From owner-linux-xfs@oss.sgi.com Sun Sep 1 02:48:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 02:48:05 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g819m0tG018981 for ; Sun, 1 Sep 2002 02:48:00 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 CAA06781 for ; Sun, 1 Sep 2002 02:51:47 -0700 (PDT) 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 TAA18463; Sun, 1 Sep 2002 19:50:29 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA83442; Sun, 1 Sep 2002 09:50:29 GMT Date: Sun, 1 Sep 2002 09:50:28 +0000 From: Nathan Scott To: mirko@tasler.net Cc: linux-xfs@oss.sgi.com Subject: Re: [xfsdump] make fails Message-ID: <20020901095028.A83368@wobbly.melbourne.sgi.com> 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 mirko@tasler.net on Sat, Aug 31, 2002 at 02:54:25PM +0200 Content-Transfer-Encoding: 8bit X-archive-position: 193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs hi, On Sat, Aug 31, 2002 at 02:54:25PM +0200, mirko@tasler.net wrote: > > hi folks, > > when i try to compile xfsdump > (ftp://oss.sgi.com/projects/xfs/download/latest/cmd_tars/xfsdump-2.0.1.src.tar.gz) > on my lfs (i386), make fails with > > /usr/bin/libtool --mode=link gcc -o xfs_fsr xfs_fsr.o > /usr/lib/libhandle.la /usr/lib/libattr.la > gcc -o xfs_fsr xfs_fsr.o /lib/libhandle.so /lib/libattr.so > gcc: /lib/libattr.so: No such file or directory > make[1]2: *** [xfs_fsr] Error 1 > make: *** [default] Error 2 > > the other packages (xfsprogs, dmapi, attr) are already installed, and > the file libattr.so exists (/lib/libattr.so). > any hints? > /lib/libattr.so is a symlink - chances are the file its pointing to does not exist on your system? iirc, it should be pointing to libattr.so.2, which is also a symlink (to libattr.so.2.?.?) - probably one of these 2 files is missing. You would normally get those files via... # cd attr-2.x.y # make install-lib You will likely see a similar problem if trying to build the acl source - it has this same dependency on libattr. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Sep 1 05:42:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 05:42:51 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g81CgltG025528 for ; Sun, 1 Sep 2002 05:42:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA66121 for ; Sun, 1 Sep 2002 07:46:31 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA33790 for ; Sun, 1 Sep 2002 07:46:31 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g81Cjgh14113; Sun, 1 Sep 2002 07:45:42 -0500 Message-Id: <200209011245.g81Cjgh14113@jen.americas.sgi.com> Date: Sun, 1 Sep 2002 07:45:42 -0500 Subject: TAKE - fix some inode teardown issues To: linux-xfs@oss.sgi.com X-archive-position: 194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs This fixes some issues between creating new inodes and tearing down old ones, freezing and thawing a filesystem seemed to be a good way of exposing this . It is a definite improvement over the old code, 36 hours continuous stress testing and still going vs about 10 minutes for the old code. Not convinced this is a totally closed issue yet though. Date: Sun Sep 1 05:43:34 PDT 2002 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:126536a linux/fs/xfs/xfs_vnodeops.c - 1.560 - fix a hole between sync and reclaim, clean up finish_reclaim code, add comments linux/fs/xfs/xfs_vfsops.c - 1.377 - pass flush mode into xfs_finish_reclaim instead of a flag linux/fs/xfs/xfs_iget.c - 1.169 - deal with the case where we race between looking up and tearing down a linux inode. linux/fs/xfs/xfs_inode.c - 1.348 - pass flush mode into xfs_finish_reclaim instead of a flag linux/fs/xfs/linux/xfs_vnode.c - 1.96 - Fail a vn_get on a vnode who's inode is being freed From owner-linux-xfs@oss.sgi.com Sun Sep 1 06:19:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 06:19:34 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g81DJStG026567 for ; Sun, 1 Sep 2002 06:19:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA66680 for ; Sun, 1 Sep 2002 08:23:12 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA39500 for ; Sun, 1 Sep 2002 08:23:12 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g81DMNx25403; Sun, 1 Sep 2002 08:22:23 -0500 Message-Id: <200209011322.g81DMNx25403@jen.americas.sgi.com> Date: Sun, 1 Sep 2002 08:22:23 -0500 Subject: TAKE - merge up to 2.5.33 To: linux-xfs@oss.sgi.com X-archive-position: 195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Date: Sun Sep 1 06:15:49 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:126537a linux/net/sctp/sysctl.c - 1.1 linux/fs/jfs/jfs_xattr.h - 1.1 linux/include/net/sctp/user.h - 1.1 linux/net/sctp/ulpevent.c - 1.1 linux/fs/jfs/xattr.c - 1.1 linux/drivers/acpi/numa.c - 1.1 linux/net/sctp/protocol.c - 1.1 linux/include/linux/mm_inline.h - 1.1 linux/include/net/sctp/sla1.h - 1.1 linux/Documentation/networking/sctp.txt - 1.1 linux/net/sctp/Config.help - 1.1 linux/net/sctp/Config.in - 1.1 linux/net/sctp/Makefile - 1.1 linux/include/net/sctp/sctp.h - 1.1 linux/net/sctp/adler32.c - 1.1 linux/net/sctp/associola.c - 1.1 linux/net/sctp/bind_addr.c - 1.1 linux/include/linux/sctp.h - 1.1 linux/net/sctp/command.c - 1.1 linux/net/sctp/crc32c.c - 1.1 linux/net/sctp/debug.c - 1.1 linux/net/sctp/endpointola.c - 1.1 linux/net/sctp/hashdriver.c - 1.1 linux/net/sctp/input.c - 1.1 linux/net/sctp/inqueue.c - 1.1 linux/net/sctp/ipv6.c - 1.1 linux/net/sctp/objcnt.c - 1.1 linux/net/sctp/output.c - 1.1 linux/drivers/net/e100/LICENSE - 1.1 linux/include/net/sctp/ulpqueue.h - 1.1 linux/net/sctp/outqueue.c - 1.1 linux/net/sctp/primitive.c - 1.1 linux/include/net/sctp/ulpevent.h - 1.1 linux/drivers/input/misc/sparcspkr.c - 1.1 linux/include/asm-ia64/kmap_types.h - 1.1 linux/include/net/sctp/constants.h - 1.1 linux/net/sctp/tsnmap.c - 1.1 linux/include/net/sctp/sm.h - 1.1 linux/net/sctp/sla1.c - 1.1 linux/net/sctp/sm_make_chunk.c - 1.1 linux/include/asm-ia64/mc146818rtc.h - 1.1 linux/include/net/sctp/command.h - 1.1 linux/net/sctp/sm_sideeffect.c - 1.1 linux/net/sctp/sm_statefuns.c - 1.1 linux/include/asm-sparc64/kmap_types.h - 1.1 linux/include/net/sctp/tsnmap.h - 1.1 linux/include/net/sctp/structs.h - 1.1 linux/include/linux/efi.h - 1.1 linux/net/sctp/sm_statetable.c - 1.1 linux/drivers/input/serio/i8042-sparcio.h - 1.1 linux/net/sctp/socket.c - 1.1 linux/net/sctp/transport.c - 1.1 linux/net/sctp/ulpqueue.c - 1.1 linux/include/linux/cobalt-nvram.h - 1.1 linux/net/sunrpc/xprt.c - 1.32 linux/net/sunrpc/svcsock.c - 1.21 linux/net/sunrpc/sched.c - 1.31 linux/net/socket.c - 1.40 linux/net/netsyms.c - 1.51 linux/net/irda/irlmp_event.c - 1.17 linux/net/ipv6/tcp_ipv6.c - 1.40 linux/net/ipv6/af_inet6.c - 1.24 linux/net/ipv4/tcp_output.c - 1.31 linux/net/ipv4/tcp_ipv4.c - 1.48 linux/net/ipv4/tcp_input.c - 1.39 linux/net/ipv4/tcp.c - 1.43 linux/net/ipv4/route.c - 1.35 linux/net/ipv4/ip_output.c - 1.34 linux/net/ipv4/af_inet.c - 1.38 linux/net/core/skbuff.c - 1.27 linux/net/core/dev.c - 1.58 linux/net/Makefile - 1.24 linux/net/Config.in - 1.27 linux/mm/vmscan.c - 1.109 linux/mm/swap_state.c - 1.47 linux/mm/swap.c - 1.24 linux/mm/page_alloc.c - 1.88 linux/mm/filemap.c - 1.131 linux/kernel/sched.c - 1.79 linux/kernel/ksyms.c - 1.161 linux/kernel/fork.c - 1.67 linux/kernel/exit.c - 1.51 linux/kernel/dma.c - 1.8 linux/init/main.c - 1.88 linux/include/video/sbusfb.h - 1.6 linux/include/net/tcp.h - 1.34 linux/include/net/sock.h - 1.32 linux/include/net/ipv6.h - 1.10 linux/include/net/ip.h - 1.18 linux/include/net/inet_common.h - 1.4 linux/include/linux/tcp.h - 1.11 linux/include/linux/sysctl.h - 1.58 linux/include/linux/swap.h - 1.64 linux/include/linux/sunrpc/svcsock.h - 1.7 linux/include/linux/socket.h - 1.11 linux/include/linux/smp.h - 1.21 linux/include/linux/skbuff.h - 1.27 linux/include/linux/sched.h - 1.80 linux/include/linux/pci.h - 1.62 linux/include/linux/pagemap.h - 1.46 linux/include/linux/nvram.h - 1.4 linux/include/linux/netdevice.h - 1.36 linux/include/linux/net.h - 1.10 linux/include/linux/mm.h - 1.97 linux/include/linux/list.h - 1.17 linux/include/linux/kernel.h - 1.35 linux/include/linux/interrupt.h - 1.23 linux/include/linux/in.h - 1.6 linux/include/linux/dcache.h - 1.26 linux/include/asm-sparc64/head.h - 1.5 linux/include/asm-sparc64/cache.h - 1.6 linux/include/asm-sparc/cache.h - 1.5 linux/include/asm-ppc/elf.h - 1.11 linux/include/asm-ppc/cache.h - 1.12 linux/include/asm-mips/cache.h - 1.6 linux/include/asm-m68k/cache.h - 1.6 linux/include/asm-i386/msr.h - 1.13 linux/include/asm-i386/mmu_context.h - 1.22 linux/include/asm-i386/desc.h - 1.14 linux/include/asm-i386/cache.h - 1.7 linux/include/asm-arm/cache.h - 1.6 linux/include/asm-alpha/cache.h - 1.9 linux/fs/smbfs/inode.c - 1.39 linux/fs/smbfs/file.c - 1.32 linux/fs/romfs/inode.c - 1.38 linux/fs/ntfs/inode.h - 1.11 linux/fs/ntfs/inode.c - 1.23 linux/fs/ntfs/dir.c - 1.18 linux/fs/ntfs/Makefile - 1.25 linux/fs/nls/nls_koi8-r.c - 1.8 linux/fs/nls/nls_iso8859-9.c - 1.9 linux/fs/nls/nls_iso8859-8.c - 1.9 linux/fs/nls/nls_iso8859-7.c - 1.9 linux/fs/nls/nls_iso8859-6.c - 1.9 linux/fs/nls/nls_iso8859-5.c - 1.9 linux/fs/nls/nls_iso8859-4.c - 1.9 linux/fs/nls/nls_iso8859-3.c - 1.9 linux/fs/nls/nls_iso8859-2.c - 1.9 linux/fs/nls/nls_iso8859-15.c - 1.9 linux/fs/nls/nls_iso8859-1.c - 1.9 linux/fs/nls/nls_cp874.c - 1.9 linux/fs/nls/nls_cp869.c - 1.9 linux/fs/nls/nls_cp866.c - 1.9 linux/fs/nls/nls_cp865.c - 1.9 linux/fs/nls/nls_cp864.c - 1.9 linux/fs/nls/nls_cp863.c - 1.9 linux/fs/nls/nls_cp862.c - 1.9 linux/fs/nls/nls_cp861.c - 1.9 linux/fs/nls/nls_cp860.c - 1.9 linux/fs/nls/nls_cp857.c - 1.9 linux/fs/nls/nls_cp855.c - 1.9 linux/fs/nls/nls_cp852.c - 1.9 linux/fs/nls/nls_cp850.c - 1.9 linux/fs/nls/nls_cp775.c - 1.9 linux/fs/nls/nls_cp737.c - 1.9 linux/fs/nls/nls_cp437.c - 1.9 linux/fs/nls/nls_base.c - 1.13 linux/fs/nfsd/vfs.c - 1.55 linux/fs/nfs/inode.c - 1.51 linux/fs/nfs/file.c - 1.34 linux/fs/locks.c - 1.30 linux/fs/lockd/svc.c - 1.18 linux/fs/fcntl.c - 1.23 linux/fs/exec.c - 1.62 linux/fs/buffer.c - 1.131 linux/fs/block_dev.c - 1.56 linux/fs/binfmt_elf.c - 1.45 linux/fs/Config.in - 1.97 linux/drivers/video/sbusfb.c - 1.24 linux/drivers/video/creatorfb.c - 1.16 linux/drivers/video/cgthreefb.c - 1.12 linux/drivers/video/cgsixfb.c - 1.15 linux/drivers/video/cgfourteenfb.c - 1.14 linux/drivers/scsi/sym53c8xx.c - 1.33 linux/drivers/scsi/st.c - 1.50 linux/drivers/scsi/sg.c - 1.36 linux/drivers/scsi/sd.c - 1.67 linux/drivers/scsi/ppa.c - 1.17 linux/drivers/scsi/imm.c - 1.17 linux/drivers/scsi/ide-scsi.c - 1.44 linux/drivers/scsi/fdomain.c - 1.22 linux/drivers/scsi/NCR53C9x.c - 1.16 linux/drivers/scsi/Config.in - 1.31 linux/drivers/sbus/char/openprom.c - 1.15 linux/drivers/net/loopback.c - 1.11 linux/drivers/net/Config.in - 1.64 linux/drivers/macintosh/via-pmu.c - 1.20 linux/drivers/char/sysrq.c - 1.27 linux/drivers/char/nvram.c - 1.23 linux/drivers/char/keyboard.c - 1.27 linux/drivers/char/console.c - 1.31 linux/drivers/char/Makefile - 1.70 linux/drivers/block/floppy.c - 1.46 linux/arch/sparc64/lib/blockops.S - 1.19 linux/arch/sparc64/kernel/traps.c - 1.22 linux/arch/sparc64/kernel/trampoline.S - 1.14 linux/arch/sparc64/kernel/setup.c - 1.33 linux/arch/sparc64/kernel/irq.c - 1.28 linux/arch/sparc64/kernel/head.S - 1.19 linux/arch/sparc64/kernel/etrap.S - 1.11 linux/arch/sparc64/kernel/entry.S - 1.26 linux/arch/sparc64/kernel/cpu.c - 1.9 linux/arch/sparc64/kernel/binfmt_elf32.c - 1.9 linux/arch/sparc64/defconfig - 1.73 linux/arch/sparc64/config.in - 1.60 linux/arch/sparc/defconfig - 1.33 linux/arch/sparc/config.in - 1.42 linux/arch/ppc/defconfig - 1.43 linux/arch/mips/sni/pci.c - 1.12 linux/arch/mips/kernel/setup.c - 1.14 linux/arch/mips/kernel/irixelf.c - 1.16 linux/arch/mips/defconfig - 1.23 linux/arch/mips/config.in - 1.35 linux/arch/m68k/defconfig - 1.13 linux/arch/i386/kernel/traps.c - 1.58 linux/arch/i386/kernel/setup.c - 1.81 linux/arch/i386/kernel/process.c - 1.55 linux/arch/i386/kernel/ldt.c - 1.14 linux/arch/i386/kernel/ioport.c - 1.5 linux/arch/i386/kernel/i386_ksyms.c - 1.54 linux/arch/i386/defconfig - 1.111 linux/arch/arm/defconfig - 1.21 linux/arch/alpha/kernel/core_t2.c - 1.12 linux/arch/alpha/kernel/core_polaris.c - 1.12 linux/arch/alpha/kernel/core_lca.c - 1.13 linux/arch/alpha/kernel/core_cia.c - 1.24 linux/arch/alpha/kernel/core_apecs.c - 1.13 linux/arch/alpha/defconfig - 1.30 linux/arch/alpha/config.in - 1.52 linux/Makefile - 1.214 linux/MAINTAINERS - 1.115 linux/Documentation/filesystems/ntfs.txt - 1.21 linux/Documentation/cdrom/sonycd535 - 1.3 linux/include/linux/ide.h - 1.60 linux/arch/arm/def-configs/rpc - 1.10 linux/arch/arm/def-configs/footbridge - 1.15 linux/arch/arm/def-configs/ebsa110 - 1.10 linux/arch/arm/def-configs/a5k - 1.8 linux/fs/nls/nls_iso8859-14.c - 1.8 linux/arch/sh/defconfig - 1.21 linux/include/asm-sh/cache.h - 1.6 linux/include/asm-i386/pci.h - 1.18 linux/fs/udf/inode.c - 1.33 linux/drivers/net/pcmcia/ray_cs.c - 1.25 linux/drivers/net/pcmcia/pcnet_cs.c - 1.19 linux/drivers/char/drm/drmP.h - 1.18 linux/include/linux/acpi.h - 1.27 linux/arch/i386/kernel/smpboot.c - 1.45 linux/drivers/net/wan/sdla_x25.c - 1.15 linux/drivers/net/pcmcia/xirc2ps_cs.c - 1.18 linux/drivers/net/pcmcia/3c574_cs.c - 1.19 linux/arch/arm/def-configs/empeg - 1.3 linux/arch/arm/def-configs/brutus - 1.12 linux/include/linux/highmem.h - 1.24 linux/fs/proc/proc_misc.c - 1.40 linux/include/asm-ppc/pgalloc.h - 1.11 linux/include/asm-i386/pgalloc.h - 1.21 linux/arch/ppc/configs/walnut_defconfig - 1.18 linux/arch/ppc/configs/pmac_defconfig - 1.10 linux/arch/ppc/configs/oak_defconfig - 1.18 linux/arch/ppc/configs/mbx_defconfig - 1.13 linux/arch/ppc/configs/gemini_defconfig - 1.20 linux/arch/ppc/configs/common_defconfig - 1.30 linux/arch/ppc/configs/apus_defconfig - 1.16 linux/arch/alpha/kernel/core_irongate.c - 1.11 linux/include/linux/mmzone.h - 1.24 linux/include/linux/cache.h - 1.5 linux/include/asm-sparc64/pgalloc.h - 1.22 linux/fs/openpromfs/inode.c - 1.24 linux/include/asm-sparc/pgalloc.h - 1.16 linux/include/net/inetpeer.h - 1.4 linux/drivers/char/mxser.c - 1.18 linux/Documentation/usb/ohci.txt - 1.3 linux/drivers/char/efirtc.c - 1.10 linux/arch/ia64/kernel/fw-emu.c - 1.9 linux/arch/ia64/kernel/entry.S - 1.29 linux/arch/ia64/kernel/efi.c - 1.17 linux/arch/ia64/kernel/acpi.c - 1.16 linux/arch/ia64/ia32/sys_ia32.c - 1.29 linux/arch/ia64/vmlinux.lds.S - 1.15 linux/arch/ia64/defconfig - 1.19 linux/arch/ia64/Makefile - 1.17 linux/arch/ia64/kernel/irq.c - 1.22 linux/arch/ia64/kernel/setup.c - 1.18 linux/arch/ia64/kernel/smp.c - 1.19 linux/arch/ia64/kernel/time.c - 1.15 linux/arch/ia64/kernel/traps.c - 1.16 linux/arch/ia64/kernel/pci.c - 1.15 linux/arch/ia64/kernel/process.c - 1.19 linux/arch/ia64/mm/tlb.c - 1.13 linux/arch/ia64/mm/init.c - 1.20 linux/include/asm-ia64/irq.h - 1.4 linux/include/asm-ia64/iosapic.h - 1.6 linux/include/asm-ia64/io.h - 1.10 linux/include/asm-ia64/ide.h - 1.12 linux/include/asm-ia64/ia32.h - 1.12 linux/include/asm-ia64/hardirq.h - 1.15 linux/include/asm-ia64/fpu.h - 1.2 linux/include/asm-ia64/efi.h - 1.12 linux/include/asm-ia64/cache.h - 1.6 linux/include/asm-ia64/atomic.h - 1.6 linux/include/asm-ia64/sal.h - 1.11 linux/include/asm-ia64/processor.h - 1.24 linux/include/asm-ia64/pgalloc.h - 1.15 linux/include/asm-ia64/pci.h - 1.16 linux/include/asm-ia64/mmu_context.h - 1.9 linux/include/asm-ia64/unistd.h - 1.23 linux/include/asm-ia64/types.h - 1.4 linux/include/asm-ia64/system.h - 1.18 linux/drivers/net/8139too.c - 1.41 linux/Documentation/filesystems/devfs/README - 1.17 linux/Documentation/filesystems/devfs/ChangeLog - 1.25 linux/include/linux/devfs_fs_kernel.h - 1.13 linux/fs/devfs/base.c - 1.43 linux/Documentation/networking/8139too.txt - 1.18 linux/arch/mips/ddb5074/pci.c - 1.9 linux/arch/mips/defconfig-decstation - 1.9 linux/arch/mips/defconfig-ip22 - 1.10 linux/drivers/net/tulip/interrupt.c - 1.15 linux/include/asm-mips64/elf.h - 1.8 linux/include/asm-mips64/cache.h - 1.4 linux/include/asm-mips64/sn/sn0/hubio.h - 1.4 linux/arch/mips64/defconfig - 1.19 linux/arch/mips64/config.in - 1.25 linux/arch/mips64/defconfig-ip22 - 1.12 linux/arch/mips64/kernel/binfmt_elf32.c - 1.7 linux/arch/mips64/defconfig-ip27 - 1.11 linux/drivers/net/bonding.c - 1.14 linux/include/linux/usb.h - 1.45 linux/include/asm-ia64/hw_irq.h - 1.9 linux/arch/ia64/kernel/irq_ia64.c - 1.13 linux/drivers/ide/ide.c - 1.63 linux/drivers/ide/ide-tape.c - 1.35 linux/drivers/ide/ide-proc.c - 1.21 linux/drivers/ide/ide-probe.c - 1.34 linux/drivers/ide/ide-floppy.c - 1.33 linux/drivers/ide/ide-disk.c - 1.45 linux/drivers/ide/ide-cd.c - 1.45 linux/drivers/scsi/sym53c8xx_comm.h - 1.13 linux/net/ipv4/netfilter/ip_tables.c - 1.16 linux/net/ipv4/netfilter/ip_nat_core.c - 1.14 linux/drivers/net/pcmcia/ibmtr_cs.c - 1.10 linux/drivers/usb/serial/keyspan_pda.c - 1.29 linux/drivers/usb/serial/ftdi_sio.c - 1.39 linux/drivers/usb/serial/usbserial.c - 1.40 linux/drivers/usb/serial/whiteheat.c - 1.28 linux/drivers/usb/serial/visor.c - 1.38 linux/arch/ia64/kernel/smpboot.c - 1.13 linux/drivers/usb/serial/omninet.c - 1.27 linux/drivers/usb/serial/digi_acceleport.c - 1.30 linux/arch/arm/def-configs/lart - 1.8 linux/arch/s390/defconfig - 1.12 linux/include/asm-s390/cache.h - 1.5 linux/arch/arm/def-configs/assabet - 1.10 linux/arch/arm/def-configs/graphicsclient - 1.9 linux/arch/arm/def-configs/lusl7200 - 1.6 linux/include/asm-s390/pgalloc.h - 1.7 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.11 linux/drivers/char/drm/r128_drv.h - 1.10 linux/drivers/char/drm/mga_state.c - 1.10 linux/drivers/char/drm/mga_drv.h - 1.10 linux/drivers/char/drm/mga_dma.c - 1.8 linux/drivers/char/drm/i810_dma.c - 1.17 linux/drivers/usb/serial/keyspan.h - 1.12 linux/drivers/usb/serial/keyspan.c - 1.31 linux/drivers/acpi/tables.c - 1.6 linux/drivers/acpi/events/evmisc.c - 1.12 linux/drivers/acpi/events/evevent.c - 1.14 linux/drivers/acpi/dispatcher/dswload.c - 1.14 linux/drivers/acpi/dispatcher/dsopcode.c - 1.14 linux/arch/ia64/kernel/ia64_ksyms.c - 1.15 linux/drivers/acpi/Makefile - 1.18 linux/arch/ia64/kernel/palinfo.c - 1.8 linux/arch/ia64/lib/memcpy.S - 1.6 linux/drivers/mtd/mtdblock.c - 1.20 linux/fs/nls/nls_big5.c - 1.5 linux/arch/mips/defconfig-rm200 - 1.6 linux/arch/ppc/configs/rpxlite_defconfig - 1.13 linux/arch/ppc/configs/rpxcllf_defconfig - 1.14 linux/arch/ppc/configs/est8260_defconfig - 1.15 linux/arch/ppc/configs/bseip_defconfig - 1.13 linux/fs/nls/nls_cp932.c - 1.5 linux/fs/nls/nls_cp936.c - 1.4 linux/fs/nls/nls_cp949.c - 1.4 linux/fs/nls/nls_cp950.c - 1.4 linux/fs/nls/nls_euc-jp.c - 1.6 linux/fs/nls/nls_euc-kr.c - 1.5 linux/fs/nls/nls_gb2312.c - 1.5 linux/fs/nls/nls_sjis.c - 1.5 linux/fs/nls/nls_utf8.c - 1.4 linux/net/ipv4/tcp_minisocks.c - 1.14 linux/include/net/tcp_ecn.h - 1.5 linux/drivers/media/video/videodev.c - 1.15 linux/drivers/media/video/saa7110.c - 1.7 linux/drivers/media/video/Config.in - 1.8 linux/drivers/input/mousedev.c - 1.13 linux/drivers/input/input.c - 1.13 linux/drivers/input/Config.in - 1.7 linux/drivers/md/raid5.c - 1.32 linux/Documentation/cciss.txt - 1.5 linux/arch/arm/def-configs/clps7500 - 1.3 linux/arch/arm/def-configs/shark - 1.9 linux/drivers/acpi/include/acconfig.h - 1.16 linux/drivers/acpi/include/acglobal.h - 1.13 linux/drivers/acpi/include/aclocal.h - 1.15 linux/drivers/acpi/include/acparser.h - 1.10 linux/drivers/usb/serial/belkin_sa.c - 1.22 linux/include/asm-i386/xor.h - 1.8 linux/include/asm-m68k/motorola_pgalloc.h - 1.8 linux/drivers/usb/serial/mct_u232.c - 1.22 linux/arch/arm/def-configs/integrator - 1.5 linux/arch/arm/def-configs/neponset - 1.9 linux/arch/arm/def-configs/pangolin - 1.7 linux/arch/arm/def-configs/sherman - 1.5 linux/drivers/usb/serial/empeg.c - 1.27 linux/include/asm-m68k/sun3_pgalloc.h - 1.7 linux/include/asm-parisc/cache.h - 1.2 linux/arch/parisc/defconfig - 1.6 linux/drivers/acpi/include/actbl2.h - 1.8 linux/include/asm-i386/mmu.h - 1.4 linux/include/asm-ia64/sn/alenlist.h - 1.3 linux/drivers/char/drm/r128_state.c - 1.6 linux/drivers/char/drm/r128_cce.c - 1.7 linux/arch/ia64/kernel/iosapic.c - 1.11 linux/arch/ia64/sn/io/pci.c - 1.4 linux/drivers/char/drm/radeon_cp.c - 1.9 linux/drivers/char/drm/radeon_drv.h - 1.7 linux/drivers/char/drm/radeon_state.c - 1.6 linux/fs/reiserfs/fix_node.c - 1.25 linux/arch/ppc/configs/power3_defconfig - 1.11 linux/arch/ppc/configs/ibmchrp_defconfig - 1.11 linux/include/asm-s390x/pgalloc.h - 1.6 linux/include/asm-s390x/cache.h - 1.5 linux/arch/cris/defconfig - 1.12 linux/arch/s390x/kernel/binfmt_elf32.c - 1.5 linux/arch/s390x/defconfig - 1.11 linux/drivers/s390/block/dasd_3990_erp.c - 1.9 linux/include/asm-cris/cache.h - 1.2 linux/include/asm-ppc/tlb.h - 1.4 linux/drivers/usb/serial/io_edgeport.c - 1.27 linux/arch/ppc/configs/TQM860L_defconfig - 1.13 linux/arch/ppc/configs/TQM850L_defconfig - 1.11 linux/arch/ppc/configs/TQM823L_defconfig - 1.11 linux/arch/ppc/configs/SPD823TS_defconfig - 1.11 linux/arch/ppc/configs/SM850_defconfig - 1.11 linux/arch/ppc/configs/IVMS8_defconfig - 1.13 linux/arch/sh/kernel/pci_st40.c - 1.5 linux/fs/nls/nls_cp1251.c - 1.5 linux/fs/nls/nls_cp1255.c - 1.6 linux/fs/nls/nls_iso8859-13.c - 1.6 linux/arch/sh/kernel/irq_intc2.c - 1.5 linux/fs/nls/nls_koi8-u.c - 1.5 linux/fs/nls/nls_tis-620.c - 1.4 linux/arch/mips/mips-boards/generic/pci.c - 1.4 linux/arch/mips/ite-boards/generic/it8172_pci.c - 1.4 linux/arch/mips/defconfig-it8172 - 1.8 linux/arch/mips/defconfig-ddb5476 - 1.8 linux/arch/mips/ddb5476/pci.c - 1.4 linux/arch/ia64/kernel/efivars.c - 1.7 linux/include/asm-alpha/mmzone.h - 1.2 linux/fs/nls/nls_koi8-ru.c - 1.5 linux/drivers/media/video/bt856.c - 1.7 linux/drivers/media/video/bt819.c - 1.6 linux/include/net/bluetooth/bluetooth.h - 1.5 linux/drivers/acpi/utilities/utglobal.c - 1.11 linux/drivers/acpi/Config.in - 1.6 linux/drivers/usb/serial/pl2303.h - 1.5 linux/drivers/acpi/include/platform/aclinux.h - 1.8 linux/drivers/acpi/debugger/dbdisasm.c - 1.7 linux/drivers/usb/serial/cyberjack.c - 1.16 linux/drivers/usb/serial/pl2303.c - 1.18 linux/arch/sh/kernel/pci-sh7751.c - 1.4 linux/arch/sh/kernel/pci-dc.c - 1.3 linux/drivers/char/drm/radeon.h - 1.3 linux/drivers/char/drm/drm_vm.h - 1.13 linux/drivers/char/drm/drm_stub.h - 1.4 linux/drivers/char/drm/drm_drv.h - 1.7 linux/drivers/char/drm/drm_agpsupport.h - 1.8 linux/arch/arm/def-configs/anakin - 1.4 linux/arch/arm/def-configs/flexanet - 1.6 linux/arch/arm/def-configs/freebird - 1.5 linux/arch/arm/def-configs/freebird_new - 1.5 linux/arch/arm/def-configs/h3600 - 1.5 linux/arch/arm/def-configs/huw_webpanel - 1.4 linux/arch/arm/def-configs/jornada720 - 1.6 linux/arch/arm/def-configs/omnimeter - 1.5 linux/arch/arm/def-configs/pfs168_mqtft - 1.5 linux/arch/arm/def-configs/pfs168_mqvga - 1.5 linux/arch/arm/def-configs/pfs168_sastn - 1.5 linux/arch/arm/def-configs/pfs168_satft - 1.5 linux/arch/arm/def-configs/pleb - 1.4 linux/arch/ppc/mm/tlb.c - 1.6 linux/drivers/scsi/dpt_i2o.c - 1.14 linux/arch/mips/ddb5xxx/ddb5477/pci_ops.c - 1.2 linux/arch/mips/defconfig-atlas - 1.3 linux/arch/mips/defconfig-ddb5477 - 1.3 linux/arch/mips/defconfig-malta - 1.3 linux/arch/mips/defconfig-nino - 1.3 linux/arch/mips/defconfig-ocelot - 1.3 linux/arch/mips/defconfig-pb1000 - 1.3 linux/arch/mips/gt64120/common/pci.c - 1.4 linux/arch/mips64/defconfig-ip32 - 1.3 linux/include/asm-s390x/tlb.h - 1.4 linux/include/asm-sparc/tlb.h - 1.3 linux/include/asm-s390/tlb.h - 1.4 linux/include/asm-m68k/tlb.h - 1.4 linux/include/asm-ia64/tlb.h - 1.5 linux/include/asm-i386/tlb.h - 1.4 linux/include/asm-sparc64/tlb.h - 1.5 linux/include/asm-generic/tlb.h - 1.9 linux/include/asm-arm/tlb.h - 1.4 linux/include/asm-alpha/tlb.h - 1.3 linux/drivers/mtd/devices/blkmtd.c - 1.12 linux/drivers/usb/serial/ir-usb.c - 1.18 linux/drivers/message/i2o/README.ioctl - 1.2 linux/drivers/net/8139cp.c - 1.18 linux/arch/arm/def-configs/adsbitsy - 1.5 linux/arch/arm/def-configs/cerfcube - 1.5 linux/arch/arm/def-configs/cerfpda - 1.5 linux/arch/arm/def-configs/cerfpod - 1.5 linux/arch/arm/def-configs/edb7211 - 1.3 linux/arch/arm/def-configs/epxa10db - 1.5 linux/arch/arm/def-configs/graphicsmaster - 1.5 linux/Documentation/networking/bonding.txt - 1.4 linux/drivers/scsi/sym53c8xx_2/sym_fw1.h - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_fw2.h - 1.2 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.6 linux/fs/ext3/inode.c - 1.17 linux/fs/ext3/super.c - 1.22 linux/drivers/hotplug/pci_hotplug_util.c - 1.4 linux/fs/jbd/revoke.c - 1.8 linux/include/linux/gfp.h - 1.3 linux/drivers/usb/serial/ipaq.c - 1.12 linux/drivers/usb/serial/kl5kusb105.c - 1.11 linux/Documentation/usb/ehci.txt - 1.3 linux/arch/arm/def-configs/adi_evb - 1.4 linux/arch/arm/def-configs/iq80310 - 1.9 linux/arch/arm/def-configs/shannon - 1.4 linux/arch/arm/def-configs/system3 - 1.4 linux/fs/Config.help - 1.18 linux/drivers/char/Config.help - 1.9 linux/drivers/net/Config.help - 1.6 linux/drivers/input/serio/Config.in - 1.5 linux/include/asm-i386/thread_info.h - 1.5 linux/Documentation/preempt-locking.txt - 1.4 linux/sound/ppc/tumbler.c - 1.4 linux/sound/ppc/pmac.c - 1.5 linux/sound/ppc/keywest.c - 1.4 linux/sound/ppc/daca.c - 1.3 linux/sound/ppc/burgundy.c - 1.3 linux/sound/ppc/awacs.c - 1.5 linux/sound/oss/wavfront.c - 1.3 linux/sound/oss/waveartist.c - 1.2 linux/sound/oss/vwsnd.c - 1.3 linux/sound/oss/via82cxxx_audio.c - 1.7 linux/sound/oss/v_midi.c - 1.2 linux/sound/oss/uart6850.c - 1.2 linux/sound/oss/uart401.c - 1.2 linux/sound/oss/trident.c - 1.6 linux/sound/oss/sys_timer.c - 1.2 linux/sound/oss/sscape.c - 1.2 linux/sound/oss/soundcard.c - 1.3 linux/sound/oss/sound_timer.c - 1.2 linux/arch/ppc/configs/FADS_defconfig - 1.3 linux/arch/ppc/configs/TQM8260_defconfig - 1.3 linux/sound/oss/sonicvibes.c - 1.4 linux/arch/ppc/configs/adir_defconfig - 1.3 linux/arch/ppc/configs/ash_defconfig - 1.3 linux/arch/ppc/configs/ceder_defconfig - 1.3 linux/sound/oss/sequencer.c - 1.3 linux/arch/ppc/configs/cpci405_defconfig - 1.5 linux/arch/ppc/configs/ep405_defconfig - 1.3 linux/arch/ppc/configs/ev64260_defconfig - 1.3 linux/arch/ppc/configs/iSeries_defconfig - 1.3 linux/arch/ppc/configs/k2_defconfig - 1.7 linux/arch/ppc/configs/lopec_defconfig - 1.4 linux/arch/ppc/configs/mcpn765_defconfig - 1.3 linux/arch/ppc/configs/menf1_defconfig - 1.7 linux/arch/ppc/configs/mvme5100_defconfig - 1.6 linux/arch/ppc/configs/pcore_defconfig - 1.3 linux/arch/ppc/configs/pplus_defconfig - 1.7 linux/arch/ppc/configs/prpmc750_defconfig - 1.3 linux/arch/ppc/configs/prpmc800_defconfig - 1.3 linux/arch/ppc/configs/redwood5_defconfig - 1.4 linux/arch/ppc/configs/redwood_defconfig - 1.3 linux/arch/ppc/configs/sandpoint_defconfig - 1.8 linux/arch/ppc/configs/spruce_defconfig - 1.3 linux/arch/ppc/configs/zx4500_defconfig - 1.3 linux/sound/oss/rme96xx.c - 1.4 linux/sound/oss/pss.c - 1.3 linux/sound/oss/pas2_pcm.c - 1.2 linux/sound/oss/pas2_midi.c - 1.2 linux/sound/oss/pas2_card.c - 1.2 linux/sound/oss/opl3sa2.c - 1.2 linux/sound/oss/opl3sa.c - 1.2 linux/sound/oss/nm256_audio.c - 1.2 linux/sound/oss/nm256.h - 1.2 linux/sound/oss/nec_vrc5477.c - 1.2 linux/sound/oss/msnd_pinnacle.c - 1.3 linux/sound/oss/mpu401.c - 1.3 linux/sound/oss/midibuf.c - 1.3 linux/sound/oss/midi_synth.c - 1.2 linux/sound/oss/maestro3.c - 1.3 linux/sound/oss/maestro.c - 1.4 linux/sound/oss/mad16.c - 1.4 linux/sound/oss/ite8172.c - 1.3 linux/sound/oss/gus_card.c - 1.2 linux/sound/oss/esssolo1.c - 1.5 linux/sound/oss/es1370.c - 1.5 linux/sound/oss/dmabuf.c - 1.2 linux/sound/oss/dev_table.h - 1.2 linux/sound/oss/cmpci.c - 1.3 linux/arch/x86_64/defconfig - 1.10 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.4 linux/sound/oss/audio.c - 1.2 linux/sound/oss/ad1848.c - 1.3 linux/sound/oss/ad1816.c - 1.2 linux/include/asm-x86_64/pgalloc.h - 1.5 linux/include/asm-x86_64/cache.h - 1.2 linux/include/asm-x86_64/xor.h - 1.3 linux/include/asm-x86_64/tlb.h - 1.4 linux/include/asm-ppc64/elf.h - 1.2 linux/include/asm-ppc64/cache.h - 1.3 linux/arch/ppc64/defconfig - 1.7 linux/arch/ppc64/kernel/iSeries_IoMmTable.c - 1.2 linux/include/asm-ppc64/tlb.h - 1.3 linux/include/asm-ppc64/pgalloc.h - 1.5 linux/drivers/net/e1000/e1000_main.c - 1.10 linux/drivers/net/e1000/LICENSE - 1.3 linux/Documentation/networking/e1000.txt - 1.4 linux/drivers/net/e1000/Makefile - 1.5 linux/drivers/net/e1000/e1000_osdep.h - 1.5 linux/drivers/net/e1000/e1000.h - 1.6 linux/drivers/net/e1000/e1000_ethtool.c - 1.5 linux/drivers/net/e1000/e1000_param.c - 1.4 linux/drivers/net/e1000/e1000_proc.c - 1.3 linux/fs/jfs/jfs_metapage.h - 1.4 linux/fs/jfs/Makefile - 1.4 linux/fs/jfs/file.c - 1.9 linux/arch/arm/def-configs/badge4 - 1.6 linux/arch/arm/def-configs/fortunet - 1.3 linux/arch/arm/def-configs/stork - 1.4 linux/fs/jfs/inode.c - 1.11 linux/fs/jfs/jfs_dmap.c - 1.7 linux/fs/jfs/jfs_incore.h - 1.8 linux/fs/jfs/jfs_imap.c - 1.6 linux/fs/jfs/namei.c - 1.10 linux/fs/jfs/jfs_logmgr.c - 1.14 linux/fs/jfs/super.c - 1.12 linux/fs/jfs/symlink.c - 1.5 linux/fs/jfs/jfs_txnmgr.c - 1.13 linux/fs/jfs/jfs_types.h - 1.3 linux/fs/jfs/jfs_umount.c - 1.4 linux/fs/jfs/jfs_metapage.c - 1.9 linux/drivers/net/tulip/xircom_cb.c - 1.3 linux/drivers/net/e100/e100_phy.h - 1.4 linux/drivers/net/e100/e100_proc.c - 1.6 linux/drivers/net/e100/e100.h - 1.8 linux/drivers/net/e100/e100_ucode.h - 1.3 linux/drivers/net/e100/e100_vendor.h - 1.4 linux/drivers/net/e100/e100_phy.c - 1.5 linux/drivers/net/e100/e100_config.c - 1.6 linux/drivers/net/e100/e100_config.h - 1.5 linux/drivers/net/e100/e100_eeprom.c - 1.4 linux/drivers/net/e100/e100_main.c - 1.7 linux/arch/ia64/sn/fakeprom/fpmem.c - 1.2 linux/arch/ia64/sn/io/efi-rtc.c - 1.2 linux/mm/msync.c - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-generic-sp - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-hp-sp - 1.3 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp - 1.5 linux/arch/ia64/sn/kernel/llsc4.c - 1.4 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-mp - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-sp - 1.6 linux/arch/ia64/sn/configs/sn1/defconfig-dig-mp - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-dig-sp - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-generic-mp - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-prom-medusa - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-modules - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-syn1-0 - 1.5 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-sp - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-dig-numa - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-mp - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-sp - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp-modules - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-prom-medusa - 1.5 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-sp - 1.5 linux/arch/ia64/sn/fakeprom/fw-emu.c - 1.2 linux/arch/ia64/sn/io/sn1/pcibr.c - 1.3 linux/drivers/net/sb1250-mac.c - 1.2 linux/drivers/net/e1000/e1000_hw.h - 1.4 linux/drivers/usb/class/bluetty.c - 1.7 linux/Documentation/watchdog-api.txt - 1.2 linux/drivers/usb/core/hcd.c - 1.9 linux/drivers/usb/core/hcd.h - 1.7 linux/drivers/usb/input/hid-core.c - 1.7 linux/drivers/usb/core/usb.c - 1.14 linux/drivers/usb/media/konicawc.c - 1.5 linux/drivers/usb/host/ehci-dbg.c - 1.5 linux/fs/partitions/efi.h - 1.3 linux/drivers/usb/host/ohci-q.c - 1.10 linux/drivers/usb/media/usbvideo.c - 1.7 linux/drivers/net/e1000/e1000_hw.c - 1.4 linux/fs/nls/nls_cp1250.c - 1.2 linux/drivers/usb/input/hid.h - 1.4 linux/drivers/usb/input/usbkbd.c - 1.3 linux/drivers/usb/input/usbmouse.c - 1.3 linux/drivers/usb/input/wacom.c - 1.3 linux/drivers/usb/media/ibmcam.c - 1.4 linux/drivers/net/e100/e100_test.c - 1.4 linux/drivers/usb/serial/safe_serial.c - 1.6 linux/drivers/usb/media/ultracam.c - 1.4 linux/drivers/usb/media/usbvideo.h - 1.5 linux/drivers/usb/net/kaweth.c - 1.7 linux/include/asm-ia64/percpu.h - 1.3 linux/include/asm-ia64/acpi.h - 1.4 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.5 linux/arch/ia64/hp/sim/simserial.c - 1.5 linux/arch/ia64/hp/sim/simeth.c - 1.2 linux/arch/ia64/hp/common/sba_iommu.c - 1.5 linux/drivers/usb/misc/brlvger.c - 1.6 linux/fs/ntfs/attrib.c - 1.8 linux/fs/ntfs/compress.c - 1.8 linux/fs/ntfs/file.c - 1.7 linux/fs/ntfs/namei.c - 1.7 linux/fs/ntfs/mft.h - 1.3 linux/fs/ntfs/mft.c - 1.7 linux/fs/ntfs/ChangeLog - 1.9 linux/fs/ntfs/aops.c - 1.9 linux/arch/i386/pci/common.c - 1.4 linux/arch/i386/pci/direct.c - 1.4 linux/net/ipv6/ipv6_syms.c - 1.2 linux/drivers/pci/access.c - 1.3 linux/drivers/pci/pool.c - 1.3 linux/drivers/pci/probe.c - 1.4 linux/arch/i386/pci/numa.c - 1.4 linux/include/linux/page-flags.h - 1.6 linux/arch/i386/pci/pcbios.c - 1.4 linux/drivers/bluetooth/hci_ldisc.c - 1.2 linux/mm/page-writeback.c - 1.9 linux/include/linux/writeback.h - 1.7 linux/drivers/char/drm/i830_dma.c - 1.3 linux/fs/mpage.c - 1.6 linux/drivers/usb/core/urb.c - 1.5 linux/drivers/acpi/bus.c - 1.6 linux/drivers/acpi/system.c - 1.7 linux/drivers/acpi/osl.c - 1.4 linux/drivers/usb/core/hcd-pci.c - 1.4 linux/arch/i386/kernel/cpu/common.c - 1.5 linux/drivers/usb/input/aiptek.c - 1.5 linux/arch/x86_64/pci/direct.c - 1.3 linux/include/asm-ia64/agp.h - 1.3 linux/drivers/input/keyboard/atkbd.c - 1.5 linux/drivers/input/serio/i8042.h - 1.3 linux/drivers/input/serio/i8042.c - 1.5 linux/drivers/input/mouse/psmouse.c - 1.5 linux/drivers/input/serio/i8042-io.h - 1.2 linux/drivers/usb/input/powermate.c - 1.3 linux/drivers/usb/input/xpad.c - 1.3 linux/security/security.c - 1.2 linux/drivers/usb/serial/io_ti.c - 1.2 linux/drivers/serial/Config.in - 1.3 linux/mm/rmap.c - 1.4 linux/arch/arm/def-configs/lubbock - 1.2 linux/include/linux/pagevec.h - 1.2 linux/drivers/usb/core/buffer.c - 1.2 linux/drivers/input/misc/Makefile - 1.2 linux/drivers/input/misc/Config.in - 1.2 linux/drivers/input/misc/Config.help - 1.2 From owner-linux-xfs@oss.sgi.com Sun Sep 1 14:43:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 14:43:43 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g81LhZtG014001 for ; Sun, 1 Sep 2002 14:43:35 -0700 Received: (qmail 25343 invoked by uid 500); 1 Sep 2002 21:46:56 -0000 Subject: Re: gcc 3.2 From: Austin Gonyou To: stefano sartini Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D6E233B.4090209@inwind.it> References: <3D6E233B.4090209@inwind.it> Content-type: text/plain Organization: Coremetrics, Inc. Message-Id: <1030916816.25333.2.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 01 Sep 2002 16:46:56 -0500 Content-Transfer-Encoding: 8bit X-archive-position: 196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I used 3.2 recently to compile 2.4.19-RC5-aa1. No problems there. On Thu, 2002-08-29 at 08:35, stefano sartini wrote: > hi all, > does anyone knows any issue compiling an XFS kernel with gcc 3.2 ? > > This is what i got on my Slackware: > > make[4]: Entering directory `/usr/src/2.4.19-xfs/fs/xfs/pagebuf' > gcc -D__KERNEL__ -I/usr/src/2.4.19-xfs/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O3 -mcpu=i686 > -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop > -frerun-loop-opt -fno-strict-aliasing -fno-common -fomit-frame-pointer > -pipe -mpreferred-stack-boundary=2 -march=i686 -I.. -nostdinc -I > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/include > -DKBUILD_BASENAME=page_buf -DEXPORT_SYMTAB -c page_buf.c > gcc -D__KERNEL__ -I/usr/src/2.4.19-xfs/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O3 -mcpu=i686 -march=i686 > -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop > -frerun-loop-opt -fno-strict-aliasing -fno-common -fomit-frame-pointer > -pipe -mpreferred-stack-boundary=2 -march=i686 -I.. -nostdinc -I > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/include > -DKBUILD_BASENAME=page_buf_io -c -o page_buf_io.o page_buf_io.c > gcc -D__KERNEL__ -I/usr/src/2.4.19-xfs/include -Wall > -Wstrict-prototypes -Wno-trigraphs -O3 -mcpu=i686 -march=i686 > -fexpensive-optimizations -funroll-loops -frerun-cse-after-loop > -frerun-loop-opt -fno-strict-aliasing -fno-common -fomit-frame-pointer > -pipe -mpreferred-stack-boundary=2 -march=i686 -I.. -nostdinc -I > /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/include > -DKBUILD_BASENAME=page_buf_locking -c -o page_buf_locking.o > page_buf_locking.c > {standard input}: Assembler messages: > {standard input}:148: Error: suffix or operands invalid for `bsf' > make[4]: *** [page_buf_locking.o] Error 1 > make[4]: Leaving directory `/usr/src/2.4.19-xfs/fs/xfs/pagebuf' > make[3]: *** [first_rule] Error 2 > make[3]: Leaving directory `/usr/src/2.4.19-xfs/fs/xfs/pagebuf' > make[2]: *** [_subdir_pagebuf] Error 2 > make[2]: Leaving directory `/usr/src/2.4.19-xfs/fs/xfs' > make[1]: *** [_subdir_xfs] Error 2 > make[1]: Leaving directory `/usr/src/2.4.19-xfs/fs' > make: *** [_dir_fs] Error 2 > > Compiling back with the 2.95.3 gcc gave no problem... > Is a compiler issue? > > Stefano Sartini. > -- Austin Gonyou Coremetrics, Inc. -- Attached file included as plaintext by Ecartis -- -- File: signature.asc -- Desc: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9corQ94g6ZVmFMoIRAlzBAJ9WpBVG/8gIT75QgivfEY2dMvD5TwCgyHoR u7zrQaKaCM4pjXgzMmkT6/c= =j5/s -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Sep 1 15:48:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 15:48:18 -0700 (PDT) Received: from msrv.minfin.govrn.bg ([212.122.164.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g81Mm9tG014737 for ; Sun, 1 Sep 2002 15:48:12 -0700 Received: from larry.minfin.government.bg ([192.168.1.12]) by msrv.minfin.govrn.bg (Netscape Messaging Server 3.62) with ESMTP id 411 for ; Mon, 2 Sep 2002 01:52:19 +0300 Received: (qmail 13400 invoked by uid 0); 1 Sep 2002 22:39:11 -0000 Date: 1 Sep 2002 22:39:11 -0000 Message-ID: <20020901223911.13399.qmail@larry.minfin.government.bg> From: root@larry.minfin.government.bg.sgi.com To: linux-xfs@oss.sgi.com Subject: Max file number in single directory X-archive-position: 197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: root@larry.minfin.government.bg.sgi.com Precedence: bulk X-list: linux-xfs I got this error when I try to proceed my directory root@larry:~/phones/new_scripts# ls CHEPELARE/*.htm bash: /bin/ls: Argument list too long cat CHEPELARE/* returns same error as above while root@larry:~/phones/new_scripts# ls CHEPELARE/ works fine the number of files in that dir is fairy big root@larry:~/phones/new_scripts# ls CHEPELARE/ |wc -l 30303 Also I'd like to know, if this is general Linux VFS, XFS or file-utils implementation restriction/bug or whatever The sytem is Slack 8.1 with recent cvs snapshot kernel my root filesystem is XFS. Kostadin Karaivanov Senior System Administrator @ Ministry of Finance of Bulgaria From owner-linux-xfs@oss.sgi.com Sun Sep 1 15:53:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 15:53:11 -0700 (PDT) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g81Mr8tG015203 for ; Sun, 1 Sep 2002 15:53:09 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17ldeM-0003XF-00; Sun, 01 Sep 2002 23:56:58 +0100 Date: Sun, 1 Sep 2002 23:56:58 +0100 From: Christoph Hellwig To: root@larry.minfin.government.bg.sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: Max file number in single directory Message-ID: <20020901235658.A13582@infradead.org> References: <20020901223911.13399.qmail@larry.minfin.government.bg> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020901223911.13399.qmail@larry.minfin.government.bg>; from root@larry.minfin.government.bg.sgi.com on Sun, Sep 01, 2002 at 10:39:11PM -0000 Content-Transfer-Encoding: 8bit X-archive-position: 198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sun, Sep 01, 2002 at 10:39:11PM -0000, root@larry.minfin.government.bg.sgi.com wrote: > I got this error when I try to proceed my directory > > root@larry:~/phones/new_scripts# ls CHEPELARE/*.htm > bash: /bin/ls: Argument list too long > > cat CHEPELARE/* returns same error as above > > while > root@larry:~/phones/new_scripts# ls CHEPELARE/ > works fine > > the number of files in that dir is fairy big > > root@larry:~/phones/new_scripts# ls CHEPELARE/ |wc -l > 30303 > > Also I'd like to know, if this is general Linux VFS, XFS or file-utils implementation restriction/bug or whatever It's a general Linux limitation - but nothing related to the number of files in a directory. By doing a ls CHEPELARE/*.htm you let the shell glob the filenames and pass all matching ones to /bin/ls. With 30303 html files in directory these are quite a lot and the resulting array overflows the hardcoded change for the argument size in the kernel binary loader. From owner-linux-xfs@oss.sgi.com Sun Sep 1 17:26:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 17:26:48 -0700 (PDT) Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g820QitG016447 for ; Sun, 1 Sep 2002 17:26:46 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g820T2u26249; Mon, 2 Sep 2002 02:29:02 +0200 Date: Mon, 2 Sep 2002 02:29:02 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Christoph Hellwig Cc: root@larry.minfin.government.bg.sgi.com, linux-xfs@oss.sgi.com Subject: Re: Max file number in single directory Message-ID: <20020902022901.F6228@vestdata.no> References: <20020901223911.13399.qmail@larry.minfin.government.bg> <20020901235658.A13582@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020901235658.A13582@infradead.org>; from hch@infradead.org on Sun, Sep 01, 2002 at 11:56:58PM +0100 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g820T2u26249 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g820QktG016448 X-archive-position: 199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs On Sun, Sep 01, 2002 at 11:56:58PM +0100, Christoph Hellwig wrote: > > On Sun, Sep 01, 2002 at 10:39:11PM -0000, root@larry.minfin.government.bg.sgi.com wrote: > > I got this error when I try to proceed my directory > > > > root@larry:~/phones/new_scripts# ls CHEPELARE/*.htm > > bash: /bin/ls: Argument list too long > > > > Also I'd like to know, if this is general Linux VFS, XFS or file-utils implementation restriction/bug or whatever > > It's a general Linux limitation - but nothing related to the number of files > in a directory. By doing a ls CHEPELARE/*.htm you let the shell glob the > filenames and pass all matching ones to /bin/ls. With 30303 html files in > directory these are quite a lot and the resulting array overflows the hardcoded > change for the argument size in the kernel binary loader. The problem can be avoided by not using shell-globbing, and rather do something like: find CHEPELARE -name '*.htm' -ls -- Ragnar Kjørstad From owner-linux-xfs@oss.sgi.com Sun Sep 1 22:05:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 22:05:29 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8255KtG019667 for ; Sun, 1 Sep 2002 22:05:21 -0700 Received: from dialup-63.214.123.53.dial1.boston1.level3.net ([63.214.123.53] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17ljSa-0005ZB-00 by VAauthid with fixed_plain for ; Sun, 01 Sep 2002 22:09:12 -0700 Message-ID: <3D72F267.3030400@osdn.com> Date: Mon, 02 Sep 2002 01:08:55 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Patches Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs Should patches get sent to the mailing list or is there a paticular person that should get them? Brian From owner-linux-xfs@oss.sgi.com Sun Sep 1 23:03:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 23:04:00 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8263stG020652 for ; Sun, 1 Sep 2002 23:03:54 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 XAA02461 for ; Sun, 1 Sep 2002 23:07:44 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA73666 for linux-xfs@oss.sgi.com; Mon, 2 Sep 2002 16:06:27 +1000 (EST) Date: Mon, 2 Sep 2002 16:06:27 +1000 (EST) From: Nathan Scott Message-Id: <200209020606.QAA73666@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - snapshot QA X-archive-position: 201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Sun Sep 1 18:39:23 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126546a linux/fs/xfs/xfs_vnodeops.c - 1.561 - remove local tmp variable "sync_mode" which was accidentally left in on previous checkin. Date: Sun Sep 1 23:04:01 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126551a cmd/xfstests/068 - 1.1 cmd/xfstests/068.out - 1.1 - A LVM snapshot regression test by Greg Freemyer. cmd/xfstests/group - 1.23 - Add in Greg's snapshot test, 068. Also, added 067 back into the auto-qa mix, looks like it wasn't added back after being disabled. From owner-linux-xfs@oss.sgi.com Sun Sep 1 23:34:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 23:34:05 -0700 (PDT) Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g826XotG021335 for ; Sun, 1 Sep 2002 23:33:50 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 4E031C297; Mon, 2 Sep 2002 08:13:11 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA02711; Mon, 2 Sep 2002 08:13:10 +0200 (MET DST) >Received: from tempmail.sauter-bc.com (tempmail [10.1.6.25]) by zuerich.sauter-bc.com (Postfix) with ESMTP id 66315138010; Mon, 2 Sep 2002 08:12:04 +0200 (CEST) Received: from ssba-bsl.cad.sba (ssba-bsl.cad.sba [10.1.6.20]) by tempmail.sauter-bc.com (Postfix) with ESMTP id 290451905E; Mon, 2 Sep 2002 08:11:10 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by ssba-bsl.cad.sba (Postfix) with ESMTP id DA24B30881D; Mon, 2 Sep 2002 08:12:02 +0200 (CEST) Message-ID: <3D730132.2EA14D92@ch.sauter-bc.com> Date: Mon, 02 Sep 2002 08:12:02 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: samba@miratek.com Cc: "'Eric Sandeen'" , linux-xfs@oss.sgi.com Subject: Re: XFS RPM install on Redhat 7.2 References: <000001c250a6$8e79b7d0$967ba8c0@maherxp> Content-Transfer-Encoding: 8bit Content-type: text/plain; charset=us-ascii X-archive-position: 202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Mike schrieb: > > Thanks Eric and Simon, > > I installed 2.4.9-31SGI_1.1smp kernel and everything was OK. I just > noticed one difference, with the newer 2.4.9-34smp kernel, I used to see > 4 CPUs (using top) on our server which is a Compaq ML530G2. This server > have 2 CPUs only. But due to Intel Hyper-Threading technology on the new > Xeon 2.4 GHz processor, the 2.4.9-34smp kernel treats it as 4 CPUs. > > After I installed 2.4.9-31SGI_1.1smp and rebooted I only could see 2 > CPUs which is equal to the physical CPUs count. > > I am going to install kernel-smp-2.4.9-34SGI_XFS_1.1.i686.rpm and > hopefully I will see 4 CPUs. Some how it supposed to be faster with the > 2 CPUs treated as 4 CPUs (?). Hi Mike, 2.4.9-34SGI_XFS_1.1 is _exactly_ the same like original RedHat 2.4.9-34 with only the XFS bits added. So whatever you see, it's the same as you see when using RedHat 2.4.9-34. Simon > > Thanks for your help and the new RPMs. > > Mike > > -----Original Message----- > From: linux-xfs-bounce@oss.sgi.com [mailto:linux-xfs-bounce@oss.sgi.com] > On Behalf Of Eric Sandeen > Sent: Friday, August 30, 2002 5:51 PM > To: Simon Matter > Cc: Mike; linux-xfs@oss.sgi.com > Subject: Re: XFS RPM install on Redhat 7.2 > > Ok, they are there now, in > ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/contribu > ted/2.4.18-34-RH/ > > Sorry it took so long to get them out there, this sort of fell through > the cracks. > > Note that they're contributed, and have not been tested by SGI. > > Thanks Simon! > > -Eric > > On Fri, 2002-08-30 at 00:50, Simon Matter wrote: > > BTW, I have built kernel-smp-2.4.9-34SGI_XFS_1.1.src.rpm packages long > > time ago. Eric, do you remember :) > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Sun Sep 1 23:38:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Sep 2002 23:38:51 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e143.dsl.mediaWays.net [213.20.225.67]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g826cmtG021734 for ; Sun, 1 Sep 2002 23:38:48 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17lkux-0002gg-00 for linux-xfs@oss.sgi.com; Mon, 02 Sep 2002 08:42:35 +0200 Message-ID: <3D73085B.17723A9A@berdmann.de> Date: Mon, 02 Sep 2002 08:42:35 +0200 From: Bernhard Erdmann X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Hi, are there any known problems with this combination? I upgraded a machine to 2.4.18-xfs-1.1 (plain vanilla 2.4.18 + xfs-1.1 patch) and build xfsdump on it using CVS of something last week. sendsize: 5990: getting size via dump for / level 1 sendsize: 5990: running "/usr/libexec/amanda/rundump (xfsdump) -F -J -l 1 - /dev/sdb1" sendsize: 5990: running /usr/libexec/amanda/killpgrp sendsize: 5990: xfsdump: using file dump (drive_simple) strategy sendsize: 5990: xfsdump: version 2.1.5 (dump format 3.0) - Running single-threaded sendsize: 5990: xfsdump: unable to determine uuid of fs mounted at /: Inappropriate ioctl for device sendsize: 5990: xfsdump: ERROR: cannot find earlier dump to base level 1 increment upon sendsize: 5990: xfsdump: Dump Status: ERROR I know you must use xfsdump version > 2 for XFS kernel version >= 2.4.18. From owner-linux-xfs@oss.sgi.com Mon Sep 2 00:16:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 00:16:27 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g827GEtG022917 for ; Mon, 2 Sep 2002 00:16:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 AAA01564 for ; Mon, 2 Sep 2002 00:20:05 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24656; Mon, 2 Sep 2002 17:18:47 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) with ESMTP id g827IQGj003205; Mon, 2 Sep 2002 17:18:26 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) id g827IPa3003203; Mon, 2 Sep 2002 17:18:25 +1000 Date: Mon, 2 Sep 2002 17:18:25 +1000 From: Nathan Scott To: Bernhard Erdmann Cc: Linux XFS Mailing List Subject: Re: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" Message-ID: <20020902071825.GB2563@frodo> References: <3D73085B.17723A9A@berdmann.de> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D73085B.17723A9A@berdmann.de> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-archive-position: 204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Sep 02, 2002 at 08:42:35AM +0200, Bernhard Erdmann wrote: > > Hi, > > are there any known problems with this combination? I upgraded a machine > to 2.4.18-xfs-1.1 (plain vanilla 2.4.18 + xfs-1.1 patch) and build > xfsdump on it using CVS of something last week. > > sendsize: 5990: getting size via dump for / level 1 > sendsize: 5990: running "/usr/libexec/amanda/rundump (xfsdump) -F -J -l > 1 - /dev/sdb1" > sendsize: 5990: running /usr/libexec/amanda/killpgrp > sendsize: 5990: xfsdump: using file dump (drive_simple) strategy > sendsize: 5990: xfsdump: version 2.1.5 (dump format 3.0) - Running > single-threaded > sendsize: 5990: xfsdump: unable to determine uuid of fs mounted at /: > Inappropriate ioctl for device > sendsize: 5990: xfsdump: ERROR: cannot find earlier dump to base level 1 > increment upon > sendsize: 5990: xfsdump: Dump Status: ERROR > > I know you must use xfsdump version > 2 for XFS kernel version >= > 2.4.18. I suspect this is due to the changes to the XFS_GEOMETRY ioctl which happened at some point since 1.1 release, which was done to support the new log format. Basically, if you compile xfsdump against the xfsprogs headers from xfsprogs in 1.1 it should work, but if you compile xfsdump against CVS header files it will use the new geometry ioctl, which was not supported by the 1.1 kernel code and hence the "Inappropriate ioctl" error. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 2 00:19:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 00:19:59 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g827JvtG023224 for ; Mon, 2 Sep 2002 00:19:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 AAA04036 for ; Mon, 2 Sep 2002 00:23:48 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24686; Mon, 2 Sep 2002 17:22:30 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) with ESMTP id g827M9Gj003242; Mon, 2 Sep 2002 17:22:09 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) id g827M9CX003240; Mon, 2 Sep 2002 17:22:09 +1000 Date: Mon, 2 Sep 2002 17:22:08 +1000 From: Nathan Scott To: Brian Pontz Cc: linux-xfs@oss.sgi.com Subject: Re: Patches Message-ID: <20020902072208.GC2563@frodo> References: <3D72F267.3030400@osdn.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D72F267.3030400@osdn.com> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-archive-position: 205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs hi, On Mon, Sep 02, 2002 at 01:08:55AM -0400, Brian Pontz wrote: > > Should patches get sent to the mailing list or is there a paticular > person that should get them? All the XFS folks are listening on the list - if you send to an individual it may be some time before they get a chance to look into it. So, you may as well send any patches to the list. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 2 01:32:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 01:32:34 -0700 (PDT) Received: from sisko.scot.redhat.com (pc-80-195-6-65-ed.blueyonder.co.uk [80.195.6.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g828WTtG024949 for ; Mon, 2 Sep 2002 01:32:30 -0700 Received: (from sct@localhost) by sisko.scot.redhat.com (8.11.6/8.11.2) id g828YtA02653; Mon, 2 Sep 2002 09:34:55 +0100 Date: Mon, 2 Sep 2002 09:34:54 +0100 From: "Stephen C. Tweedie" To: Christoph Hellwig Cc: root@larry.minfin.government.bg.sgi.com, linux-xfs@oss.sgi.com Subject: Re: Max file number in single directory Message-ID: <20020902093454.A2507@redhat.com> References: <20020901223911.13399.qmail@larry.minfin.government.bg> <20020901235658.A13582@infradead.org> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020901235658.A13582@infradead.org>; from hch@infradead.org on Sun, Sep 01, 2002 at 11:56:58PM +0100 Content-Transfer-Encoding: 8bit X-archive-position: 206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Hi, On Sun, Sep 01, 2002 at 11:56:58PM +0100, Christoph Hellwig wrote: > > root@larry:~/phones/new_scripts# ls CHEPELARE/*.htm > > bash: /bin/ls: Argument list too long > > root@larry:~/phones/new_scripts# ls CHEPELARE/ |wc -l > > 30303 > It's a general Linux limitation - but nothing related to the number of files > in a directory. By doing a ls CHEPELARE/*.htm you let the shell glob the > filenames and pass all matching ones to /bin/ls. With 30303 html files in > directory these are quite a lot and the resulting array overflows the hardcoded > change for the argument size in the kernel binary loader. ... so you need to chop the argument list up into smaller chunks. You can do that easily with "find" and "xargs". Find will list the given files, including doing "*" filename glob matching, and xargs will take a stream of arguments on its standard input and pass them, one chunk at a time, to some command as arguments: find CHEPELARE -name "*.htm" | xargs ls or, if there are oddly-named files in the tree which might otherwise confuse xargs (eg. files with spaces in their names), you can use the more-reliable null-terminated form to pass the find output to xargs: find CHEPELARE -name "*.htm" -print0 | xargs -0 ls That's not _quite_ the same as your original ls, because the find will recurse many directories deep --- use the "-maxdepth" argument to find to prevent that --- and because ls's field formatting may get reset each time xargs starts it up again. But it's the most reliable way of running some command over an arbitrarily long list of files. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Sep 2 03:37:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 03:37:39 -0700 (PDT) Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82AbYtG004341 for ; Mon, 2 Sep 2002 03:37:35 -0700 Received: from online.no (81.80-202-103.nextgentel.com [80.202.103.81]) by mail.broadpark.no (Postfix) with ESMTP id 665AE7F80 for ; Mon, 2 Sep 2002 12:41:21 +0200 (MEST) Message-ID: <3D734045.F800F83B@online.no> Date: Mon, 02 Sep 2002 12:41:10 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10custom-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: patch for linux-2.4.18-10 based on XFS 1.1 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs I have made a patch for redhat latest update kernel 2.4.18-10, and it is at http://members.tripod.com/knutjorgen/patch/xfs-2.4.18.10.patch. This patch contain xfs-kernel, only, misc, acl, xattr for linux 2.4.18-10. From owner-linux-xfs@oss.sgi.com Mon Sep 2 03:49:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 03:49:41 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82AnUtG004897 for ; Mon, 2 Sep 2002 03:49:36 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g82ArLCY062313; Mon, 2 Sep 2002 12:53:21 +0200 (CEST) Message-Id: <4.3.2.7.2.20020902125151.02c959d0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Sep 2002 12:52:10 +0200 To: Knut J Bjuland , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: patch for linux-2.4.18-10 based on XFS 1.1 In-Reply-To: <3D734045.F800F83B@online.no> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:41 2-9-2002 +0200, Knut J Bjuland wrote: >I have made a patch for redhat latest update kernel 2.4.18-10, and it is >at http://members.tripod.com/knutjorgen/patch/xfs-2.4.18.10.patch. This >patch contain xfs-kernel, only, misc, acl, xattr for linux 2.4.18-10. It doesn't work. The link that is. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Sep 2 04:30:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 04:30:28 -0700 (PDT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82BUCtG006115 for ; Mon, 2 Sep 2002 04:30:13 -0700 Received: from online.no (81.80-202-103.nextgentel.com [80.202.103.81]) by mail.broadpark.no (Postfix) with ESMTP id 699117FFA; Mon, 2 Sep 2002 13:33:55 +0200 (MEST) Message-ID: <3D734C96.5C34853A@online.no> Date: Mon, 02 Sep 2002 13:33:42 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-10custom-XFS i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: patch for linux-2.4.18-10 based on XFS 1.1 References: <4.3.2.7.2.20020902125151.02c959d0@pop.xs4all.nl> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knutjbj@online.no Precedence: bulk X-list: linux-xfs Seth Mos wrote: > At 12:41 2-9-2002 +0200, Knut J Bjuland wrote: > > >I have made a patch for redhat latest update kernel 2.4.18-10, and it is > >at http://members.tripod.com/knutjorgen/patch/xfs-2.4.18.10.patch. This > >patch contain xfs-kernel, only, misc, acl, xattr for linux 2.4.18-10. > > It doesn't work. The link that is. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. sorry http://members.tripod.com/knutjorgen/patch/xfs-2.4.18-10.patch . From owner-linux-xfs@oss.sgi.com Mon Sep 2 05:34:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 05:34:34 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82CYRtG007335 for ; Mon, 2 Sep 2002 05:34:28 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g82Cbt7s075369; Mon, 2 Sep 2002 14:37:55 +0200 (CEST) Message-Id: <4.3.2.7.2.20020902143557.0383d488@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Sep 2002 14:36:40 +0200 To: Knut J Bjuland From: Seth Mos Subject: Re: patch for linux-2.4.18-10 based on XFS 1.1 Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D734C96.5C34853A@online.no> References: <4.3.2.7.2.20020902125151.02c959d0@pop.xs4all.nl> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 13:33 2-9-2002 +0200, Knut J Bjuland wrote: >Seth Mos wrote: > > > At 12:41 2-9-2002 +0200, Knut J Bjuland wrote: > > > > >I have made a patch for redhat latest update kernel 2.4.18-10, and it is > > >at http://members.tripod.com/knutjorgen/patch/xfs-2.4.18.10.patch. This > > >patch contain xfs-kernel, only, misc, acl, xattr for linux 2.4.18-10. > > > > It doesn't work. The link that is. > >sorry http://members.tripod.com/knutjorgen/patch/xfs-2.4.18-10.patch . If the Tripod page is not getting along you can also fetch it here: http://iserv.nl/files/xfs/patches/ Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Sep 2 05:58:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 05:58:59 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82CwptG008034 for ; Mon, 2 Sep 2002 05:58:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA71707 for ; Mon, 2 Sep 2002 08:02:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA77390 for ; Mon, 2 Sep 2002 08:02:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g82D1dx32301; Mon, 2 Sep 2002 08:01:39 -0500 Message-Id: <200209021301.g82D1dx32301@jen.americas.sgi.com> Date: Mon, 2 Sep 2002 08:01:39 -0500 Subject: TAKE - make xfs_link static To: linux-xfs@oss.sgi.com X-archive-position: 211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs More cleanup Date: Mon Sep 2 06:01:45 PDT 2002 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:126557a linux/fs/xfs/xfs_vnodeops.c - 1.562 linux/fs/xfs/xfs_utils.h - 1.25 From owner-linux-xfs@oss.sgi.com Mon Sep 2 06:03:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 06:03:49 -0700 (PDT) Received: from msrv.minfin.govrn.bg ([212.122.164.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82D2utG008568 for ; Mon, 2 Sep 2002 06:03:42 -0700 Received: from larry2 ([192.168.4.21]) by msrv.minfin.govrn.bg (Netscape Messaging Server 3.62) with SMTP id 87 for ; Mon, 2 Sep 2002 15:33:47 +0300 Reply-To: From: "Kostadin Karaivanov" To: Subject: Date: Mon, 2 Sep 2002 15:34:55 +0300 Message-ID: <009b01c2527d$24507f00$1504a8c0@larry2> MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-archive-position: 212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@minfin.government.bg Precedence: bulk X-list: linux-xfs ... so you need to chop the argument list up into >>smaller chunks. You can do that easily with "find" and "xargs". Find will list the given files, including doing "*" >filename glob matching, and xargs will take a stream of arguments on its standard input and pass them, one chunk at a time, to some command as arguments: find CHEPELARE -name "*.htm" | xargs ls or, if there are oddly-named files in the tree which might otherwise confuse xargs (eg. files with spaces in their names), you can use the more-reliable null-terminated form to pass the find output to xargs: find CHEPELARE -name "*.htm" -print0 | xargs -0 ls That's not _quite_ the same as your original ls, because the find will recurse many directories deep --- use the "-maxdepth" argument to find to prevent that --- and because ls's field formatting may get reset each time xargs starts it up again. But it's the most reliable way of running some command over an arbitrarily long list of files. Cheers, Stephen :-)) When the culprit is known (my ignorance) to find the solution is easy. The find/xargs combination seems most robust to me, althou I beleave that find CHEPELARE / -name *.htm -exec ls {} \; (or cat {} \;) will work also...... -maxdepth is not needed in my case, couse CHEPELARE/ is no-leaf directory Thanks again for all answers and clarifications Kostadin Karaivanov Senior System Administrator @ Ministry Of Finace tel: +359 2 98592062 larry@minfin.government.bg From owner-linux-xfs@oss.sgi.com Mon Sep 2 06:09:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 06:09:49 -0700 (PDT) Received: from sisko.scot.redhat.com (pc-80-195-6-65-ed.blueyonder.co.uk [80.195.6.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82D9ktG009145 for ; Mon, 2 Sep 2002 06:09:47 -0700 Received: (from sct@localhost) by sisko.scot.redhat.com (8.11.6/8.11.2) id g82DDUx06766; Mon, 2 Sep 2002 14:13:30 +0100 Date: Mon, 2 Sep 2002 14:13:30 +0100 From: "Stephen C. Tweedie" To: Kostadin Karaivanov Cc: linux-xfs@oss.sgi.com Subject: Re: your mail Message-ID: <20020902141330.G2507@redhat.com> References: <009b01c2527d$24507f00$1504a8c0@larry2> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <009b01c2527d$24507f00$1504a8c0@larry2>; from larry@minfin.government.bg on Mon, Sep 02, 2002 at 03:34:55PM +0300 Content-Transfer-Encoding: 8bit X-archive-position: 213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sct@redhat.com Precedence: bulk X-list: linux-xfs Hi, On Mon, Sep 02, 2002 at 03:34:55PM +0300, Kostadin Karaivanov wrote: > :-)) When the culprit is known (my ignorance) to find the solution is easy. > The find/xargs combination seems most robust to me, althou I beleave that > find CHEPELARE / -name *.htm -exec ls {} \; (or cat {} \;) will work > also...... Ewww. That will fork and exec a new copy of "ls" for every file it finds. For a 30000-file directory, that will be *expensive*. xargs is far more efficient. Cheers, Stephen From owner-linux-xfs@oss.sgi.com Mon Sep 2 07:02:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 07:03:03 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82E2vtG012536 for ; Mon, 2 Sep 2002 07:02:58 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17lrr4-000061-00; Mon, 02 Sep 2002 08:07:03 -0600 Message-ID: <3D737061.6030407@emergence.com> Date: Mon, 02 Sep 2002 08:06:25 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" References: <3D73085B.17723A9A@berdmann.de> <20020902071825.GB2563@frodo> <3D73307A.5000309@emergence.com> <20020902205459.A86944@wobbly.melbourne.sgi.com> Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-archive-position: 214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Well I initially installed via Gentoo, which I believe was based on 1.1 code (April 2002). I was just hoping to dump and restore this filesystem onto an identical adjacent (move from hda8 to hda7) in order to grow hda7 to the entire size of the two partitions. But I guess either I didn't compile the utils right or the filesystem on disk is still in the older V1 format. This if for no other reason would be a good reason for a point release that contains the V2Log code, if the future utilities aren't going to be able to cope with V1. Or is there an easy way to convert? -Mike Nathan Scott wrote: > On Mon, Sep 02, 2002 at 03:33:46AM -0600, Michael Best wrote: > >>Nathan Scott wrote: >> >>>Basically, if you compile xfsdump against the xfsprogs headers >>>from xfsprogs in 1.1 it should work, but if you compile xfsdump >>>against CVS header files it will use the new geometry ioctl, >>>which was not supported by the 1.1 kernel code and hence the >>>"Inappropriate ioctl" error. >> >>Odd I had the same error. I am using a 2.4.19+20020825 kernel and the >>latest tools. Do I need older tools, an older kernel, or a newer kernel >>still? :) > > > Hmm... are you sure you are running that recent a kernel? > v2 log support went in on 2002/06/18 and I don't understand > how this error would be generated from a current kernel... > perhaps I'm overlooking something though. My tests don't > seem to produce any errors of this kind. > > cheers. From owner-linux-xfs@oss.sgi.com Mon Sep 2 10:17:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 10:17:11 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e12d.dsl.mediaWays.net [213.20.225.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82HH5tG017362 for ; Mon, 2 Sep 2002 10:17:06 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17lusg-0003j9-00; Mon, 02 Sep 2002 19:20:54 +0200 Message-ID: <3D739DF6.74D678FF@berdmann.de> Date: Mon, 02 Sep 2002 19:20:54 +0200 From: Bernhard Erdmann X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nathan Scott CC: Linux XFS Mailing List Subject: Re: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" References: <3D73085B.17723A9A@berdmann.de> <20020902071825.GB2563@frodo> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Nathan Scott wrote: [...] > Basically, if you compile xfsdump against the xfsprogs headers > from xfsprogs in 1.1 it should work, but if you compile xfsdump > against CVS header files it will use the new geometry ioctl, > which was not supported by the 1.1 kernel code and hence the > "Inappropriate ioctl" error. Yes, I compiled CVS xfsdump on CVS kernel end of last week, but now I use 2.4.8-xfs-1.1. Sorry not to mention this detail. I'll check it out. From owner-linux-xfs@oss.sgi.com Mon Sep 2 11:24:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 11:24:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82IO6tG018400 for ; Mon, 2 Sep 2002 11:24:07 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA72486; Mon, 2 Sep 2002 13:27:55 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-34.corp.sgi.com [134.15.64.34]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA90249; Mon, 2 Sep 2002 13:27:54 -0500 (CDT) Subject: Re: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" From: Stephen Lord To: Bernhard Erdmann Cc: Nathan Scott , Linux XFS Mailing List In-Reply-To: <3D739DF6.74D678FF@berdmann.de> References: <3D73085B.17723A9A@berdmann.de> <20020902071825.GB2563@frodo> <3D739DF6.74D678FF@berdmann.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 02 Sep 2002 13:26:30 -0500 Message-Id: <1030991193.1498.1.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-02 at 12:20, Bernhard Erdmann wrote: > Nathan Scott wrote: > [...] > > Basically, if you compile xfsdump against the xfsprogs headers > > from xfsprogs in 1.1 it should work, but if you compile xfsdump > > against CVS header files it will use the new geometry ioctl, > > which was not supported by the 1.1 kernel code and hence the > > "Inappropriate ioctl" error. > > Yes, I compiled CVS xfsdump on CVS kernel end of last week, but now I > use 2.4.8-xfs-1.1. Sorry not to mention this detail. I'll check it out. > When the new commands came out, they did start using a new interface which was versioned for the v2 log code. The old commands will work with a new kernel, but the new commands will not work with an old one. When you build commands, the installed kernel has nothing to do with which version of the system calls the commands will use. So, use older commands with an old kernel, or use a newer kernel. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 2 11:25:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 11:25:24 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e12d.dsl.mediaWays.net [213.20.225.45]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g82IPLtG018653 for ; Mon, 2 Sep 2002 11:25:22 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17lvwl-0004wN-00; Mon, 02 Sep 2002 20:29:11 +0200 Message-ID: <3D73ADF7.5BF35A08@berdmann.de> Date: Mon, 02 Sep 2002 20:29:11 +0200 From: Bernhard Erdmann X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Nathan Scott CC: Linux XFS Mailing List Subject: Re: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" References: <3D73085B.17723A9A@berdmann.de> <20020902071825.GB2563@frodo> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs Nathan Scott wrote: [...] > Basically, if you compile xfsdump against the xfsprogs headers > from xfsprogs in 1.1 it should work, but if you compile xfsdump > against CVS header files it will use the new geometry ioctl, > which was not supported by the 1.1 kernel code and hence the > "Inappropriate ioctl" error. It did the trick. Using xfsprogs-2.0.3 and xfsprogs-devel-2.0.3 of xfs-1.1 to compile CVS xfsdump lets this xfsdump 2.1.5 work on kernel-2.4.18-xfs-1.1. Many thanks for your quick help! From owner-linux-xfs@oss.sgi.com Mon Sep 2 17:14:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 17:14:28 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g830ENtG023034 for ; Mon, 2 Sep 2002 17:14:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 RAA07045 for ; Mon, 2 Sep 2002 17:18:17 -0700 (PDT) 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 KAA00387; Tue, 3 Sep 2002 10:17:01 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA88169; Tue, 3 Sep 2002 10:17:00 +1000 (AEDT) Date: Tue, 3 Sep 2002 10:16:59 +1000 From: Nathan Scott To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump 2.1.5, kernel 2.4.18-xfs-1.1, "unable to determine uuid of fs mounted at /" Message-ID: <20020903101659.C87986@wobbly.melbourne.sgi.com> References: <3D73085B.17723A9A@berdmann.de> <20020902071825.GB2563@frodo> <3D73307A.5000309@emergence.com> <20020902205459.A86944@wobbly.melbourne.sgi.com> <3D737061.6030407@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D737061.6030407@emergence.com>; from mbest@emergence.com on Mon, Sep 02, 2002 at 08:06:25AM -0600 X-archive-position: 218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs hi, On Mon, Sep 02, 2002 at 08:06:25AM -0600, Michael Best wrote: > Well I initially installed via Gentoo, which I believe was based on 1.1 > code (April 2002). OK, so I expect that version would fail with the current tools. (but that is not kernel 2.4.19+20020825 though, right?) > I was just hoping to dump and restore this filesystem onto an identical > adjacent (move from hda8 to hda7) in order to grow hda7 to the entire > size of the two partitions. > > But I guess either I didn't compile the utils right or the filesystem on > disk is still in the older V1 format. This problem is more to do with ioctl versions that ondisk formats. > This if for no other reason would be a good reason for a point release > that contains the V2Log code, if the future utilities aren't going to be > able to cope with V1. Or is there an easy way to convert? No other way to convert the ondisk format - mkfs is it; but this is not an ondisk format problem, its an ioctl version problem. We can do a better job than we currently are in this kernel <-> userspace interaction - I will checkin some changes later today which should allow all the tools to work with both new and old kernels. cheers. > Nathan Scott wrote: > > On Mon, Sep 02, 2002 at 03:33:46AM -0600, Michael Best wrote: > > > >>Nathan Scott wrote: > >> > >>>Basically, if you compile xfsdump against the xfsprogs headers > >>>from xfsprogs in 1.1 it should work, but if you compile xfsdump > >>>against CVS header files it will use the new geometry ioctl, > >>>which was not supported by the 1.1 kernel code and hence the > >>>"Inappropriate ioctl" error. > >> > >>Odd I had the same error. I am using a 2.4.19+20020825 kernel and the > >>latest tools. Do I need older tools, an older kernel, or a newer kernel > >>still? :) > > > > > > Hmm... are you sure you are running that recent a kernel? > > v2 log support went in on 2002/06/18 and I don't understand > > how this error would be generated from a current kernel... > > perhaps I'm overlooking something though. My tests don't > > seem to produce any errors of this kind. > > > > cheers. > > -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 2 17:25:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 17:25:05 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g830P3tG023955 for ; Mon, 2 Sep 2002 17:25:03 -0700 Received: from dialup-63.214.123.137.dial1.boston1.level3.net ([63.214.123.137] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17m1Yv-0002A0-00 by VAauthid with fixed_plain for ; Mon, 02 Sep 2002 17:28:57 -0700 Message-ID: <3D74023E.1010208@osdn.com> Date: Mon, 02 Sep 2002 20:28:46 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] Kernel janitor cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs http://www.axehind.com/xfs/xfs-cleanup-1-linux-2.4.patch The patch is mainly a partial janitor patch. Brian From owner-linux-xfs@oss.sgi.com Mon Sep 2 18:53:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 18:53:44 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g831rbtG025827 for ; Mon, 2 Sep 2002 18:53:37 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.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 SAA02657 for ; Mon, 2 Sep 2002 18:57:32 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g831uUpx20314695; Mon, 2 Sep 2002 18:56:31 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 099E8300087; Tue, 3 Sep 2002 11:56:29 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id B2E3D97; Tue, 3 Sep 2002 11:56:29 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Brian Pontz Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup In-reply-to: Your message of "Mon, 02 Sep 2002 20:28:46 -0400." <3D74023E.1010208@osdn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 Sep 2002 11:56:24 +1000 Message-ID: <3214.1031018184@kao2.melbourne.sgi.com> X-archive-position: 220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 02 Sep 2002 20:28:46 -0400, Brian Pontz wrote: >http://www.axehind.com/xfs/xfs-cleanup-1-linux-2.4.patch > >The patch is mainly a partial janitor patch. Given Linus's recent comments about code style, I can understand the changes from 'return(foo);' to 'return foo;'. But why change 'int i' to 'uint i'? From owner-linux-xfs@oss.sgi.com Mon Sep 2 19:16:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 19:16:44 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g832GdtG027069 for ; Mon, 2 Sep 2002 19:16:39 -0700 Received: from dialup-63.214.123.137.dial1.boston1.level3.net ([63.214.123.137] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17m3Iv-0008M3-00 by VAauthid with fixed_plain; Mon, 02 Sep 2002 19:20:34 -0700 Message-ID: <3D741C60.8020900@osdn.com> Date: Mon, 02 Sep 2002 22:20:16 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Keith Owens CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup References: <3214.1031018184@kao2.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs I was reading the kerneljanitors TODO list at http://www.kerneljanitors.org/TODO From: Jeff Garzik 1) "unsigned int" is preferred to "int", it generates better asm code on all platforms except sh5. This replacement needs to be done manually, because often 'int' is required due to negative values -Exxx commonly passed as error values. If this is unwanted in the xfs code let me know. Brian Keith Owens wrote: >On Mon, 02 Sep 2002 20:28:46 -0400, >Brian Pontz wrote: > >>http://www.axehind.com/xfs/xfs-cleanup-1-linux-2.4.patch >> >>The patch is mainly a partial janitor patch. >> > >Given Linus's recent comments about code style, I can understand the >changes from 'return(foo);' to 'return foo;'. But why change 'int i' >to 'uint i'? > From owner-linux-xfs@oss.sgi.com Mon Sep 2 19:21:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Sep 2002 19:21:34 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g832LWtG027857 for ; Mon, 2 Sep 2002 19:21:33 -0700 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.55.176]) by deliverator.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 TAA08044 for ; Mon, 2 Sep 2002 19:25:27 -0700 (PDT) mail_from (nathans@bruce.melbourne.sgi.com) Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.9.3/8.9.3) id MAA02579 for linux-xfs@oss.sgi.com; Tue, 3 Sep 2002 12:25:26 +1000 Date: Tue, 3 Sep 2002 12:25:26 +1000 From: Nathan Scott Message-Id: <200209030225.MAA02579@bruce.melbourne.sgi.com> Subject: TAKE - ioctl compatibility X-archive-position: 222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs These changes aim to make all the tools behave more gracefully in the presence of old kernels which don't support the latest XFS_IOC_FSGEOMETRY ioctl. For the most part, the earlier verion of the ioctl has all the info the tools need. xfs_growfs was a bit more involved, but still should work fine with all kernels. Note - xfsdump needs autoconf to be re-run, so "make distclean". cheers. Date: Mon Sep 2 18:17:30 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/local-xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:126561a attr/Makefile - 1.9 xfstests/Makefile - 1.7 dmapi/Makefile - 1.8 - Do a better job of cleaning up after autoconf. Date: Mon Sep 2 19:15:45 PDT 2002 Workarea: bruce.melbourne.sgi.com:/home/nathans/isms/local-xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:126562a xfsdump/include/config.h.in - 1.1 - interfaces configure script to source code - initial version holds info about versioning of ioctl interfaces from XFS headers. xfsdump/Makefile - 1.10 xfsprogs/Makefile - 1.14 - do some additional cleanup after autoconf has run. xfsdump/VERSION - 1.39 xfsdump/doc/CHANGES - 1.47 xfsdump/debian/changelog - 1.30 xfsprogs/VERSION - 1.55 xfsprogs/doc/CHANGES - 1.80 xfsprogs/debian/changelog - 1.51 - bump version document changes - mainly relating to ioctl versions. xfsdump/configure.in - 1.23 xfsprogs/bmap/xfs_bmap.c - 1.10 xfsprogs/rtcp/xfs_rtcp.c - 1.8 xfsdump/common/fs.c - 1.6 xfsdump/common/util.c - 1.11 xfsdump/fsr/xfs_fsr.c - 1.12 - geometry ioctl versioning changes. xfsprogs/mkfs/xfs_mkfs.c - 1.35 - don't display the message about lsu/lsunit causing v2 log use if version 2 logs have been specifically requested. xfsprogs/growfs/xfs_growfs.c - 1.14 - geometry ioctl versioning changes. trickier than most - we first try the latest version ioctl, if that fails, we back off and try the earlier version, and only if that fails do we exit. xfsdump/include/Makefile - 1.8 - add in new file - config.h.in. From owner-linux-xfs@oss.sgi.com Tue Sep 3 00:33:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 00:33:59 -0700 (PDT) Received: from mail.takas.lt (mail-src.takas.lt [212.59.31.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g837XqtG002836 for ; Tue, 3 Sep 2002 00:33:53 -0700 Received: from egis ([212.59.17.210]) by mail.takas.lt with Microsoft SMTPSVC(5.0.2195.5329); Tue, 3 Sep 2002 09:37:39 +0200 Message-ID: <002201c2531c$ca1cccf0$4c00000a@lukoil.lt> From: "Egidijus Antanaitis" To: Subject: Date: Tue, 3 Sep 2002 09:37:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 03 Sep 2002 07:37:39.0294 (UTC) FILETIME=[C79CFFE0:01C2531C] X-archive-position: 223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: antaegid@takas.lt Precedence: bulk X-list: linux-xfs Dear support, recently I got stuck with such a problem. OS - Linux RedHat 7.3, kernel 2.4.18. Hardware - Intel Desktop Board D845BG motherboard, Pentium 4 processor, HDD's Maxtor d740x-6l. Because of a bug in motherboard, the system often freezes. I have found, the Alan's Cox patch 2.4.19-ac3 has the workaround according to this, but when I do apply it, the xfs patch doesn't work correctly any more. Also, I cannot apply the xfs patch to newest RedHat's 2.4.18-10 kernel source. I got a lot of rejects in both cases. XFS has not a xfs patch to 2.4.19 kernel, hence I am stuck. Is any solution here? Thanks for any help:) Sincerely, Egidijus Antanaitis From owner-linux-xfs@oss.sgi.com Tue Sep 3 01:51:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 01:51:10 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g838p3tG010885 for ; Tue, 3 Sep 2002 01:51:04 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17m9Sc-00009G-00; Tue, 03 Sep 2002 09:54:58 +0100 Date: Tue, 3 Sep 2002 09:54:58 +0100 From: Christoph Hellwig To: Brian Pontz Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup Message-ID: <20020903095458.A551@infradead.org> References: <3D74023E.1010208@osdn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D74023E.1010208@osdn.com>; from brian.pontz@osdn.com on Mon, Sep 02, 2002 at 08:28:46PM -0400 X-archive-position: 224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Mon, Sep 02, 2002 at 08:28:46PM -0400, Brian Pontz wrote: > http://www.axehind.com/xfs/xfs-cleanup-1-linux-2.4.patch > > The patch is mainly a partial janitor patch. The return cleanups make sense, that was inconsisten even inside XFS. I'm not entirely sure wheter the int->uint stuff makes sense. Have you seen differences in the generated assembly? The set_current_state patch is wrong, it adds another unnessecary test. But that piece of code is rather wrong anyway and sets the states in the wrong places. Using wait_event() cleans up the code more and gets it right: Index: fs/xfs/xfs_inode.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c,v retrieving revision 1.348 diff -u -p -r1.348 xfs_inode.c --- fs/xfs/xfs_inode.c 2002/09/01 12:43:34 1.348 +++ fs/xfs/xfs_inode.c 2002/09/03 08:49:50 @@ -2579,7 +2579,6 @@ xfs_iunpin_wait( { xfs_inode_log_item_t *iip; xfs_lsn_t lsn; - DECLARE_WAITQUEUE(wait, current); ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE | MR_ACCESS)); @@ -2599,15 +2598,7 @@ xfs_iunpin_wait( */ xfs_log_force(ip->i_mount, lsn, XFS_LOG_FORCE); - add_wait_queue(&ip->i_ipin_wait, &wait); -repeat: - set_current_state(TASK_UNINTERRUPTIBLE); - if (atomic_read(&ip->i_pincount)) { - schedule(); - goto repeat; - } - remove_wait_queue(&ip->i_ipin_wait, &wait); - current->state = TASK_RUNNING; + wait_event(ip->i_ipin_wait, (atomic_read(&ip->i_pincount) == 0)); } From owner-linux-xfs@oss.sgi.com Tue Sep 3 03:54:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 03:54:57 -0700 (PDT) Received: from flush (ptr-207-54-119-33.ptr.terago.ca [207.54.119.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83AsotG019736 for ; Tue, 3 Sep 2002 03:54:50 -0700 Message-Id: <200209031054.g83AsotG019736@oss.sgi.com> From: NFLPicks@NFLPredicitions.no-ip.com.sgi.com To: linux-xfs@oss.sgi.com Subject: =?ISO-8859-7?Q?New=20York=20Giants=20cover=20the=20spread=20VS=2E=20The=20San=20Francisco=2049er=A2s=20this=20Thursday=2E=2E=2E?= Date: Tue, 3 Sep 2002 05:24:56 -0500 MIME-Version: 1.0 (produced by Synapse) x-mailer: Synapse - Delphi & Kylix TCP/IP library by Lukas Gebauer Content-type: text/plain; charset=ISO-8859-7 Content-Disposition: inline Content-Description: Message text Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by oss.sgi.com id g83AsptG019738 X-archive-position: 225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: NFLPicks@NFLPredicitions.no-ip.com.sgi.com Precedence: bulk X-list: linux-xfs New York Giants cover the spread VS. The San Francisco 49er¢s this Thursday_ So predicts the NFL betting system I¢ve developed. Enjoy this pick on the house and feel free to contact the link below for more on using this system for yourself. http://nflpredictions.no-ip.com This prediction is by no means a guarantee of the outcome. Gamble at your own risk! From owner-linux-xfs@oss.sgi.com Tue Sep 3 05:04:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 05:04:17 -0700 (PDT) Received: from burgers.bubbanfriends.org (IDENT:postfix@dhcp024-208-195-177.indy.rr.com [24.208.195.177]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83C3ltG021423 for ; Tue, 3 Sep 2002 05:04:10 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 49EEB4001A1; Tue, 3 Sep 2002 07:07:27 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 2DF3E4001A0; Tue, 3 Sep 2002 07:07:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id F3D0AC026B6; Tue, 3 Sep 2002 07:07:23 -0500 (EST) Date: Tue, 3 Sep 2002 07:07:23 -0500 (EST) From: Mike Burger To: Egidijus Antanaitis Cc: linux-xfs@oss.sgi.com Subject: Re: your mail In-Reply-To: <002201c2531c$ca1cccf0$4c00000a@lukoil.lt> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mburger@bubbanfriends.org Precedence: bulk X-list: linux-xfs Can't you download/install an updated BIOS from the mainboard manufacturer? On Tue, 3 Sep 2002, Egidijus Antanaitis wrote: > Dear support, > recently I got stuck with such a problem. OS - Linux RedHat 7.3, kernel > 2.4.18. Hardware - Intel Desktop Board D845BG motherboard, Pentium 4 > processor, HDD's Maxtor d740x-6l. Because of a bug in motherboard, the > system often freezes. I have found, the Alan's Cox patch 2.4.19-ac3 has the > workaround according to this, but when I do apply it, the xfs patch doesn't > work correctly any more. Also, I cannot apply the xfs patch to newest > RedHat's 2.4.18-10 kernel source. I got a lot of rejects in both cases. XFS > has not a xfs patch to 2.4.19 kernel, hence I am stuck. Is any solution > here? Thanks for any help:) > > Sincerely, > Egidijus Antanaitis > > > From owner-linux-xfs@oss.sgi.com Tue Sep 3 05:28:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 05:29:03 -0700 (PDT) Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83CSotG022364 for ; Tue, 3 Sep 2002 05:28:51 -0700 Received: from m2vwall5.wipro.com (m2vwall5.wipro.com [10.115.50.5]) by wiprom2mx1.wipro.com (8.11.3/8.11.3) with SMTP id g83CWfi05681 for ; Tue, 3 Sep 2002 18:02:42 +0530 (IST) Received: from m3uwin ([10.114.11.103]) by sarovar.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id H1V46C00.BUW for ; Tue, 3 Sep 2002 18:02:36 +0530 Message-ID: <00ac01c25346$cea919c0$670b720a@wipro.com> From: "Saji Kumar VR" To: Subject: How can I become a part of XFS development team Date: Tue, 3 Sep 2002 18:08:29 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-97e7ffa6-b4c0-11d6-ba7c-006067005148" 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 X-archive-position: 227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: saji.kumar@wipro.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------=_NextPartTM-000-97e7ffa6-b4c0-11d6-ba7c-006067005148 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C25374.E825D360" ------=_NextPart_000_00A9_01C25374.E825D360 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I would like to know about this project, like what are the future plans? C= an I join the development team? what are the current activities going on... =20 Thanks & Rgds, Saji ------=_NextPart_000_00A9_01C25374.E825D360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
 I would like to know about this proj= ect, like=20 what are the future plans? Can I join the development team?
 what are the current activities goin= g=20 on...
 
Thanks & Rgds,
Saji

 

------=_NextPart_000_00A9_01C25374.E825D360-- ------=_NextPartTM-000-97e7ffa6-b4c0-11d6-ba7c-006067005148-- From owner-linux-xfs@oss.sgi.com Tue Sep 3 06:38:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 06:38:28 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83DcNtG024076 for ; Tue, 3 Sep 2002 06:38:23 -0700 Received: from dialup-63.214.121.72.dial1.boston1.level3.net ([63.214.121.72] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17mDwa-0006Ic-00 by VAauthid with fixed_plain; Tue, 03 Sep 2002 06:42:12 -0700 Message-ID: <3D74BC27.7080304@osdn.com> Date: Tue, 03 Sep 2002 09:41:59 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup References: <3D74023E.1010208@osdn.com> <20020903095458.A551@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs > > >The return cleanups make sense, that was inconsisten even inside XFS. >I'm not entirely sure wheter the int->uint stuff makes sense. Have >you seen differences in the generated assembly? > I'll leave out the int->uint stuff for now. If it's proved correct in the future, then I'll do it at that time. So you can disregard the previous patch and I'll make a new one without the int->uint changes in it. The return changes are easy to do with a script. Brian From owner-linux-xfs@oss.sgi.com Tue Sep 3 09:13:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 09:14:00 -0700 (PDT) Received: from imf10bis.bellsouth.net (mail110.mail.bellsouth.net [205.152.58.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83GDstG031416 for ; Tue, 3 Sep 2002 09:13:54 -0700 Received: from TAZ2 ([66.156.1.201]) by imf10bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020903161925.ZHTP11348.imf10bis.bellsouth.net@TAZ2>; Tue, 3 Sep 2002 12:19:25 -0400 Date: Tue, 3 Sep 2002 12:16:14 -0400 From: Greg Freemyer Subject: re[2]: snapshot regression test try 3 To: Ethan Benson , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020903161925.ZHTP11348.imf10bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g83GDstG031418 X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Ethan, That seems fair, I am putting together a small patch that will include this change. Greg >> On Fri, Aug 30, 2002 at 06:35:39PM -0400, Greg Freemyer wrote: >> > >> > if [ -e "$SCRATCH_SNAP_MNT" ]; then rm -rf "$SCRATCH_SNAP_MNT"; fi >> ummm is $SCRATCH_SNAP_MNT normally an empty mountpoint directory? if >> so please use rmdir and test its exit status (abort if rmdir fails) >> don't use rm -rf since you can't be certain there isn't something >> mounted there, or something stored there (shouldn't be but do you >> really want to chance it? rm -rf'ing data without warning is a good >> way to induce homicidal behavior) >> i recommend: >> if [ -e "$SCRATCH_SNAP_MNT" ]; then >> rmdir "$SCRATCH_SNAP_MNT" || exit 1 >> fi >> -- >> Ethan Benson >> http://www.alaska.net/~erbenson/ >> -- Attached file included as plaintext by Ecartis -- >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.0.6 (GNU/Linux) >> Comment: For info see http://www.gnupg.org >> iEYEARECAAYFAj1wdngACgkQJKx7GixEevxoBQCfahqAivVM3WJXGCKFdg/w1HE1 >> MQAAniwfD9n3fbY6G7PgTLe7/jp+L0NU >> =qMMo >> -----END PGP SIGNATURE----- Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Sep 3 09:42:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 09:42:25 -0700 (PDT) Received: from imf02bis.bellsouth.net (mail002.mail.bellsouth.net [205.152.58.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83GgItG032315 for ; Tue, 3 Sep 2002 09:42:19 -0700 Received: from TAZ2 ([66.156.1.201]) by imf02bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020903164750.KTVW8089.imf02bis.bellsouth.net@TAZ2>; Tue, 3 Sep 2002 12:47:50 -0400 Date: Tue, 3 Sep 2002 12:44:38 -0400 From: Greg Freemyer Subject: re: TAKE - snapshot QA To: Nathan Scott , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020903164750.KTVW8089.imf02bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g83GgJtG032317 X-archive-position: 230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Nathan, I looked over the edits you made, and most of them are fine. I did find a couple small things wrong. Despite there small size, they keep the script from from running correctly. I also made a change recommended by Ethan. "cvs diff 068" output below (is that fine, or do you need a unified diff): Index: 068 =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfstests/068,v retrieving revision 1.2 diff -r1.2 068 49a50 > mkdir "$tmp" 106c107,110 < [ -e "$SCRATCH_SNAP_MNT" ] && rm -rf "$SCRATCH_SNAP_MNT" --- > if [ -e "$SCRATCH_SNAP_MNT" ]; then > rmdir "$SCRATCH_SNAP_MNT" || _notrun "$SCRATCH_SNAP_MNT should be removed prior to running." > fi > 158c162 < dd if=/dev/zero of=$SCRATCH_MNT/dummy bs=64k count=1000 >/dev/null 2>&1 --- > dd if=/dev/zero of="$SCRATCH_MNT/dummy" bs=64k count=1000 >/dev/null 2>&1 210d213 < fi =================================================================== Line 50: The mkdir is required because $tmp is now a directory to place temp files in, not a prefix to add an extent to. Line 107-110: The $SCRATCH_SNAP_MNT change is Ethan's request Line 162: Some missing quotes requested by Ethan that somehow were missed previously. Line 210: An extraneous 'fi' left over from an if statement you converted to boolean logic. (I don't know how to word this one.) Greg ======== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> Date: Sun Sep 1 18:39:23 PDT 2002 >> Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs >> The following file(s) were checked into: >> bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs >> Modid: 2.4.x-xfs:slinx:126546a >> linux/fs/xfs/xfs_vnodeops.c - 1.561 >> - remove local tmp variable "sync_mode" which was accidentally >> left in on previous checkin. >> Date: Sun Sep 1 23:04:01 PDT 2002 >> Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs >> The following file(s) were checked into: >> bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs >> Modid: xfs-cmds:slinx:126551a >> cmd/xfstests/068 - 1.1 >> cmd/xfstests/068.out - 1.1 >> - A LVM snapshot regression test by Greg Freemyer. >> cmd/xfstests/group - 1.23 >> - Add in Greg's snapshot test, 068. Also, added 067 back into the >> auto-qa mix, looks like it wasn't added back after being disabled. From owner-linux-xfs@oss.sgi.com Tue Sep 3 09:51:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 09:51:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83GoxtG000339 for ; Tue, 3 Sep 2002 09:51:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA80464 for ; Tue, 3 Sep 2002 11:54:53 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA29628 for ; Tue, 3 Sep 2002 11:54:53 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g83Gpwv04539; Tue, 3 Sep 2002 11:51:58 -0500 Message-Id: <200209031651.g83Gpwv04539@stout.americas.sgi.com> Date: Tue, 3 Sep 2002 11:51:58 -0500 Subject: TAKE - Allow xfs_db to write negative numbers X-archive-position: 231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Allow xfs_db to write negative numbers. "-1" is often a special value for inode numbers, etc, but xfs_db didn't allow you to write a negative number. Date: Tue Sep 3 09:53:43 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126585a cmd/xfsprogs/db/write.c - 1.6 cmd/xfsprogs/VERSION - 1.56 cmd/xfsprogs/doc/CHANGES - 1.81 From owner-linux-xfs@oss.sgi.com Tue Sep 3 12:56:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 12:56:20 -0700 (PDT) Received: from imf04bis.bellsouth.net (mail104.mail.bellsouth.net [205.152.58.44]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83JuEtG012622 for ; Tue, 3 Sep 2002 12:56:14 -0700 Received: from TAZ2 ([66.156.1.201]) by imf04bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020903200146.XJFZ26924.imf04bis.bellsouth.net@TAZ2> for ; Tue, 3 Sep 2002 16:01:46 -0400 Date: Tue, 3 Sep 2002 15:58:34 -0400 From: Greg Freemyer Subject: Snapshot Status To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020903200146.XJFZ26924.imf04bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g83JuFtG012632 X-archive-position: 232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs All, I have been using the new LVM snapshot regression test extensively over the last couple of business days. (xfstests/068 now in CVS) I have found that the only kernel that can reliable pass the test is an xfs cvs kernel as of today. (Steve Lord put in a fix over the weekend that seems to be the final piece in the puzzle.) I suggest anyone using LVM snapshots with XFS in a production environment should consider this information. Note: if you want to run the snapshot test on your platform, the current CVS version has a couple of small typos that I described in an e-mail earlier today. Hopefully Nathan will get those changes into CVS shortly. Note 2: The kernel lockup listed below has not been reported before by me, but it was apparently resolved by Steve's latest fix. ===== Results of my tests WIth no i/o load: Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) Succesfully ran 20 iterations XFS CVS Aug. 30 kernel Succesfully ran 20 iterations XFS CVS Sept. 2 kernel Succesfully ran 20 iterations WIth a dd based i/o load Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) lvcreate locks up within 20 iterations XFS CVS Aug. 30 kernel Succesfully ran 20 iterations XFS CVS Sept. 2 kernel Succesfully ran 20 iterations WIth a fsstress based i/o load Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) lvcreate locks up within 20 iterations XFS CVS Aug. 30 kernel Not tested XFS CVS Sept. 2 kernel Succesfully ran 20 iterations WIth both a dd and a fsstress based i/o load Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) lvcreate locks up within 20 iterations XFS CVS Aug. 30 kernel Kernel locks up within 20 iterations XFS CVS Sept. 2 kernel Succesfully ran 20 iterations Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Sep 3 12:58:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 12:58:07 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83Jw4tG012835 for ; Tue, 3 Sep 2002 12:58:05 -0700 Received: (qmail 190 invoked by uid 500); 3 Sep 2002 20:01:22 -0000 Subject: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: linux-xfs@oss.sgi.com Cc: andrea@suse.de Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031083281.32386.21.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 15:01:22 -0500 X-archive-position: 233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB of disks FC2 disks. (14*69.87GB) I'm using LVM 1.0.3 and associated tools, as well as XFS as my FS of choice. I'm not sure what's happened recently, but after upgrading my disk subsystem to full FC2 (we were just FC2 to the switches before), when mounting any of the volumes on the StorageTek D178 subsystem, I get the following bug message. I was curious if I was hitting an XFS bug, or if it's because of the many LIP resets I get from the Qlogic Driver and the kernel got overflowed or XFS's mount got overflowed or something. Not sure, but it doesn't sound good. TIA scsi1: Topology - (FL_Port), Host Loop address 0x0 Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) kernel BUG at page_buf.c:602! invalid operand: 0000 2.4.19 #2 SMP Sun Aug 25 23:33:55 CDT 2002 CPU: 4 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 esi: c92d5180 edi: 00000001 ebp: 00000000 esp: c92e5720 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 1381, stackpage=c92e5000) Stack: c92d51e0 00000002 000001f0 c78eb28c c92e4000 00000000 00000000 000001f0 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 00000000 00002205 00000000 c01ffc76 c92d5180 c92e9934 00002205 00002000 00002205 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:05:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:05:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83K51tG013624 for ; Tue, 3 Sep 2002 13:05:01 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA83849; Tue, 3 Sep 2002 15:08:53 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-77.corp.sgi.com [134.15.64.77]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA84486; Tue, 3 Sep 2002 15:08:52 -0500 (CDT) Subject: Re: Kernel Opps/panic with 2.4.19 From: Stephen Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031083281.32386.21.camel@UberGeek.coremetrics.com> References: <1031083281.32386.21.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Sep 2002 15:07:26 -0500 Message-Id: <1031083648.1077.70.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB of > disks FC2 disks. (14*69.87GB) > > I'm using LVM 1.0.3 and associated tools, as well as XFS as my FS of > choice. I'm not sure what's happened recently, but after upgrading my > disk subsystem to full FC2 (we were just FC2 to the switches before), > when mounting any of the volumes on the StorageTek D178 subsystem, I get > the following bug message. > > I was curious if I was hitting an XFS bug, or if it's because of the > many LIP resets I get from the Qlogic Driver and the kernel got > overflowed or XFS's mount got overflowed or something. Not sure, but it > doesn't sound good. TIA > > scsi1: Topology - (FL_Port), Host Loop address 0x0 > Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) > kernel BUG at page_buf.c:602! > invalid operand: 0000 2.4.19 #2 SMP Sun Aug 25 23:33:55 CDT 2002 > CPU: 4 > EIP: 0010:[] Not tainted > EFLAGS: 00010246 > eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 > esi: c92d5180 edi: 00000001 ebp: 00000000 esp: c92e5720 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 1381, stackpage=c92e5000) > Stack: c92d51e0 00000002 000001f0 c78eb28c c92e4000 00000000 00000000 > 000001f0 > 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 > 00000000 > 00002205 00000000 c01ffc76 c92d5180 c92e9934 00002205 00002000 > 00002205 > Call Trace: [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] > Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 A decoded version of that would help.... Steve > > -- > Austin Gonyou > Coremetrics, Inc. > From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:24:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:24:20 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83KOEtG014231 for ; Tue, 3 Sep 2002 13:24:14 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17mKHi-0001Gm-00 for linux-xfs@oss.sgi.com; Tue, 03 Sep 2002 14:28:26 -0600 Message-ID: <3D751B88.2040507@emergence.com> Date: Tue, 03 Sep 2002 14:28:56 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Kernel Opps/panic with 2.4.19 References: <1031083281.32386.21.camel@UberGeek.coremetrics.com> <1031083648.1077.70.camel@laptop.americas.sgi.com> X-Enigmail-Version: 0.65.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Stephen Lord wrote: > On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > >>I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB of >>disks FC2 disks. (14*69.87GB) Which patch is this? Mainly just out of curiousity. Alan Cox patch-2.4.19-rc5-ac1.gz + XFS? -Mike From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:40:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:41:01 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83KewtG014822 for ; Tue, 3 Sep 2002 13:40:59 -0700 Received: (qmail 818 invoked by uid 500); 3 Sep 2002 20:44:19 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Michael Best Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D751B88.2040507@emergence.com> References: <3D751B88.2040507@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031085859.32386.58.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 15:44:19 -0500 X-archive-position: 236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs No, -RC5-AA1. Andrea Arcangeli. On Tue, 2002-09-03 at 15:28, Michael Best wrote: > Stephen Lord wrote: > > On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > > > >>I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB > of > >>disks FC2 disks. (14*69.87GB) > > Which patch is this? Mainly just out of curiousity. > > Alan Cox patch-2.4.19-rc5-ac1.gz + XFS? > > -Mike -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:41:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:41:25 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83KfNtG014823 for ; Tue, 3 Sep 2002 13:41:24 -0700 Received: (qmail 827 invoked by uid 500); 3 Sep 2002 20:44:46 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031083648.1077.70.camel@laptop.americas.sgi.com> References: <1031083648.1077.70.camel@laptop.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031085885.32386.62.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 15:44:46 -0500 X-archive-position: 237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Will ksymoops work on this? On Tue, 2002-09-03 at 15:07, Stephen Lord wrote: > On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > > I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB > of > > disks FC2 disks. (14*69.87GB) > > > > I'm using LVM 1.0.3 and associated tools, as well as XFS as my FS of > > choice. I'm not sure what's happened recently, but after upgrading > my > > disk subsystem to full FC2 (we were just FC2 to the switches > before), > > when mounting any of the volumes on the StorageTek D178 subsystem, I > get > > the following bug message. > > > > I was curious if I was hitting an XFS bug, or if it's because of the > > many LIP resets I get from the Qlogic Driver and the kernel got > > overflowed or XFS's mount got overflowed or something. Not sure, but > it > > doesn't sound good. TIA > > > > scsi1: Topology - (FL_Port), Host Loop address 0x0 > > Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) > > kernel BUG at page_buf.c:602! > > invalid operand: 0000 2.4.19 #2 SMP Sun Aug 25 23:33:55 CDT 2002 > > CPU: 4 > > EIP: 0010:[] Not tainted > > EFLAGS: 00010246 > > eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 > > esi: c92d5180 edi: 00000001 ebp: 00000000 esp: c92e5720 > > ds: 0018 es: 0018 ss: 0018 > > Process mount (pid: 1381, stackpage=c92e5000) > > Stack: c92d51e0 00000002 000001f0 c78eb28c c92e4000 00000000 > 00000000 > > 000001f0 > > 00000000 00000001 0010000c 00000002 00000000 00000002 > 00800050 > > 00000000 > > 00002205 00000000 c01ffc76 c92d5180 c92e9934 00002205 > 00002000 > > 00002205 > > Call Trace: [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] > > Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 > > A decoded version of that would help.... > > Steve > > > > > -- > > Austin Gonyou > > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 14:21:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 14:21:43 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83LLZtG016117 for ; Tue, 3 Sep 2002 14:21:35 -0700 Received: (qmail 1337 invoked by uid 500); 3 Sep 2002 21:25:01 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031083648.1077.70.camel@laptop.americas.sgi.com> References: <1031083648.1077.70.camel@laptop.americas.sgi.com> Content-Type: multipart/mixed; boundary="=-6Am2j39O1Ob7YdPBVNPV" Organization: Coremetrics, Inc. Message-Id: <1031088301.32386.92.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 16:25:01 -0500 X-archive-position: 238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs --=-6Am2j39O1Ob7YdPBVNPV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok, I guess ksymoops will do that. I only had used it for just plain *oopses* before. Sorry about my ignorance.=20 Attatched is the output.=20 =20 --=20 Austin Gonyou Coremetrics, Inc. --=-6Am2j39O1Ob7YdPBVNPV Content-Disposition: attachment; filename=2.4.19-xfs-ksymoops-prod5.txt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=2.4.19-xfs-ksymoops-prod5.txt; charset=ISO-8859-1 kernel BUG at page_buf.c:602! invalid operand: 0000 2.4.19 #2 SMP Mon Aug 26 02:32:04 CDT 2002 CPU: 2 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 esi: c8e7d780 edi: 00000001 ebp: 00000000 esp: d4245720 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 5264, stackpage=3Dd4245000) Stack: c8e7d7e0 00000002 000001f0 c7878864 d4244000 00000000 00000000 00000= 1f0 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 00000= 000 00002205 00000000 c01ffc76 c8e7d780 d3e76db4 00002205 00002000 00002= 205 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 kernel BUG at page_buf.c:602! invalid operand: 0000 2.4.19 #2 SMP Mon Aug 26 02:32:04 CDT 2002 CPU: 2 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 esi: c8e7d780 edi: 00000001 ebp: 00000000 esp: d4245720 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 5264, stackpage=3Dd4245000) Stack: c8e7d7e0 00000002 000001f0 c7878864 d4244000 00000000 00000000 00000= 1f0 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 00000= 000 00002205 00000000 c01ffc76 c8e7d780 d3e76db4 00002205 00002000 00002= 205 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [<= c0165780>] [] [] [] Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 >>EIP; c01ff6e4 <_pagebuf_lookup_pages+124/430> <=3D=3D=3D=3D=3D Trace; c01ffc76 Trace; c01e68c7 Trace; c01e7854 Trace; c01e5d97 Trace; c01e792f Trace; c01e7a3e Trace; c01e8544 Trace; c01e89d3 Trace; c01e8a3b Trace; c01e8c53 Trace; c01e13b4 Trace; c01ea0bc Trace; c0201a3c <.text.lock.page_buf+83/127> Trace; c01e95b4 Trace; c01e980b Trace; c01f36be Trace; c01f392f Trace; c01f3977 Trace; c020c753 Trace; c013ed95 <__alloc_pages+65/280> Trace; c01352b5 Trace; c013d02f Trace; c012f57d Trace; c014dd2a Trace; c014e7ac Trace; c014dc7b Trace; c014eb8c Trace; c01652e8 Trace; c0165780 Trace; c01655c9 Trace; c0165d3f Trace; c01095bb Code; c01ff6e4 <_pagebuf_lookup_pages+124/430> 00000000 <_EIP>: Code; c01ff6e4 <_pagebuf_lookup_pages+124/430> <=3D=3D=3D=3D=3D 0: 0f 0b ud2a <=3D=3D=3D=3D=3D Code; c01ff6e6 <_pagebuf_lookup_pages+126/430> 2: 5a pop %edx Code; c01ff6e7 <_pagebuf_lookup_pages+127/430> 3: 02 a0 4e 2f c0 8b add 0x8bc02f4e(%eax),%ah Code; c01ff6ed <_pagebuf_lookup_pages+12d/430> 9: 4c dec %esp Code; c01ff6ee <_pagebuf_lookup_pages+12e/430> a: 24 4c and $0x4c,%al Code; c01ff6f0 <_pagebuf_lookup_pages+130/430> c: 8b 51 58 mov 0x58(%ecx),%edx Code; c01ff6f3 <_pagebuf_lookup_pages+133/430> f: 81 49 08 04 00 00 00 orl $0x4,0x8(%ecx) --=-6Am2j39O1Ob7YdPBVNPV --=-6Am2j39O1Ob7YdPBVNPV-- From owner-linux-xfs@oss.sgi.com Tue Sep 3 14:31:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 14:31:28 -0700 (PDT) Received: from pop.andover.net (pop.andover.net [209.192.217.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83LVNtG016643 for ; Tue, 3 Sep 2002 14:31:23 -0700 Received: from Rodan.osdn.com (vpn-route.osdn.com [209.192.217.2]) by pop.andover.net (8.11.0/8.9.2) with ESMTP id g83LVOu02910 for ; Tue, 3 Sep 2002 17:31:25 -0400 Subject: Re: [PATCH] Kernel janitor cleanup From: Brian Pontz To: linux-xfs@oss.sgi.com In-Reply-To: <20020903095458.A551@infradead.org> References: <3D74023E.1010208@osdn.com> <20020903095458.A551@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Sep 2002 17:35:18 -0400 Message-Id: <1031088918.14660.36.camel@Rodan.osdn.com> Mime-Version: 1.0 X-archive-position: 239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs http://www.axehind.com/xfs/xfs-cleanup-2-linux-2.4.patch return() cleanup partial patch. Brian On Tue, 2002-09-03 at 04:54, Christoph Hellwig wrote: > On Mon, Sep 02, 2002 at 08:28:46PM -0400, Brian Pontz wrote: > > http://www.axehind.com/xfs/xfs-cleanup-1-linux-2.4.patch > > > > The patch is mainly a partial janitor patch. > > The return cleanups make sense, that was inconsisten even inside XFS. > I'm not entirely sure wheter the int->uint stuff makes sense. Have > you seen differences in the generated assembly? > > The set_current_state patch is wrong, it adds another unnessecary test. > But that piece of code is rather wrong anyway and sets the states in > the wrong places. Using wait_event() cleans up the code more and gets > it right: > > > Index: fs/xfs/xfs_inode.c > =================================================================== > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c,v > retrieving revision 1.348 > diff -u -p -r1.348 xfs_inode.c > --- fs/xfs/xfs_inode.c 2002/09/01 12:43:34 1.348 > +++ fs/xfs/xfs_inode.c 2002/09/03 08:49:50 > @@ -2579,7 +2579,6 @@ xfs_iunpin_wait( > { > xfs_inode_log_item_t *iip; > xfs_lsn_t lsn; > - DECLARE_WAITQUEUE(wait, current); > > ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE | MR_ACCESS)); > > @@ -2599,15 +2598,7 @@ xfs_iunpin_wait( > */ > xfs_log_force(ip->i_mount, lsn, XFS_LOG_FORCE); > > - add_wait_queue(&ip->i_ipin_wait, &wait); > -repeat: > - set_current_state(TASK_UNINTERRUPTIBLE); > - if (atomic_read(&ip->i_pincount)) { > - schedule(); > - goto repeat; > - } > - remove_wait_queue(&ip->i_ipin_wait, &wait); > - current->state = TASK_RUNNING; > + wait_event(ip->i_ipin_wait, (atomic_read(&ip->i_pincount) == 0)); > } > > From owner-linux-xfs@oss.sgi.com Tue Sep 3 15:00:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 15:00:41 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83M0ctG017238 for ; Tue, 3 Sep 2002 15:00:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA84805 for ; Tue, 3 Sep 2002 17:04:33 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA73700 for ; Tue, 3 Sep 2002 17:04:33 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g83M1aQ16043; Tue, 3 Sep 2002 17:01:36 -0500 Message-Id: <200209032201.g83M1aQ16043@stout.americas.sgi.com> Date: Tue, 3 Sep 2002 17:01:36 -0500 Subject: TAKE - add show_options sb method X-archive-position: 240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This adds a superblock method so that /proc/mounts will query the xfs mount structs, etc, and tell you what options are really set in the kernel. Currently /etc/mtab can get faked out and list options that didn't really get set. add show_options sb method Date: Tue Sep 3 15:03:09 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126637a linux/fs/xfs/linux/xfs_super.c - 1.210 From owner-linux-xfs@oss.sgi.com Tue Sep 3 15:21:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 15:21:35 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83MLTtG017917 for ; Tue, 3 Sep 2002 15:21:29 -0700 Received: (qmail 1885 invoked by uid 500); 3 Sep 2002 22:25:01 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031088301.32386.92.camel@UberGeek.coremetrics.com> References: <1031088301.32386.92.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031091900.32409.101.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 17:25:01 -0500 X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I seemed to have found that after running xfs_repair -L on a fs I knew I could lose the log for, I can now mount the volume properly. Is it because the -RC5-aa1 patch has old XFS code that this is happening? Should I upgrade my mount to support newer XFS code, and thusly, log replays? Please advise. This appears to be the only thing causing any problems on this system at this point. TIA! On Tue, 2002-09-03 at 16:25, Austin Gonyou wrote: > Ok, I guess ksymoops will do that. I only had used it for just plain > *oopses* before. Sorry about my ignorance. > > Attatched is the output. > > -- > Austin Gonyou > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 15:24:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 15:24:17 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83MOCtG018398 for ; Tue, 3 Sep 2002 15:24:12 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA85153 for ; Tue, 3 Sep 2002 17:28:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA62386 for ; Tue, 3 Sep 2002 17:28:06 -0500 (CDT) Subject: Re: TAKE - add show_options sb method From: Eric Sandeen To: linux-xfs@oss.sgi.com In-Reply-To: <200209032201.g83M1aQ16043@stout.americas.sgi.com> References: <200209032201.g83M1aQ16043@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 03 Sep 2002 17:25:09 -0500 Message-Id: <1031091909.3162.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Oh, I should mention that this is xfs-specific mount options, "generic" vfs mount options already show up in /proc/mounts. On Tue, 2002-09-03 at 17:01, Eric Sandeen wrote: > This adds a superblock method so that /proc/mounts will query the xfs > mount structs, etc, and tell you what options are really set in the kernel. > > Currently /etc/mtab can get faked out and list options that didn't > really get set. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Sep 3 18:58:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 18:58:57 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g841wqtG030340 for ; Tue, 3 Sep 2002 18:58:52 -0700 Received: (qmail 4377 invoked by uid 500); 4 Sep 2002 02:02:27 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031088301.32386.92.camel@UberGeek.coremetrics.com> References: <1031088301.32386.92.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031104946.4344.1.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 21:02:27 -0500 X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I used the 2.4.19 xfs patch set with a stock 2.4.19 kernel, and get the same output as far as the oops is concerned. I can xfs_repair -L on the volumes and then mount them, but I'm not sure why I can't replay the journal at all, and then mount segfaults. Any ideas on what I can do, besides just xfs_repair -L, would be greatly appreciated. TIA On Tue, 2002-09-03 at 16:25, Austin Gonyou wrote: > Ok, I guess ksymoops will do that. I only had used it for just plain > *oopses* before. Sorry about my ignorance. > > Attatched is the output. > > -- > Austin Gonyou > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 19:18:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 19:18:54 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g842IqtG030981 for ; Tue, 3 Sep 2002 19:18:52 -0700 Received: from dialup-63.214.67.118.dial1.boston1.level3.net ([63.214.67.118] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17mPoh-00053a-00 by VAauthid with fixed_plain for ; Tue, 03 Sep 2002 19:22:52 -0700 Message-ID: <3D756E6A.30908@osdn.com> Date: Tue, 03 Sep 2002 22:22:34 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup References: <3D74023E.1010208@osdn.com> <20020903095458.A551@infradead.org> <1031088918.14660.36.camel@Rodan.osdn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs > > >http://www.axehind.com/xfs/xfs-cleanup-2-linux-2.4.patch > >return() cleanup partial patch. > >Brian > Next patch for the return() cleanup http://www.axehind.com/xfs/xfs-cleanup-3-linux-2.4.patch Brian From owner-linux-xfs@oss.sgi.com Tue Sep 3 21:21:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 21:21:26 -0700 (PDT) Received: from mail.aspec.ru (relay1.aspec.ru [217.14.198.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g844LJtG000346 for ; Tue, 3 Sep 2002 21:21:21 -0700 Received: from [192.168.22.111] (HELO belkam.com) by mail.aspec.ru (CommuniGate Pro SMTP 3.5.9) with ESMTP id 697553 for linux-xfs@oss.sgi.com; Wed, 04 Sep 2002 09:25:12 +0500 Message-ID: <3D758B28.9000406@belkam.com> Date: Wed, 04 Sep 2002 09:25:12 +0500 From: Dmitry Melekhov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: ru, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.19- xfs oops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@belkam.com Precedence: bulk X-list: linux-xfs Hello! We had our fileserver died this night. Sorry, I wrote down oops info by hands (so it is possible that there are mistypings) and I can't run ksymoops on 2.4.19, because we switched back to 2.4.18 for now, so most of warinings are skipped here. Hope, anyway, that this info can help. kernel BUG at filemap.c:843 invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: c11b388 ecx: 00000017 edx: c02f60f4 esi: c1580948 edi: cc5b6dc0 ebp: df0e9d40 esp: c4841e4c ds: 0018 es:0018 ss: 0018 Stack: ca0bce00 c11b9388 c01f41cd d4f6d6e0 00000246 00000001 ca0bce00 00000000 c11b9388 c01f4209 ca0bce00 00000001 00000001 c024ebae ca0bce00 00000001 d4f6d6e0 db7077a0 00000001 dfe6ae00 c034ecd0 d4f6d6e0 00000001 dfe6aeb8 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] code: 0f 0b 4b 03 00cb 2a c0 8d 46 04 39 46 04 74 0e 31 c9 ba 03 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops 0.7c on i686 2.4.18-xfs. Options used -v /usr/src/linux-2.4.19-xfs/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-xfs/ (specified) -m /usr/src/linux/System.map (default) Warning (compare_Version): Version mismatch. System.map says 2.4.19, e100 says 2.4.18. Expect lots of address mismatches. [skip] invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: c11b388 ecx: 00000017 edx: c02f60f4 esi: c1580948 edi: cc5b6dc0 ebp: df0e9d40 esp: c4841e4c ds: 0018 es:0018 ss: 0018 Stack: ca0bce00 c11b9388 c01f41cd d4f6d6e0 00000246 00000001 ca0bce00 00000000 c11b9388 c01f4209 ca0bce00 00000001 00000001 c024ebae ca0bce00 00000001 d4f6d6e0 db7077a0 00000001 dfe6ae00 c034ecd0 d4f6d6e0 00000001 dfe6aeb8 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] code: 0f 0b 4b 03 00cb 2a c0 8d 46 04 39 46 04 74 0e 31 c9 ba 03 >>EIP; e012420a <_end+1fda3506/205d735c> <===== Trace; c01f41cd <_end_pagebuf_page_io_multi+e5/110> Trace; c01f4209 <_end_io_multi_full+11/18> Trace; c024ebae Trace; c024ecd0 Trace; c023b738 <__scsi_end_request+74/130> Trace; c023ba96 Trace; c0240c58 Trace; c024529b Trace; c023ad86 Trace; c0243d91 Trace; c010996d Trace; c0109ad7 Trace; c010bd08 Code; e012420a <_end+1fda3506/205d735c> 00000000 <_EIP>: Code; e012420a <_end+1fda3506/205d735c> <===== 0: 0f 0b ud2a <===== Code; e012420c <_end+1fda3508/205d735c> 2: 4b dec %ebx Code; e012420d <_end+1fda3509/205d735c> 3: 03 cb add %ebx,%ecx Code; e012420f <_end+1fda350b/205d735c> 5: 00 2a add %ch,(%edx) Code; e0124211 <_end+1fda350d/205d735c> 7: c0 8d 46 04 39 46 04 rorb $0x4,0x46390446(%ebp) Code; e0124218 <_end+1fda3514/205d735c> e: 74 0e je 1e <_EIP+0x1e> e0124228 <_end+1fda3524/205d735c> Code; e012421a <_end+1fda3516/205d735c> 10: 31 c9 xor %ecx,%ecx Code; e012421c <_end+1fda3518/205d735c> 12: ba 03 00 00 00 mov $0x3,%edx <0>Kernel panic: Aiee, killing interrupt handler! 1167 warnings issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Tue Sep 3 23:17:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 23:17:47 -0700 (PDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g846HftG003427 for ; Tue, 3 Sep 2002 23:17:41 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g846LaE26875 for ; Wed, 4 Sep 2002 15:21:36 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g846LZ512670 for ; Wed, 4 Sep 2002 15:21:35 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g846LZh02841 for ; Wed, 4 Sep 2002 15:21:35 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA513 for ; Wed, 4 Sep 2002 15:21:34 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Sep 04 15:21:33 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g846LXA62253 for ; Wed, 4 Sep 2002 15:21:33 +0900 (JST) Received: from TNES007145 (TNES007145.bsd.tnes.nec.co.jp [10.1.104.50]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g846LXY04157 for ; Wed, 4 Sep 2002 15:21:33 +0900 From: "hatakeyama" To: Subject: issue on dual cpu machine Date: Wed, 4 Sep 2002 15:21:33 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C25426.C0AB7DF0" 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.4807.1700 Importance: Normal X-archive-position: 246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hatakeyama@bsd.tnes.nec.co.jp Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C25426.C0AB7DF0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, I found an issue on dual cpu machine. Description: the xfs couldn't follow append-write semantics correctly. After the file was opened with O_APPEND flag, then seek the file position of EOF before each writing. After several seconds, we found that the data was not written one by one, that means some of them have been overwritten. Configuration: VERSION:2.4.17(xfs-0225-all.patch) Dual Intel pentium III 900 2G RAM -------- You can reproduce the issue with the attached files as below: chdir to a xfs, run # test kill this process, the files size exceed 40 MB. and verify as below: # test2 testfile* -------- Regards, hatake ------=_NextPart_000_000B_01C25426.C0AB7DF0 Content-Type: application/octet-stream; name="test2.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test2.c" #include #include #include #include #include #include #include int main(int argc, char **argv) { char *file; int fd, i, rc, d; if (argc < 2) exit(1); file =3D argv[1]; if ((fd =3D open(file, O_RDONLY, 0600)) =3D=3D -1) { perror("couldn't open"); exit(1); } for (i =3D 0; ;i ++) { if ((rc =3D read(fd, &d, sizeof(d))) !=3D sizeof(i)) { if (rc =3D=3D 0) exit(0); perror("couldn't read"); exit(1); } if (d !=3D i) { fprintf(stderr, "bad data, offset =3D %u", i * 4); exit(1); } } exit(0); } ------=_NextPart_000_000B_01C25426.C0AB7DF0 Content-Type: application/octet-stream; name="test.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test.c" #include #include #include #include #include #include int main(int argc, char **argv) { char file[MAXPATHLEN]; int fd, i; sprintf(file, "testfile.%d", getpid()); if ((fd =3D open(file, O_CREAT | O_RDWR | O_APPEND, 0600)) =3D=3D -1) { perror("couldn't open"); exit(1); } for (i =3D 0; ;i ++) { if (write(fd, &i, sizeof(i)) !=3D sizeof(i)) { perror("couldn't write"); exit(1); } } exit(0); } ------=_NextPart_000_000B_01C25426.C0AB7DF0-- From owner-linux-xfs@oss.sgi.com Tue Sep 3 23:54:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 23:54:49 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g846sitG004265 for ; Tue, 3 Sep 2002 23:54:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 XAA08223 for ; Tue, 3 Sep 2002 23:58:44 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13996; Wed, 4 Sep 2002 16:57:24 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) with ESMTP id g846uxKR000575; Wed, 4 Sep 2002 16:56:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) id g846uwnH000573; Wed, 4 Sep 2002 16:56:58 +1000 Date: Wed, 4 Sep 2002 16:56:58 +1000 From: Nathan Scott To: hatakeyama Cc: linux-xfs@oss.sgi.com Subject: Re: issue on dual cpu machine Message-ID: <20020904065658.GA518@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Hi there, This does not fail on my quad CPU test box with CVS code. I seem to remember a problem with append writes from a long time ago, but not the specific fix [ -- there was a specific fix, I just can't remember what it was ;-) ]. You might be able to dredge the CVS logs if you need to stay at that version, otherwise I'd recommend upgrading to more recent kernel code (2.4.17 is already dated). FWIW, I tried these different test sizes: -rw------- 1 root root 2.9M Sep 4 16:33 /mnt/xfs1/testfile.1176 -rw------- 1 root root 20M Sep 4 16:35 /mnt/xfs1/testfile.1183 -rw------- 1 root root 74M Sep 4 16:50 /mnt/xfs1/testfile.1233 cheers. -- Nathan On Wed, Sep 04, 2002 at 03:21:33PM +0900, hatakeyama wrote: > Hi, > > I found an issue on dual cpu machine. > > Description: > the xfs couldn't follow append-write semantics correctly. > After the file was opened with O_APPEND flag, then seek the > file position of EOF before each writing. After several seconds, > we found that the data was not written one by one, that means > some of them have been overwritten. > > Configuration: > VERSION:2.4.17(xfs-0225-all.patch) > Dual Intel pentium III 900 > 2G RAM > > -------- > You can reproduce the issue with the attached files as below: > > chdir to a xfs, run > > # test > > kill this process, the files size exceed 40 MB. > > and verify as below: > > # test2 testfile* > -------- > > Regards, > hatake From owner-linux-xfs@oss.sgi.com Wed Sep 4 01:39:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 01:39:42 -0700 (PDT) Received: from Gateway.bksys.co.in ([61.1.200.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g848dYtG018329 for ; Wed, 4 Sep 2002 01:39:36 -0700 Received: from bksys.co.in (mail.bksys.co.in [192.168.1.1]) by Gateway.bksys.co.in (8.11.6/8.11.6) with ESMTP id g848hSo06992 for ; Wed, 4 Sep 2002 14:13:29 +0530 Received: from Uday.bksys.co.in (IDENT:7w6G4WfSJf11qnE0hg/x0LXAoA2KzdwC@Uday.bksys.co.in [192.168.1.79]) by bksys.co.in (8.11.6/8.8.5) with ESMTP id g848fsK13492 for ; Wed, 4 Sep 2002 14:11:54 +0530 Date: Wed, 4 Sep 2002 14:15:50 +0530 (IST) From: "Udaya Kumar.R" X-X-Sender: uday@Uday.bksys.co.in Reply-To: "Udaya Kumar.R" To: linux-xfs@oss.sgi.com Subject: 2.4.18 not compiling with XFS ! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: itsuday@linuxfreemail.com Precedence: bulk X-list: linux-xfs hi , I m a newbie to Linux & XFS and i m in RedHat 7.3 . I m trying to make my kernel ( 2.4.18 ) , XFS enabled . In the process i downloaded the patch from : ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18/ which is ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18/xfs-2.4. 18-all-i386.bz2 After untaring the kernel and applying the patch , everything patched proprely , i went on to compile him . I enabled the required options in 'make menuconfig' , said 'make dep' and 'make bzImage' . In the last step , 'make bzImage' , i got some errors which i have posted along with this mail . ld -m elf_i386 -T /usr/src/linux-2.4.18/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/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o net/network.o /usr/src/linux-2.4.18/arch/i386/lib/lib.a /usr/src/linux-2.4.18/lib/lib.a /usr/src/linux-2.4.18/arch/i386/lib/lib.a --end-group -o vmlinux fs/fs.o: In function `xfs_dm_send_data_event': fs/fs.o(.text+0x4a622): undefined reference to `dm_send_data_event' fs/fs.o: In function `xfs_dm_send_create_event': fs/fs.o(.text+0x4a6d6): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_dm_bulkstat_one': fs/fs.o(.text+0x4ab2a): undefined reference to `dm_vp_to_handle' fs/fs.o: In function `xfs_dm_mount': fs/fs.o(.text+0x4d6d6): undefined reference to `dm_send_mount_event' fs/fs.o: In function `xfs_rename': fs/fs.o(.text+0x9b26d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x9bc47): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_unmount': fs/fs.o(.text+0xa14e4): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa15b3): undefined reference to `dm_send_unmount_event' fs/fs.o: In function `xfs_setattr': fs/fs.o(.text+0xa36f5): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_inactive': fs/fs.o(.text+0xa461e): undefined reference to `dm_send_destroy_event' fs/fs.o: In function `xfs_create': fs/fs.o(.text+0xa5551): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_remove': fs/fs.o(.text+0xa5b90): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa6051): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_link': fs/fs.o(.text+0xa619d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa6556): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa6b53): more undefined references to `dm_send_namesp_event' follow make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.18' make: *** [vmlinux] Error 2 Tell me how to go about on getting thru. xfs enabled kernel ! Note : I enabled the XFS as loadable module . bye uday -- Reply To : perl -e 'print pack "H*","69747375646179406c696e7578667265656d61696c2e636f6d";' OR to the above 'From' Address From owner-linux-xfs@oss.sgi.com Wed Sep 4 02:48:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 02:48:51 -0700 (PDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g849mjtG023052 for ; Wed, 4 Sep 2002 02:48:45 -0700 Received: (qmail 41540 invoked from network); 4 Sep 2002 09:52:46 -0000 Received: from unknown (HELO mountainviewdata.com) (210.72.245.13) by relay1.pair.com with SMTP; 4 Sep 2002 09:52:46 -0000 X-pair-Authenticated: 210.72.245.13 Message-ID: <3D75D7A6.7010205@mountainviewdata.com> Date: Wed, 04 Sep 2002 17:51:34 +0800 From: tom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Ask a xfs problem Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-archive-position: 249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: twang@mountainviewdata.com Precedence: bulk X-list: linux-xfs Hi xfs developers. These days when I studied the xfs code, I found that if a process allocats one inode extents, while another process frees its extents which belong to another inode at the meantime, these two processes maybe deadlock. Following is my analysis: when allocating the extents, the process may loop over allocation groups and lock their allocation agf blocks. (the code 2380-2430 in xfs_alloc.c) At the same time, if another process free its extents, then the deadlock of these two process will happen, for it will also lock some allocation agf block, and furthermore the lock sequences of agf in these two process is apparently different.(the code 4040-4056 in fs/xfs/xfs_bmap.c) I really want to figure out it. Your responses is highly appreciated. Best regards. From owner-linux-xfs@oss.sgi.com Wed Sep 4 04:04:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 04:05:03 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84B4utG030039 for ; Wed, 4 Sep 2002 04:04:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 EAA00196 for ; Wed, 4 Sep 2002 04:08:57 -0700 (PDT) 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 VAA15360; Wed, 4 Sep 2002 21:07:25 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA95153; Wed, 4 Sep 2002 21:07:23 +1000 (AEDT) Date: Wed, 4 Sep 2002 21:07:23 +1000 From: Nathan Scott To: "Udaya Kumar.R" Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 not compiling with XFS ! Message-ID: <20020904210723.A95165@wobbly.melbourne.sgi.com> 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 itsuday@linuxfreemail.com on Wed, Sep 04, 2002 at 02:15:50PM +0530 X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 02:15:50PM +0530, Udaya Kumar.R wrote: > hi , > > I m a newbie to Linux & XFS and i m in RedHat 7.3 . > > I m trying to make my kernel ( 2.4.18 ) , XFS enabled . > ... > > Tell me how to go about on getting thru. xfs enabled kernel ! > > Note : I enabled the XFS as loadable module . The easiest solution for you would be to disable XFS DMAPI support in your kernel builds. With recent changes in the XFS kernel code (after 2.4.18 I guess) this sort of error cannot happen, but Dean may have some more suggestions for you if you need to enable DMAPI support in that particular kernel version. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 4 08:43:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 08:43:30 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84FhPtG027908 for ; Wed, 4 Sep 2002 08:43:26 -0700 Received: (qmail 6475 invoked by uid 500); 4 Sep 2002 15:47:04 -0000 Subject: What's up with the list? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031154424.6416.10.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Sep 2002 10:47:04 -0500 X-archive-position: 251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Has everything gone crazy, or is there now an xfs-dev list or something, and so bug reports aren't getting noticed as much? -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 4 09:17:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 09:17:44 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84GHbtG029385 for ; Wed, 4 Sep 2002 09:17:37 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA15625; Wed, 4 Sep 2002 11:21:34 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA21204; Wed, 4 Sep 2002 11:21:34 -0500 (CDT) Subject: Re: What's up with the list? From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031154424.6416.10.camel@UberGeek.coremetrics.com> References: <1031154424.6416.10.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Sep 2002 11:18:29 -0500 Message-Id: <1031156310.3056.15.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-04 at 10:47, Austin Gonyou wrote: > Has everything gone crazy, or is there now an xfs-dev list or something, > and so bug reports aren't getting noticed as much? Or choice c) - Steve is out, I'm very busy, and we might not be able to deal with every problem as quickly as we'd like to... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 4 09:25:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 09:25:35 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84GPUtG029907 for ; Wed, 4 Sep 2002 09:25:30 -0700 Received: (qmail 6546 invoked by uid 500); 4 Sep 2002 16:28:59 -0000 Subject: Re: What's up with the list? From: Austin Gonyou To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031156310.3056.15.camel@stout.americas.sgi.com> References: <1031156310.3056.15.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031156939.6421.25.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Sep 2002 11:28:59 -0500 X-archive-position: 253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs :-D I hear ya. I was just curious. Not many mails from others yesterday evening. Used to be that the evening time was very busy. Then as this AM seems slow too, I was a bit worried that people had less interest or something. That's all. I wasn't trying to sound like a jerk, I was more curious than anything. On Wed, 2002-09-04 at 11:18, Eric Sandeen wrote: > On Wed, 2002-09-04 at 10:47, Austin Gonyou wrote: > > Has everything gone crazy, or is there now an xfs-dev list or > something, > > and so bug reports aren't getting noticed as much? > > Or choice c) - Steve is out, I'm very busy, and we might not be able > to > deal with every problem as quickly as we'd like to... > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:27:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:27:31 -0700 (PDT) Received: from imf03bis.bellsouth.net (mail303.mail.bellsouth.net [205.152.58.163]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HROtG016251 for ; Wed, 4 Sep 2002 10:27:25 -0700 Received: from TAZ2 ([66.156.0.36]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> for ; Wed, 4 Sep 2002 13:33:00 -0400 Date: Wed, 4 Sep 2002 13:29:45 -0400 From: Greg Freemyer Subject: mapcheck question To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g84HRPtG016254 X-archive-position: 254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs I think I have the latest mapcheck which was recently posted. (Thanks to whoever is supporting this.) unfortunately mapcheck -V gives "$Id:$", so I can't say what the version number is. My real question is if the -f or --force option is still valid. mapcheck -aq seems to work fine for me, but since I want to run this at the end of my backup script I assume I need the -f option to keep any interactive questions from occuring. Whenever I try to add a -f or --force, I get a usage statement. Thanks Greg ====== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:36:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:36:06 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84Ha3tG016762 for ; Wed, 4 Sep 2002 10:36:03 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g84HduFZ097329; Wed, 4 Sep 2002 19:40:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20020904193658.03a2a540@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Sep 2002 19:38:32 +0200 To: Dmitry Melekhov , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2.4.19- xfs oops In-Reply-To: <3D758B28.9000406@belkam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 09:25 4-9-2002 +0500, Dmitry Melekhov wrote: >Hello! > >We had our fileserver died this night. >Sorry, I wrote down oops info by hands (so it is possible >that there are mistypings) and I can't run ksymoops on 2.4.19, >because we switched back to 2.4.18 for now, so most of warinings >are skipped here. Hope, anyway, that this info can help. I personally don't think we can do much with this oops. I don't even see a xfs_ function called anywhere. Not all oopses are a direct result from XFS, I have had a ethernet driver (bcm5700) blowup a box which is totally unrelated to disk io at all. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:41:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:41:25 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HfMtG017287 for ; Wed, 4 Sep 2002 10:41:22 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g84HjNLZ025735; Wed, 4 Sep 2002 19:45:23 +0200 (CEST) Message-Id: <4.3.2.7.2.20020904193939.03a1f278@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Sep 2002 19:43:58 +0200 To: "Egidijus Antanaitis" , From: Seth Mos Subject: Re: In-Reply-To: <002201c2531c$ca1cccf0$4c00000a@lukoil.lt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 09:37 3-9-2002 +0200, Egidijus Antanaitis wrote: >Dear support, > recently I got stuck with such a problem. OS - Linux RedHat 7.3, kernel >2.4.18. Hardware - Intel Desktop Board D845BG motherboard, Pentium 4 >processor, HDD's Maxtor d740x-6l. Because of a bug in motherboard, the >system often freezes. I have found, the Alan's Cox patch 2.4.19-ac3 has the >workaround according to this, but when I do apply it, the xfs patch doesn't >work correctly any more. Also, I cannot apply the xfs patch to newest >RedHat's 2.4.18-10 kernel source. I got a lot of rejects in both cases. XFS >has not a xfs patch to 2.4.19 kernel, hence I am stuck. Is any solution >here? Thanks for any help:) What patch is this? Is is possible for you to use one of the Red Hat Linux based kernels with XFS bolted on? They have lot's fixes and workarounds for known buggy hardware, most of these patches are never integrated into the mainstream kernels or it takes a while. 2.4.18-4 is the latest kernel we have in that form at the moment, it's from the 1.1 release but should do well. I am using it with good results on the main database server at work. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:51:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:51:14 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HpBtG017827 for ; Wed, 4 Sep 2002 10:51:11 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17meMy-00012K-00; Wed, 04 Sep 2002 18:55:12 +0100 Date: Wed, 4 Sep 2002 18:55:12 +0100 From: Christoph Hellwig To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19- xfs oops Message-ID: <20020904185512.A3903@infradead.org> References: <3D758B28.9000406@belkam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D758B28.9000406@belkam.com>; from dm@belkam.com on Wed, Sep 04, 2002 at 09:25:12AM +0500 X-archive-position: 257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 09:25:12AM +0500, Dmitry Melekhov wrote: > Hello! > > We had our fileserver died this night. > Sorry, I wrote down oops info by hands (so it is possible > that there are mistypings) and I can't run ksymoops on 2.4.19, > because we switched back to 2.4.18 for now, so most of warinings > are skipped here. Hope, anyway, that this info can help. > > kernel BUG at filemap.c:843 mm/filemap.c in a stock kernel does not contain a BUG(). What patches do you use? From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:54:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:55:01 -0700 (PDT) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HswtG018332 for ; Wed, 4 Sep 2002 10:54:59 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17meQf-00013F-00; Wed, 04 Sep 2002 18:59:01 +0100 Date: Wed, 4 Sep 2002 18:59:01 +0100 From: Christoph Hellwig To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19- xfs oops Message-ID: <20020904185901.A4028@infradead.org> References: <3D758B28.9000406@belkam.com> <20020904185512.A3903@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020904185512.A3903@infradead.org>; from hch@infradead.org on Wed, Sep 04, 2002 at 06:55:12PM +0100 X-archive-position: 258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 06:55:12PM +0100, Christoph Hellwig wrote: > On Wed, Sep 04, 2002 at 09:25:12AM +0500, Dmitry Melekhov wrote: > > Hello! > > > > We had our fileserver died this night. > > Sorry, I wrote down oops info by hands (so it is possible > > that there are mistypings) and I can't run ksymoops on 2.4.19, > > because we switched back to 2.4.18 for now, so most of warinings > > are skipped here. Hope, anyway, that this info can help. > > > > kernel BUG at filemap.c:843 > > mm/filemap.c in a stock kernel does not contain a BUG(). > What patches do you use? Sorry, I read 943. Of course it does. From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:02:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:02:58 -0700 (PDT) Received: from imf16bis.bellsouth.net (mail116.mail.bellsouth.net [205.152.58.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84I2rtG018876 for ; Wed, 4 Sep 2002 11:02:53 -0700 Received: from TAZ2 ([66.156.0.36]) by imf16bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020904180829.NWVS7192.imf16bis.bellsouth.net@TAZ2>; Wed, 4 Sep 2002 14:08:29 -0400 Date: Wed, 4 Sep 2002 14:05:14 -0400 From: Greg Freemyer Subject: re: mapcheck question To: Greg Freemyer , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020904180829.NWVS7192.imf16bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g84I2stG018878 X-archive-position: 259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> I think I have the latest mapcheck which was recently posted. (Thanks to >> whoever is supporting this.) >> unfortunately mapcheck -V gives "$Id:$", so I can't say what the version >> number is. >> My real question is if the -f or --force option is still valid. >> mapcheck -aq seems to work fine for me, but since I want to run this at >> the end of my backup script I assume I need the -f option to keep any >> interactive questions from occuring. >> Whenever I try to add a -f or --force, I get a usage statement. Replying to self, :o My mistake, mapcheck is always never asks for user input from what I can see in the code. The -f option is apparently to force it to process a filesystem even though it does not look like an XFS filesystem. (This is a guess from a very brief look at the code.) Regardless, the argument processing logic does not handle the -f or --force option, so if this is needed by anyone, the code is broken. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:33:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:33:17 -0700 (PDT) Received: from psygenomics.com (user1.psygenomics.com [66.200.78.178]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IX9tG021062 for ; Wed, 4 Sep 2002 11:33:10 -0700 Received: from localhost (root@localhost) by psygenomics.com (8.9.3/8.9.3) with ESMTP id OAA07568 for ; Wed, 4 Sep 2002 14:36:12 -0400 X-OpenMail-Hops: 1 Date: Wed, 4 Sep 2002 14:36:12 -0400 Message-Id: Subject: XFS bad block recording? MIME-Version: 1.0 From: dbarber@psygenomics.com TO: linux-xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=openmail-part-002387b2-00000002 X-archive-position: 260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dbarber@psygenomics.com Precedence: bulk X-list: linux-xfs --openmail-part-002387b2-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline; filename="BDY.RTF" ;Creation-Date="Wed, 4 Sep 2002 14:36:11 -0400" Content-Transfer-Encoding: quoted-printable Is there a way mark the bad blocks on the hard drive while mkfs'ing the drive? Or another tool to mark bad blocks on a live filesystem? Just curious. Thanks! Don --openmail-part-002387b2-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Wed, 4 Sep 2002 14:36:11 -0400" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250 dGJsDQp7XGYwXGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmll ciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xm bW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xjb2xvcnRibFxy ZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMx XHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIElzIHRoZXJlIGEgd2F5 IG1hcmsgdGhlIGJhZCBibG9ja3Mgb24gdGhlIGhhcmQgZHJpdmUgd2hpbGUg bWtmcydpbmcgdGhlIGRyaXZlPyAgT3IgYW5vdGhlciB0b29sIHRvIG1hcmsg YmFkIGJsb2NrcyBvbiBhIGxpdmUgZmlsZXN5c3RlbT8gIEp1c3QgY3VyaW91 cy5ccGFyDQpccGFyDQpUaGFua3MhXHBhcg0KXHBhcg0KRG9uXHBhcg0KfQ== --openmail-part-002387b2-00000002-- From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:40:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:40:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84Ie8tG021562 for ; Wed, 4 Sep 2002 11:40:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA17180 for ; Wed, 4 Sep 2002 13:44:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA29807 for ; Wed, 4 Sep 2002 13:44:07 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84If1T20957; Wed, 4 Sep 2002 13:41:01 -0500 Message-Id: <200209041841.g84If1T20957@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 13:41:01 -0500 Subject: TAKE - remove dead members of struct vfs X-archive-position: 261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs From Christoph: "These two are only ever set and never read." remove dead members of struct vfs Date: Wed Sep 4 11:43:38 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126693a linux/fs/xfs/xfs_vfsops.c - 1.378 linux/fs/xfs/xfs_mount.c - 1.300 linux/fs/xfs/linux/xfs_vfs.h - 1.29 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:41:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:41:19 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IfHtG021822 for ; Wed, 4 Sep 2002 11:41:17 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g84IjJBx035736; Wed, 4 Sep 2002 20:45:19 +0200 (CEST) Message-Id: <4.3.2.7.2.20020904204331.02e58070@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Sep 2002 20:44:08 +0200 To: dbarber@psygenomics.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS bad block recording? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 14:36 4-9-2002 -0400, dbarber@psygenomics.com wrote: >Is there a way mark the bad blocks on the hard drive while mkfs'ing the >drive? Or another tool to mark bad blocks on a live filesystem? Just >curious. Nope. XFS automatiically bails out on a IO error and umounts the filesystem to prevent further damage. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:41:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:41:26 -0700 (PDT) Received: from imf22bis.bellsouth.net (mail122.mail.bellsouth.net [205.152.58.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IfOtG021852 for ; Wed, 4 Sep 2002 11:41:24 -0700 Received: from TAZ2 ([66.156.0.36]) by imf22bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020904184514.YNRW2113.imf22bis.bellsouth.net@TAZ2>; Wed, 4 Sep 2002 14:45:14 -0400 Date: Wed, 4 Sep 2002 14:43:44 -0400 From: Greg Freemyer Subject: re: XFS bad block recording? To: , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020904184514.YNRW2113.imf22bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g84IfOtG021900 X-archive-position: 263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> Is there a way mark the bad blocks on the hard drive while mkfs'ing the >> drive? Or another tool to mark bad blocks on a live filesystem? Just >> curious. >> Thanks! >> Don I think badblocks are handled at the drive level anymore. Both with SCSI and IDE. If you look at a old drive and a new one, you will see on the old one a list of bad sectors as it left the factory. On new drives, they don't show it because the drive internally maps around the bad sectors. AFAIK, if a drive starts having end-user observable bad sectors, it is time to replace it. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:44:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:44:34 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IiWtG022935 for ; Wed, 4 Sep 2002 11:44:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA17329; Wed, 4 Sep 2002 13:48:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA93311; Wed, 4 Sep 2002 13:48:30 -0500 (CDT) Subject: Re: XFS bad block recording? From: Eric Sandeen To: dbarber@psygenomics.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Sep 2002 13:45:25 -0500 Message-Id: <1031165125.3056.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs The short answer is "no," and the longer answer is that by the time a modern drive is showing bad blocks to the user, it's a short trip to the dumpster, IMHO! -Eric On Wed, 2002-09-04 at 13:36, dbarber@psygenomics.com wrote: > Is there a way mark the bad blocks on the hard drive while mkfs'ing the > drive? Or another tool to mark bad blocks on a live filesystem? Just > curious. > > Thanks! > > Don > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:52:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:52:44 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IqftG023551 for ; Wed, 4 Sep 2002 11:52:41 -0700 Received: (qmail 7071 invoked by uid 500); 4 Sep 2002 18:56:12 -0000 Subject: Re: XFS bad block recording? From: Austin Gonyou To: Seth Mos Cc: dbarber@psygenomics.com, linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020904204331.02e58070@pop.xs4all.nl> References: <4.3.2.7.2.20020904204331.02e58070@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031165771.6421.72.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Sep 2002 13:56:11 -0500 X-archive-position: 265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-04 at 13:44, Seth Mos wrote: > At 14:36 4-9-2002 -0400, dbarber@psygenomics.com wrote: > >Is there a way mark the bad blocks on the hard drive while mkfs'ing > the > >drive? Or another tool to mark bad blocks on a live filesystem? > Just > >curious. > > Nope. XFS automatiically bails out on a IO error and umounts the > filesystem > to prevent further damage. Hrrmm....Something really bad happened then with my system. We had/have lots of IO errors on one host, now XFS can't replay the logs, mount segfaults. I don't think there's physical corruption, the disks are really new, but were working fine before, and after dumping the logs, things are good. I've got V1 logs though, dunno if that makes a difference. One of the HBAs or GBICs went bellyup on us, but XFS didn't shut-down. Now I can't mount. I don't want to dump the logs, anyone have any ideas? > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:55:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:55:58 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84ItstG024060 for ; Wed, 4 Sep 2002 11:55:55 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.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 LAA05982 for ; Wed, 4 Sep 2002 11:59:57 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA16864 for ; Wed, 4 Sep 2002 13:50:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA53394 for ; Wed, 4 Sep 2002 13:50:30 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84IlPu21194; Wed, 4 Sep 2002 13:47:25 -0500 Message-Id: <200209041847.g84IlPu21194@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 13:47:25 -0500 Subject: TAKE - make xfs_aops.c look like XFS source X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Again from Christoph: "Remove the misleading comment the refers to page_bufs (I've also removed the written by part as nothing else in XFS has it), use xfs.h insead of page_buf_internal.h, s/static/STATIC/g, use XFS's ASSERT() instead of hand-crafted assert()." make xfs_aops.c look like XFS source Date: Wed Sep 4 11:49:59 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126696a linux/fs/xfs/linux/xfs_aops.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:57:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:57:59 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IvttG024489 for ; Wed, 4 Sep 2002 11:57:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA12559 for ; Wed, 4 Sep 2002 14:01:53 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA62964 for ; Wed, 4 Sep 2002 14:01:53 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84IwmU21547; Wed, 4 Sep 2002 13:58:48 -0500 Message-Id: <200209041858.g84IwmU21547@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 13:58:48 -0500 Subject: TAKE - use wait_event in xfs_iunpin_wait X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Another one from Christoph. use wait_event in xfs_iunpin_wait Date: Wed Sep 4 12:01:30 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126700a linux/fs/xfs/xfs_inode.c - 1.349 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:59:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 12:00:05 -0700 (PDT) Received: from fruit.eu.org (qmailr@d4400fd8.cable.wanadoo.nl [212.64.15.216]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IxvtG025035 for ; Wed, 4 Sep 2002 11:59:58 -0700 Received: (qmail 28935 invoked by uid 500); 4 Sep 2002 19:03:58 -0000 Resent-Message-ID: <20020904190358.28934.qmail@fruit.eu.org> Date: Wed, 4 Sep 2002 21:03:08 +0200 From: Wessel Dankers To: Greg Freemyer Subject: Re: mapcheck question Message-ID: <20020904190308.GO567@fruit.eu.org> References: <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> User-Agent: Mutt/1.4i X-oi: oi Resent-From: wsl@fruit.eu.org Resent-Date: Wed, 4 Sep 2002 21:03:57 +0200 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-04 13:29:45-0400, Greg Freemyer wrote: > unfortunately mapcheck -V gives "$Id:$", so I can't say what the version number is. Yes, it isn't in CVS yet. I have added a date there instead. > Whenever I try to add a -f or --force, I get a usage statement. Silly bug. The force function was completely implemented but not checked for in the option interpreting part. Fixed too. I also imported Ethan Benson's changes. You can download the result from: URI: http://fruit.eu.org/mapcheck.c md5: 553db9cb32e754b33f0a4aa3151cab96 mapcheck.c sha1: 8be76862923130634471e597f3fbb053de07c92e mapcheck.c HTH, HAND! :) -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Wed Sep 4 12:27:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 12:27:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84JQxtG025760 for ; Wed, 4 Sep 2002 12:27:00 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA17396 for ; Wed, 4 Sep 2002 14:30:58 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA85411 for ; Wed, 4 Sep 2002 14:30:58 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id OAA06009 for linux-xfs@oss.sgi.com; Wed, 4 Sep 2002 14:30:57 -0500 (CDT) Date: Wed, 4 Sep 2002 14:30:57 -0500 (CDT) From: Dean Roehrich Message-Id: <200209041930.OAA06009@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add mtpt option to xfs.txt X-archive-position: 269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Sep 4 12:30:36 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:126702a linux/Documentation/filesystems/xfs.txt - 1.11 - add mtpt option to go with dmapi option. remove xdsm option From owner-linux-xfs@oss.sgi.com Wed Sep 4 13:09:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 13:09:41 -0700 (PDT) Received: from femme.sapphite.org (root@pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84K9ZtG027465 for ; Wed, 4 Sep 2002 13:09:35 -0700 Received: from localhost (trish@localhost [127.0.0.1]) by femme.sapphite.org (8.12.6/8.12.5) with ESMTP id g84KE8C3001417 for ; Wed, 4 Sep 2002 16:14:09 -0400 (EDT) (envelope-from trish@bsdunix.net) Date: Wed, 4 Sep 2002 16:14:08 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Subject: possible xfs panic? Message-ID: <20020904160646.V426-100000@femme.sapphite.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: trish@bsdunix.net Precedence: bulk X-list: linux-xfs THis is with: Linux www-s1-3 2.4.19-xfs #1 SMP Tue Sep 3 22:45:09 EDT 2002 i686 unknown The XFS patch for 2.4.19 off oss.sgi.com [1]kdb> bt ESP EIP Function (args) 0xd27e5ba8 0xc01f01aa linvfs_follow_link+0x8e (0xeb16e3e0, 0xd27e5c0c,0xe783049c, 0xd27e5c0c) kernel .text 0xc0100000 0xc01f011c 0xc01f0208 0xd27e5bc0 0xc014470d link_path_walk+0x83d kernel .text 0xc0100000 0xc0143ed0 0xc014486c 0xd27e5bf8 0xc0144886 path_walk+0x1a (0xd27e4000, 0xc9659322, 0xc02b0f5e, 0x13) kernel .text 0xc0100000 0xc014486c 0xc0144888 0xd27e5bfc 0xc0141e3e open_exec+0x2e (0xc9659320, 0xc0389958, 0xc01569c4, 0xd27e5e6c, 0x0) kernel .text 0xc0100000 0xc0141e10 0xc0141edc 0xd27e5c2c 0xc0156c6e load_elf_binary+0x2aa (0xd27e5e6c, 0xd27e5fc4, 0xd27e5e6c, 0xd27e5e7c, 0xd27e5da2) kernel .text 0xc0100000 0xc01569c4 0xc015744c 0xd27e5d38 0xc0142786 search_binary_handler+0x7a (0xd27e5e6c, 0xd27e5fc4) kernel .text 0xc0100000 0xc014270c 0xc01428b0 0xd27e5d70 0xc0156262 load_script+0x1a2 (0xd27e5e6c, 0xd27e5fc4, 0xd27e5e6c, 0x0, 0xd27e5eec) kernel .text 0xc0100000 0xc01560c0 0xc01562a0 0xd27e5e18 0xc0142786 search_binary_handler+0x7a (0xd27e5e6c, 0xd27e5fc4) kernel .text 0xc0100000 0xc014270c 0xc01428b0 0xd27e5e50 0xc0142a45 do_execve+0x195 (0xd540a000, 0xbfffa890, 0x871cce4, 0xd27e5fc4, 0xd27e4000) kernel .text 0xc0100000 0xc01428b0 0xc0142aa0 0xd27e5fa4 0xc010758f sys_execve+0x2f (0x86a6b3c, 0xbfffa890, 0x871cce4, 0xbfffa890, 0x86a6b3c) kernel .text 0xc0100000 0xc0107560 0xc01075c0 0xd27e5fc4 0xc0108a3b system_call+0x33 kernel .text 0xc0100000 0xc0108a08 0xc0108a40 [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc19de000 00000001 00000000 0 000 stop 0xc19de370 init 0xc19d2000 00000002 00000001 0 000 stop 0xc19d2370 keventd 0xc19de000 00000001 00000000 0 000 stop 0xc19de370 init 0xc19d2000 00000002 00000001 0 000 stop 0xc19d2370 keventd 0xc19d0000 00000003 00000001 0 000 stop 0xc19d0370 ksoftirqd_CPU0 0xc19ce000 00000004 00000001 0 001 stop 0xc19ce370 ksoftirqd_CPU1 0xf7e3e000 00000005 00000001 0 000 run 0xf7e3e370 kswapd 0xf7e3c000 00000006 00000001 0 000 stop 0xf7e3c370 bdflush 0xf7e3a000 00000007 00000001 0 000 stop 0xf7e3a370 kupdated 0xf7e28000 00000008 00000001 0 000 run 0xf7e28370 pagebufd 0xf7e26000 00000009 00000001 0 000 stop 0xf7e26370 pagebuf_io_CPU0 0xf7e24000 00000010 00000001 0 001 stop 0xf7e24370 pagebuf_io_CPU1 0xf76a0000 00000017 00000001 0 001 stop 0xf76a0370 devfsd 0xf7322000 00000084 00000001 0 000 stop 0xf7322370 mdrecoveryd 0xf7658000 00000489 00000001 0 001 stop 0xf7658370 syslogd 0xf6e46000 00000494 00000001 0 001 run 0xf6e46370 klogd 0xf6dfe000 00000508 00000001 0 001 stop 0xf6dfe370 portmap 0xf6c1c000 00000581 00000001 0 001 stop 0xf6c1c370 rpciod 0xf6c0a000 00000582 00000001 0 000 stop 0xf6c0a370 lockd 0xf71b2000 00000597 00000001 0 000 stop 0xf71b2370 ntpd 0xf742e000 00000619 00000001 0 000 stop 0xf742e370 atd 0xf6a00000 00000631 00000001 0 001 stop 0xf6a00370 sshd 0xf69aa000 00000651 00000001 0 000 stop 0xf69aa370 xinetd 0xf687a000 00000663 00000001 0 001 stop 0xf687a370 exim 0xf3106000 00000693 00000001 0 000 stop 0xf3106370 httpd 0xf2f16000 00000694 00000693 0 000 stop 0xf2f16370 httpd 0xf2efe000 00000695 00000693 0 000 stop 0xf2efe370 httpd 0xf2eb6000 00000696 00000693 0 001 run 0xf2eb6370 httpd 0xf2e6c000 00000697 00000693 0 000 stop 0xf2e6c370 httpd 0xf2e22000 00000698 00000693 0 000 stop 0xf2e22370 httpd 0xf2dd8000 00000699 00000693 0 000 stop 0xf2dd8370 httpd 0xf2d8c000 00000700 00000693 0 000 stop 0xf2d8c370 httpd 0xf2d42000 00000701 00000693 0 000 stop 0xf2d42370 httpd 0xf2d8c000 00000700 00000693 0 000 stop 0xf2d8c370 httpd 0xf2d42000 00000701 00000693 0 000 stop 0xf2d42370 httpd 0xf2cfa000 00000702 00000693 0 000 stop 0xf2cfa370 httpd 0xf2cae000 00000703 00000693 0 000 stop 0xf2cae370 httpd 0xf2c66000 00000704 00000693 0 000 stop 0xf2c66370 httpd 0xf2c1a000 00000705 00000693 0 000 stop 0xf2c1a370 httpd 0xf2bd2000 00000706 00000693 0 000 stop 0xf2bd2370 httpd 0xf2b88000 00000707 00000693 0 000 stop 0xf2b88370 httpd 0xf2b40000 00000708 00000693 0 000 stop 0xf2b40370 httpd 0xf1426000 00000709 00000693 0 000 stop 0xf1426370 httpd 0xef76a000 00000710 00000693 0 000 stop 0xef76a370 httpd 0xee9ee000 00000711 00000693 0 000 stop 0xee9ee370 httpd 0xee9cc000 00000712 00000693 0 000 run 0xee9cc370 httpd 0xed832000 00000713 00000693 0 000 run 0xed832370 httpd 0xecff8000 00000714 00000693 0 000 stop 0xecff8370 httpd 0xecfd4000 00000715 00000693 0 000 stop 0xecfd4370 httpd 0xec66c000 00000720 00000001 0 001 run 0xec66c370 httpd 0xf538e000 00000734 00000720 0 001 run 0xf538e370 httpd 0xf5854000 00000747 00000001 0 000 stop 0xf5854370 crond 0xe39bc000 00001159 00000001 0 000 run 0xe39bc370 spread 0xf78e4000 00001179 00000001 0 000 stop 0xf78e4370 mingetty 0xeb096000 00001180 00000001 0 000 stop 0xeb096370 mingetty 0xf5bd8000 00001181 00000001 0 000 stop 0xf5bd8370 mingetty 0xf5c74000 00001182 00000001 0 000 stop 0xf5c74370 mingetty 0xf6806000 00001183 00000001 0 000 stop 0xf6806370 mingetty 0xe5f1a000 00001184 00000001 0 000 stop 0xe5f1a370 mingetty 0xe5e76000 00001185 00000001 0 001 stop 0xe5e76370 agetty 0xcd968000 00005117 00000693 0 000 stop 0xcd968370 httpd 0xcaa9e000 00005884 00000693 0 000 stop 0xcaa9e370 httpd 0xc516e000 00008702 00000693 0 000 stop 0xc516e370 httpd 0xc4966000 00008703 00000693 0 000 run 0xc4966370 httpd 0xc516e000 00008702 00000693 0 000 stop 0xc516e370 httpd 0xc4966000 00008703 00000693 0 000 run 0xc4966370 httpd 0xc582a000 00008704 00000693 0 000 stop 0xc582a370 httpd 0xc4182000 00008705 00000693 0 000 stop 0xc4182370 httpd 0xc4164000 00008706 00000693 0 000 stop 0xc4164370 httpd 0xc411a000 00008707 00000693 0 000 stop 0xc411a370 httpd 0xf548c000 00010519 00000720 0 001 stop 0xf548c370 httpd 0xe972e000 00010521 00000720 0 000 stop 0xe972e370 httpd 0xe73e6000 00010580 00000720 0 001 stop 0xe73e6370 httpd 0xe44ba000 00010742 00000747 0 001 stop 0xe44ba370 crond 0xe44d2000 00010745 00010742 0 001 stop 0xe44d2370 run-parts 0xe452a000 00010751 00010745 0 001 stop 0xe452a370 awk 0xe44a0000 00010752 00000001 0 001 stop 0xe44a0370 sa1 0xe44c2000 00010755 00010752 0 000 stop 0xe44c2370 sadc 0xe44dc000 00010757 00000720 0 000 stop 0xe44dc370 httpd 0xe43de000 00010759 00000720 0 000 stop 0xe43de370 httpd 0xe413c000 00010856 00000720 0 000 stop 0xe413c370 httpd 0xe4f42000 00011497 00000720 0 000 stop 0xe4f42370 httpd 0xf65ec000 00011507 00000720 0 000 stop 0xf65ec370 httpd 0xebe7a000 00011527 00000720 0 000 stop 0xebe7a370 httpd 0xe2ecc000 00011580 00000720 0 000 stop 0xe2ecc370 httpd 0xe30bc000 00011584 00000720 0 001 stop 0xe30bc370 httpd 0xd9a76000 00011585 00000720 0 001 stop 0xd9a76370 httpd 0xe3966000 00011592 00000720 0 001 stop 0xe3966370 httpd 0xe327a000 00011597 00000720 0 001 stop 0xe327a370 httpd 0xd9f0c000 00011605 00000720 0 000 stop 0xd9f0c370 httpd 0xd95bc000 00011626 00000720 0 000 stop 0xd95bc370 httpd 0xd94c0000 00011628 00000720 0 001 stop 0xd94c0370 httpd 0xd958a000 00011629 00000720 0 000 stop 0xd958a370 httpd 0xe3c1c000 00011756 00000631 0 000 stop 0xe3c1c370 sshd 0xe5720000 00011758 00011756 0 001 stop 0xe5720370 bash 0xe3c1c000 00011756 00000631 0 000 stop 0xe3c1c370 sshd 0xe5720000 00011758 00011756 0 001 stop 0xe5720370 bash 0xf2f68000 00011797 00011507 0 000 stop 0xf2f68370 serve.cgi 0xd27e4000 00011804 00011629 1 001 run 0xd27e4370*httpd 0xe2268000 00011807 00011758 0 001 stop 0xe2268370 apachectl 0xcbb78000 00011808 00011807 1 000 run 0xcbb78370 apachectl -- Trish Lynch trish@bsdunix.net Ecartis Core Team trish@listmistress.org Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD From owner-linux-xfs@oss.sgi.com Wed Sep 4 13:19:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 13:20:00 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84KJttG028036 for ; Wed, 4 Sep 2002 13:19:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA17795 for ; Wed, 4 Sep 2002 15:23:54 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA19290 for ; Wed, 4 Sep 2002 15:23:54 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84KKmn23318; Wed, 4 Sep 2002 15:20:48 -0500 Message-Id: <200209042020.g84KKmn23318@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 15:20:48 -0500 Subject: TAKE - remove copyin/copyout X-archive-position: 271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Still more from Christoph. "copyin/copyout is used only six times in the actual XFS code. Also remove an unused member of struct uio and and enum uio_seg members that don't make sense on Linux." remove copyin/copyout Date: Wed Sep 4 13:22:39 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126707a linux/fs/xfs/xfs_itable.c - 1.110 linux/fs/xfs/xfs_dfrag.c - 1.35 linux/fs/xfs/xfs_bmap.c - 1.291 linux/fs/xfs/support/move.h - 1.9 linux/fs/xfs/support/move.c - 1.8 From owner-linux-xfs@oss.sgi.com Wed Sep 4 13:52:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 13:52:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84KqgtG028849 for ; Wed, 4 Sep 2002 13:52:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA17380 for ; Wed, 4 Sep 2002 15:56:41 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA75008 for ; Wed, 4 Sep 2002 15:56:41 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84KrYr23710; Wed, 4 Sep 2002 15:53:34 -0500 Message-Id: <200209042053.g84KrYr23710@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 15:53:34 -0500 Subject: TAKE - merge xfs_get_vfsmount into it's only caller X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Christoph won't let me do any of my own work today! "There wasn't much left of the old IRIX functionality.." merge xfs_get_vfsmount into it's only caller Date: Wed Sep 4 13:54:02 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126715a linux/fs/xfs/xfs_vfsops.c - 1.379 From owner-linux-xfs@oss.sgi.com Wed Sep 4 16:18:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 16:18:28 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84NIOtG003966 for ; Wed, 4 Sep 2002 16:18:24 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 QAA02025 for ; Wed, 4 Sep 2002 16:22:26 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA72075 for linux-xfs@oss.sgi.com; Thu, 5 Sep 2002 09:21:09 +1000 (EST) Date: Thu, 5 Sep 2002 09:21:09 +1000 (EST) From: Nathan Scott Message-Id: <200209042321.JAA72075@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - attr/acl updates X-archive-position: 273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Some minor updates from AndreasG, see doc/CHANGES for details. cheers. Date: Wed Sep 4 16:19:54 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126729a cmd/acl/VERSION - 1.36 cmd/acl/doc/CHANGES - 1.41 cmd/acl/debian/changelog - 1.30 cmd/attr/VERSION - 1.22 cmd/attr/doc/CHANGES - 1.27 cmd/attr/debian/changelog - 1.23 cmd/attr/test/run - 1.3 cmd/attr/setfattr/setfattr.c - 1.10 cmd/attr/getfattr/getfattr.c - 1.16 cmd/acl/libacl/acl_get_file.c - 1.5 cmd/acl/libacl/acl_get_fd.c - 1.4 cmd/acl/libacl/acl_extended_file.c - 1.3 cmd/acl/libacl/acl_extended_fd.c - 1.3 cmd/acl/libacl/acl_delete_def_file.c - 1.5 cmd/acl/getfacl/getfacl.c - 1.5 cmd/acl/getfacl/user_group.h - 1.2 cmd/acl/getfacl/user_group.c - 1.3 cmd/acl/test/misc.test - 1.2 cmd/acl/test/run - 1.3 - minor updates from Andreas. From owner-linux-xfs@oss.sgi.com Wed Sep 4 20:50:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 20:50:33 -0700 (PDT) Received: from mail.aspec.ru (mail.aspec.ru [217.14.198.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g853oPtG011136 for ; Wed, 4 Sep 2002 20:50:26 -0700 Received: from [192.168.22.111] (HELO belkam.com) by mail.aspec.ru (CommuniGate Pro SMTP 3.5.9) with ESMTP id 699802 for linux-xfs@oss.sgi.com; Thu, 05 Sep 2002 08:54:24 +0500 Message-ID: <3D76D542.90104@belkam.com> Date: Thu, 05 Sep 2002 08:53:38 +0500 From: Dmitry Melekhov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: ru, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.19- xfs oops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@belkam.com Precedence: bulk X-list: linux-xfs >>Sorry, I wrote down oops info by hands (so it is possible >>that there are mistypings) and I can't run ksymoops on 2.4.19, >>because we switched back to 2.4.18 for now, so most of warinings >>are skipped here. Hope, anyway, that this info can help. > > I personally don't think we can do much with this oops. I don't even see a > xfs_ function called anywhere. OK :-) From owner-linux-xfs@oss.sgi.com Wed Sep 4 20:56:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 20:56:24 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g853txtG011512 for ; Wed, 4 Sep 2002 20:56:10 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id AD1885B87B; Wed, 4 Sep 2002 20:59:40 -0700 (PDT) Date: Wed, 4 Sep 2002 20:59:40 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: dbarber@psygenomics.com, linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? Message-ID: <20020905035940.GC6004@tapu.f00f.org> References: <1031165125.3056.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031165125.3056.18.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 01:45:25PM -0500, Eric Sandeen wrote: > The short answer is "no," and the longer answer is that by the time > a modern drive is showing bad blocks to the user, it's a short trip > to the dumpster, IMHO! It's a pretty rotten answer really :) I agree that since most (all?) modern drive transparently remap errors until the 'grown' table (or equivalent) is full that if you see errors your disk is in terrible shape and has been for some time, but it doesn't seem unreasonable for someone to want to mark part of the disk bad and have the fs avoid this. Almost ever other fs I can think of allows this kind of thing. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 4 22:39:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 22:39:08 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g855d2tG015058 for ; Wed, 4 Sep 2002 22:39:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 WAA02272 for ; Wed, 4 Sep 2002 22:43:05 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA55247 for linux-xfs@oss.sgi.com; Thu, 5 Sep 2002 15:41:45 +1000 (EST) Date: Thu, 5 Sep 2002 15:41:45 +1000 (EST) From: Nathan Scott Message-Id: <200209050541.PAA55247@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_aops.c cleanup (contd). X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Help out a bit with the tidyup work - this keeps related aops/iops code together a bit more, and two less files. cheers. Date: Wed Sep 4 22:37:11 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/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:126748a linux/fs/xfs/xfs_dmapi.c - 1.78 linux/fs/xfs/xfs_vfsops.c - 1.380 linux/fs/xfs/xfs_iget.c - 1.170 linux/fs/xfs/linux/xfs_lrw.c - 1.166 linux/fs/xfs/linux/xfs_linux.h - 1.84 linux/fs/xfs/linux/xfs_ioctl.c - 1.76 linux/fs/xfs/linux/xfs_xattr.c - 1.20 linux/fs/xfs/linux/xfs_xattr.h - 1.7 - remove an unneeded #include file. linux/fs/xfs/linux/Makefile - 1.63 linux/fs/xfs/linux/Makefile.in - 1.13 - xfs_xattr.o has been merged in with xfs_iops.o. linux/fs/xfs/linux/xfs_vnode.c - 1.97 linux/fs/xfs/linux/xfs_super.c - 1.211 - remove an unneeded #include file. linux/fs/xfs/linux/xfs_iops.c - 1.172 - move the xattr inode operations into here, move the address_space operations into xfs_aops.c. no functional change, but one less file & a bunch more static functions. linux/fs/xfs/linux/xfs_iops.h - 1.16 - merge xfs_xattr.h in here as the xattr ops are all inode ops. linux/fs/xfs/linux/xfs_aops.c - 1.3 - move the address_space operations from xfs_iops.c into here, make a bunch of stuff static now. remove a few more remnants of the pb/pagebuf naming scheme that remained here too. From owner-linux-xfs@oss.sgi.com Wed Sep 4 23:00:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 23:00:54 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8560qtG016039 for ; Wed, 4 Sep 2002 23:00:52 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17mplO-0000to-00 for linux-xfs@oss.sgi.com; Thu, 05 Sep 2002 00:05:10 -0600 Message-ID: <3D76F3E9.5090808@emergence.com> Date: Thu, 05 Sep 2002 00:04:25 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? References: <1031165125.3056.18.camel@stout.americas.sgi.com> <20020905035940.GC6004@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > It's a pretty rotten answer really :) > > I agree that since most (all?) modern drive transparently remap errors > until the 'grown' table (or equivalent) is full that if you see errors > your disk is in terrible shape and has been for some time, but it > doesn't seem unreasonable for someone to want to mark part of the disk > bad and have the fs avoid this. > > Almost ever other fs I can think of allows this kind of thing. > > --cw You should check out the Bad Block on Disk Drive section at: http://linas.org/linux/raid.html Which then links to this LKML discussion about the issue about bad block capabilities in 2.5: Basically even with ext2/ext3, with the drive failing spectacularly, it's pretty much game over for that drive. EVMS and LVM may have addressed this issue where the LVM/EVMS layer is actually handling the physical disks and can reallocate bad blocks on the fly. As he mentions many drives are using s.m.a.r.t these days, and monitoring your devices for that is probably useful. -Mike From owner-linux-xfs@oss.sgi.com Wed Sep 4 23:58:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 23:58:32 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g856wQtG018083 for ; Wed, 4 Sep 2002 23:58:26 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 580941C2A62; Thu, 5 Sep 2002 00:02:32 -0700 (PDT) Date: Thu, 5 Sep 2002 00:02:32 -0700 From: Chris Wedgwood To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? Message-ID: <20020905070232.GA6430@tapu.f00f.org> References: <1031165125.3056.18.camel@stout.americas.sgi.com> <20020905035940.GC6004@tapu.f00f.org> <3D76F3E9.5090808@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D76F3E9.5090808@emergence.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Sep 05, 2002 at 12:04:25AM -0600, Michael Best wrote: > Basically even with ext2/ext3, with the drive failing spectacularly, > it's pretty much game over for that drive. For gradual failures or "bad blocks in stasis" it would be nice to have the fs avoid these. > EVMS and LVM may have addressed this issue where the LVM/EVMS layer > is actually handling the physical disks and can reallocate bad > blocks on the fly. Arguably, you shouldn't need to use LVM to deal with bad blocks. Anyhow, this is getting rather OT. If XFS cannot deal with bad-blocks (I'm not talking about failing drives), then that is that and other means are required. --cw From owner-linux-xfs@oss.sgi.com Thu Sep 5 00:20:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 00:20:41 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g857KZtG019354 for ; Thu, 5 Sep 2002 00:20:36 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 8A5381431F; Thu, 5 Sep 2002 09:24:36 +0200 (MEST) Date: Thu, 5 Sep 2002 09:24:36 +0200 From: Andi Kleen To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? Message-ID: <20020905092436.A4780@wotan.suse.de> References: <1031165125.3056.18.camel@stout.americas.sgi.com> <20020905035940.GC6004@tapu.f00f.org> <3D76F3E9.5090808@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D76F3E9.5090808@emergence.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > Basically even with ext2/ext3, with the drive failing spectacularly, > it's pretty much game over for that drive. EVMS and LVM may have > addressed this issue where the LVM/EVMS layer is actually handling the > physical disks and can reallocate bad blocks on the fly. EVMS has a BBR module for this. But I agree with Eric Sandeen on this - when your disk shows bad sectors and ran out of its internal remapping space you should get rid of it ASAP. -Andi From owner-linux-xfs@oss.sgi.com Thu Sep 5 09:40:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 09:41:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85GevtG025576 for ; Thu, 5 Sep 2002 09:40:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA27113 for ; Thu, 5 Sep 2002 11:44:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA10461 for ; Thu, 5 Sep 2002 11:44:59 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g85Gfjd05329; Thu, 5 Sep 2002 11:41:45 -0500 Message-Id: <200209051641.g85Gfjd05329@stout.americas.sgi.com> Date: Thu, 5 Sep 2002 11:41:45 -0500 Subject: TAKE - Remove mrquota/QUOTAMAYBE mount option X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs There was an undocumented "mrquota" mount option which essentially said "if quota is marked as being on in the superblock, enable quota on mount; don't enable it otherwise." This was really only for the IRIX miniroot environment and is unused in Linux, so take it out. Remove mrquota/QUOTAMAYBE mount option Date: Thu Sep 5 09:43:35 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126776a linux/fs/xfs/xfs_log_recover.c - 1.241 linux/fs/xfs/xfs_vfsops.c - 1.381 linux/fs/xfs/xfs_clnt.h - 1.34 linux/fs/xfs/xfs_qm.c - 1.83 linux/fs/xfs/xfs_quota.h - 1.29 linux/fs/xfs/linux/xfs_super.c - 1.212 From owner-linux-xfs@oss.sgi.com Thu Sep 5 10:57:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 10:57:20 -0700 (PDT) Received: from stumpy.chowhouse.com (root@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85HvGtG027475 for ; Thu, 5 Sep 2002 10:57:16 -0700 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.11.6/8.11.3) with ESMTP id g85I1Nl27737 for ; Thu, 5 Sep 2002 12:01:23 -0600 Date: Thu, 5 Sep 2002 12:01:23 -0600 (MDT) From: James Rich To: XFS mailing list Subject: update summary page Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@stumpy.chowhouse.com Precedence: bulk X-list: linux-xfs I've updated the CVS summary for August 27 - September 5. Quite a bit of work has been done during that period. If people feel there are some significant issues or important checkins that should be listed in the "Significant issues" section please let me know. The summary page is available at: http://www.chowhouse.com/~james/xfs/checklist.html James Rich From owner-linux-xfs@oss.sgi.com Thu Sep 5 11:52:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 11:52:56 -0700 (PDT) Received: from mailrtr1.mailzone.edeltacom.com (IDENT:mirapoint@mailrtr1.mailzone.edeltacom.com [216.248.176.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85IqntI029069 for ; Thu, 5 Sep 2002 11:52:51 -0700 Received: from Obkgrjd (66-0-27-113.deltacom.net [66.0.27.113]) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ACQ88038; Thu, 5 Sep 2002 14:56:53 -0400 (EDT) Date: Thu, 5 Sep 2002 14:56:53 -0400 (EDT) Message-Id: <200209051856.ACQ88038@mailrtr1.mailzone.edeltacom.com> From: cbono To: linux-xfs@oss.sgi.com Subject: 980000) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Bq50vA3GEMK X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cbono@protective.com Precedence: bulk X-list: linux-xfs --Bq50vA3GEMK Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on mailrtr1.mailzone.edeltacom.com) Found virus WORM_KLEZ.H in file alt.pif The uncleanable file was deleted. ********************************************************* --Bq50vA3GEMK Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --Bq50vA3GEMK Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on mailrtr1.mailzone.edeltacom.com) alt.pif was removed from here because it contained a virus. ********************************************************* --Bq50vA3GEMK Content-Type: application/octet-stream; name=sinfest[1].htm Content-Transfer-Encoding: base64 Content-ID: PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkF1dGhvciIgY29udGVudD0iVGF0c3V5YSBJc2hpZGEiPg0KICAgPG1ldGEg bmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNb3ppbGxhLzQuNjEgW2VuXSAoV2luOTU7IEkp IFtOZXRzY2FwZV0iPg0KICAgPHRpdGxlPlNpbmZlc3Q8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgdGV4dD0iI0ZGRkZGRiIgYmdjb2xvcj0iI0ZGRkZGRiIgbGluaz0iI0ZGRkZGRiIgdmxp bms9IiNGRkZGRkYiIGFsaW5rPSIjRkYwMDAwIiBiYWNrZ3JvdW5kPSJtYXV2ZV90aWxlLmdp ZiIgbGVmdG1hcmdpbj0wICByaWdodG1hcmdpbj0wICBtYXJnaW5oZWlnaHQ9MCAgbWFyZ2lu d2lkdGg9MCAgdG9wbWFyZ2luPTAgPgo8U0NSSVBUIExBTkdVQUdFPSJKYXZhU2NyaXB0Ij4K PCEtLQp2YXIgYXhlbCA9IE1hdGgucmFuZG9tKCkgKyAiIjsKdmFyIG9yZCA9IE1hdGgucm91 bmQoYXhlbCAqIDEwMDAwMDApOwovLyBUaGlzIHBhcnQgb2Ygc2NyaXB0IGFsbGV2aWF0ZXMg YSBOZXRzY2FwZSBkb2N1bWVudC53cml0ZSBidWcKTlM0ID0gZG9jdW1lbnQubGF5ZXJzOwpp ZiAoTlM0KSB7Cm9yaWdXaWR0aCA9IGlubmVyV2lkdGg7Cm9yaWdIZWlnaHQgPSBpbm5lckhl aWdodDsKfQpmdW5jdGlvbiByZURvKCkgewppZiAoaW5uZXJXaWR0aCAhPSBvcmlnV2lkdGgg fHwgaW5uZXJIZWlnaHQgIT0gb3JpZ0hlaWdodCkKbG9jYXRpb24ucmVsb2FkKCk7Cn0KaWYg KE5TNCkgb25yZXNpemUgPSByZURvOwovLy0tPgo8L1NDUklQVD4KICAgIAo8c2NyaXB0IGxh bmd1YWdlPSJqYXZhc2NyaXB0IiB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgo8IS0tCnZhciBh ZGNvb2tpZSA9ICIiOwp2YXIga2VlbmFkc2l6ZSA9ICJub3JtYWwiOwp2YXIgd2FycGVuYWJs ZWQgPSBmYWxzZTsKdmFyIGFkZnZhbGlkID0gZmFsc2U7CnZhciByZXBsYWQgPSAiIjsKdmFy IGFkYmFubG9jID0gIiI7CnZhciB3YXJwYWxpdmUgPSB0cnVlOwp2YXIgZ2F2emFkaWQgPSAi c2luZmVzdCI7Ci8vLS0+Cjwvc2NyaXB0Pgo8U0NSSVBUIExBTkdVQUdFPSJKQVZBU0NSSVBU IiBTUkM9Imh0dHA6Ly93d3cua2VlbnNwb3Qub3JnL3ByZW1pdW0tc2VydmljZXMvZ2V0Y29v a2llLmNnaSI+CjwvU0NSSVBUPgogPFNDUklQVCBMQU5HVUFHRT0iSkFWQVNDUklQVCI+CiA8 IS0tCmlmIChhZGNvb2tpZSAhPSAiIikgewogZG9jdW1lbnQud3JpdGUoIjxTIisiQ1JJUFQg TEFOR1VBR0U9J0pBVkFTQ1JJUFQnIFNSQz0naHR0cDovL3d3dy5rZWVuc3BvdC5vcmcvcHJl bWl1bS1zZXJ2aWNlcy9kZWNvb2tpZS5jZ2k/IitvcmQrIic+PC9TIisiQ1JJUFQ+Iik7CiBk b2N1bWVudC53cml0ZSgiPFMiKyJDUklQVCBMQU5HVUFHRT0nSkFWQVNDUklQVCcgU1JDPSdo dHRwOi8vd3d3LmtlZW5zcG90Lm9yZy9wcmVtaXVtL3dhcnBjaGVjay5qcyc+PC9TIisiQ1JJ UFQ+Iik7Cn0KIC8vLS0+CjwvU0NSSVBUPgogPFNDUklQVCBMQU5HVUFHRT0iSkFWQVNDUklQ VCI+CiA8IS0tCmlmICghYWRmdmFsaWQpIHsKIGRvY3VtZW50LndyaXRlKCI8UyIrIkNSSVBU IExBTkdVQUdFPSdKQVZBU0NSSVBUJyBTUkM9J2h0dHA6Ly9hZC5rZWVuc3BhY2UuY29tL2J1 cnN0Zm4uanMnPjxcL1MiKyJDUklQVD4iKTsKfQogLy8tLT4KPC9TQ1JJUFQ+CjxTQ1JJUFQg TEFOR1VBR0U9SmF2YVNjcmlwdD4KPCEtLQppZiAoYWRmdmFsaWQgIT0gdHJ1ZSkgIHsKICB2 YXIgSW50ZXJuZXRFeHBsb3JlciA9IG5hdmlnYXRvci5hcHBOYW1lLmluZGV4T2YoIk1pY3Jv c29mdCIpICE9IC0xOwogIC8vIEhhbmRsZSBhbGwgdGhlIHRoZSBGU0NvbW1hbmQgbWVzc2Fn ZXMgaW4gYSBGbGFzaCBtb3ZpZQogIGZ1bmN0aW9uIEJhbm5lck1lbnVfRG9GU0NvbW1hbmQo Y29tbWFuZCwgYXJncykgewogICAgdmFyIEJhbm5lck1lbnVPYmogPSBJbnRlcm5ldEV4cGxv cmVyID8gQmFubmVyTWVudSA6IGRvY3VtZW50LkJhbm5lck1lbnU7CiAgICAvLwogICAgaWYg KGNvbW1hbmQgPT0gMjgpIHsKICAgIE1haW5NZW51LnN0eWxlLnZpc2liaWxpdHk9J2hpZGRl bic7CiAgICB9CiAgICAvLwogIH0KICAvLyBIb29rIGZvciBJbnRlcm5ldCBFeHBsb3Jlcgog IGlmIChuYXZpZ2F0b3IuYXBwTmFtZSAmJiBuYXZpZ2F0b3IuYXBwTmFtZS5pbmRleE9mKCJN aWNyb3NvZnQiKSAhPSAtMSAmJgogICAgICAgICAgICBuYXZpZ2F0b3IudXNlckFnZW50Lmlu ZGV4T2YoIldpbmRvd3MiKSAhPSAtMSAmJiBuYXZpZ2F0b3IudXNlckFnZW50LmluZGV4T2Yo IldpbmRvd3MgMy4xIikgPT0gLTEgJiYgbmF2aWdhdG9yLnVzZXJBZ2VudC5pbmRleE9mKCJP cGVyYSIpID09IC0xKSB7CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgnPFMnKydDUklQVCBM QU5HVUFHRT1WQlNjcmlwdD4gXG4nKTsKICAgICAgICAgIGRvY3VtZW50LndyaXRlKCdvbiBl cnJvciByZXN1bWUgbmV4dCBcbicpOwogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJ1N1YiBC YW5uZXJNZW51X0ZTQ29tbWFuZChCeVZhbCBjb21tYW5kLCBCeVZhbCBhcmdzKVxuJyk7CiAg ICAgICAgICBkb2N1bWVudC53cml0ZSgnICBjYWxsIEJhbm5lck1lbnVfRG9GU0NvbW1hbmQo Y29tbWFuZCwgYXJncylcbicpOwogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJ2VuZCBzdWJc bicpOwogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJzxcL1MnKydDUklQVD4gXG4nKTsKICB9 CiAgCiAgdmFyIEludGVybmV0RXhwbG9yZXIgPSBuYXZpZ2F0b3IuYXBwTmFtZS5pbmRleE9m KCJNaWNyb3NvZnQiKSAhPSAtMTsKICAvLyBIYW5kbGUgYWxsIHRoZSB0aGUgRlNDb21tYW5k IG1lc3NhZ2VzIGluIGEgRmxhc2ggbW92aWUKICBmdW5jdGlvbiBCYW5uZXJfRG9GU0NvbW1h bmQoY29tbWFuZCwgYXJncykgewogICAgdmFyIEJhbm5lck9iaiA9IEludGVybmV0RXhwbG9y ZXIgPyBCYW5uZXIgOiBkb2N1bWVudC5CYW5uZXI7CiAgICAvLwogICAgaWYgKGNvbW1hbmQg PT0gMjAwKSB7CiAgCiAgICBNYWluTWVudS5zdHlsZS5waXhlbExlZnQ9MjIwOwogICAgTWFp bk1lbnUuc3R5bGUucGl4ZWxUb3A9MTA7CiAgCiAgICBNYWluTWVudS5zdHlsZS52aXNpYmls aXR5PScnOwogICAgfQogICAgLy8KICB9CiAgLy8gSG9vayBmb3IgSW50ZXJuZXQgRXhwbG9y ZXIKICBpZiAobmF2aWdhdG9yLmFwcE5hbWUgJiYgbmF2aWdhdG9yLmFwcE5hbWUuaW5kZXhP ZigiTWljcm9zb2Z0IikgIT0gLTEgJiYKICAgICAgICAgICAgbmF2aWdhdG9yLnVzZXJBZ2Vu dC5pbmRleE9mKCJXaW5kb3dzIikgIT0gLTEgJiYgbmF2aWdhdG9yLnVzZXJBZ2VudC5pbmRl eE9mKCJXaW5kb3dzIDMuMSIpID09IC0xICYmIG5hdmlnYXRvci51c2VyQWdlbnQuaW5kZXhP ZigiT3BlcmEiKSA9PSAtMSkgewogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJzxTJysnQ1JJ UFQgTEFOR1VBR0U9VkJTY3JpcHQ+IFxuJyk7CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgn b24gZXJyb3IgcmVzdW1lIG5leHQgXG4nKTsKICAgICAgICAgIGRvY3VtZW50LndyaXRlKCdT dWIgQmFubmVyX0ZTQ29tbWFuZChCeVZhbCBjb21tYW5kLCBCeVZhbCBhcmdzKVxuJyk7CiAg ICAgICAgICBkb2N1bWVudC53cml0ZSgnICBjYWxsIEJhbm5lcl9Eb0ZTQ29tbWFuZChjb21t YW5kLCBhcmdzKVxuJyk7CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgnZW5kIHN1YlxuJyk7 CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgnPFwvUycrJ0NSSVBUPiBcbicpOwogIH0KfQov Ly0tPgo8L1NDUklQVD4KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPTIgd2lkdGg9IjEwMCUiIGJhY2tncm91bmQ9IiIgYmdjb2xvcj0iIzYwNmE2MCIg Ym9yZGVyY29sb3I9IiMwMDAwMDAiIGhlaWdodD0iMzAiIGhzcGFjZT0iMCIgdnNwYWNlPSIw Ij4KIDx0cj4KICAgPHRkIGFsaWduPSJsZWZ0IiB2YWxpZ249Im1pZGRsZSI+CiAgICAgPGEg aHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20iPjxpbWcgIHNyYz0iaHR0cDovL3d3dy5r ZWVuc3BvdC5vcmcvaW1hZ2VzL2hlYWRlci1rZWVuc3BvdGxvZ29fdHIuZ2lmIiBib3JkZXI9 IjAiIGhzcGFjZT0iMCIgd2lkdGg9IjEwMSIgaGVpZ2h0PSIyOCI+PC9hPgogICA8L3RkPjx0 ZD48c2NyaXB0IGxhbmd1YWdlPSJqYXZhc2NyaXB0Ij48IS0tCmlmKGFkZnZhbGlkID09IHRy dWUpIHsKIHZhciB3YXJwaW1hZ2UgPSAid2FycGRpc2FibGVkLmdpZiI7CiBpZighd2FycGFs aXZlKSB2YXIgd2FycGltYWdlID0gIndhcnBvdXQuZ2lmIjsKIGlmKHdhcnBlbmFibGVkICYm IHdhcnBhbGl2ZSkgdmFyIHdhcnBpbWFnZSA9ICJ3YXJwZW5nYWdlZC5naWYiOwogZG9jdW1l bnQud3JpdGUoJzxhIGhyZWY9IicrYWZiYW5sb2MrJyI+PGltZyBib3JkZXI9MCBzcmM9Imh0 dHA6Ly93d3cua2VlbnNwb3Qub3JnL3ByZW1pdW0vaW1hZ2VzLycrd2FycGltYWdlKyciPjwv YT4nKTsKfSBlbHNlIHsKZG9jdW1lbnQud3JpdGUoJyZuYnNwOycpOwp9Ci8vLS0+PC9zY3Jp cHQ+PG5vc2NyaXB0PiZuYnNwOzwvbm9zY3JpcHQ+PC90ZD48dGQgYWxpZ249Y2VudGVyIHZh bGlnbj0ibWlkZGxlIj4KICAgPGNlbnRlcj48aW1nIHNyYz1odHRwOi8vd3d3LmtlZW5zcG90 Lm9yZy9oZWFkZXItY29taWNsaW5raW1hZ2VzL2hlYWRlci10cnl0aGlzc3BvdC5naWY+PFND UklQVCBMQU5HVUFHRT0iSmF2YVNjcmlwdCI+CjwhLS0KdmFyIEtlZW5IZWFkZXJQaXggPSBu ZXcgQXJyYXkoImFsaWNlY29taWNzLmNvbSIsImFzaGZpZWxkb25saW5lLmNvbSIsImF2YWxv bmhpZ2guY29tIiwiYmF5c2lkLmNvbSIsImJvYmJpbnMub3JnIiwiYnJ1bm90aGViYW5kaXQu Y29tIiwiY2hvcHBpbmdibG9jay5vcmciLCJjbGFub2Z0aGVjYXRzLmNvbSIsImNvb2xjYXRz dHVkaW8uY29tIiwiY3JmaC5uZXQiLCJjdXRld2VuZHkuY29tIiwiZWxmbGlmZS5jb20iLCJl dmVyeXRoaW5namFrZS5jb20iLCJleHBsb2l0YXRpb25ub3cuY29tIiwiZmF0LWplc3VzLmNv bSIsImZ1bm55ZmFybWNvbWljcy5jb20iLCJnZW5lY2F0bG93LmNvbSIsImdwZi1jb21pY3Mu Y29tIiwiZ3JleXN0b25laW5uLm5ldCIsImhvdW5kc2hvbWUuY29tIiwiaXRzd2Fsa3kuY29t Iiwiam9lYXZlcmFnZS5vcmciLCJrZWVuc3BvdC5jb20iLCJrcmF6eWxhcnJ5LmNvbSIsImxp dmluZ2luZ3JleXRvd24uY29tIiwibG9va3doYXRpYnJvdWdodGhvbWUuY29tIiwibG9zdGFu ZGZvdW5kY29taWMuY29tIiwibWVsb25wb29sLmNvbSIsIm1yY2h1Y2tzaG93LmNvbSIsIm5l d3Nob3VuZHMuY29tIiwibnVrZWVzLmNvbSIsInBlbnRhc21hbC5jb20iLCJwb2lzb25lZG1p bmRzLmNvbSIsInJhZGNvbWljcy5jb20iLCJyZWFsbGlmZWNvbWljcy5jb20iLCJyb2Fkd2Fm Zmxlcy5jb20iLCJycGd3b3JsZGNvbWljLmNvbSIsInNjaGxvY2ttZXJjZW5hcnkuY29tIiwi c2luZmVzdC5uZXQiLCJzb2Fwcm9wZS5jb20iLCJzdWJ1cmJhbmp1bmdsZS5jb20iLCJzdXBl cm9zaXR5LmNvbSIsInRoZWNsYXNzbS5jb20iLCJ1YmVyc29mdC5uZXQiLCJ3YW5kZXJpbmdv bmVzLmNvbSIsIndoZW5pZ3Jvd3VwLm5ldCIsInlvdWRhbW5raWQuY29tIik7CnJhbmRvbU51 bSA9IE1hdGguZmxvb3IoTWF0aC5yYW5kb20oKSAqIDQ2KTsKZG9jdW1lbnQud3JpdGUoIjxh IGhyZWY9aHR0cDovL3d3dy4iKTsKZG9jdW1lbnQud3JpdGUoS2VlbkhlYWRlclBpeFtyYW5k b21OdW1dKTsKZG9jdW1lbnQud3JpdGUoIj48aW1nIGJvcmRlcj0wIHNyYz1odHRwOi8vd3d3 LmtlZW5zcG90Lm9yZy9oZWFkZXItY29taWNsaW5raW1hZ2VzL2NvbWljbGluay0iKTsKZG9j dW1lbnQud3JpdGUoS2VlbkhlYWRlclBpeFtyYW5kb21OdW1dKTsKZG9jdW1lbnQud3JpdGUo Ii5naWY+PC9hIik7CiAvLyAtLT4KPC9TQ1JJUFQ+PC9jZW50ZXI+PC90ZD48dGQgYWxpZ249 bWlkZGxlPjx0YWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+PHRk IHdpZHRoPTQwPjxhIGhyZWY9Imh0dHA6Ly93d3cua2VlbnNwb3QuY29tL2tzbmV3cy9rc25l d3MyMDAyMDcyNy5odG1sIj48aW1nIHdpZHRoPTQwIGhlaWdodD0yOCBib3JkZXI9MCBzcmM9 Imh0dHA6Ly93d3cua2VlbnNwb3QuY29tL2ltYWdlcy9rZWVubmV3c2xvZ28uZ2lmIj48L2E+ PC90ZD48dGQgd2lkdGg9OTA+PGEgaHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20va3Nu ZXdzL2tzbmV3czIwMDIwNzI3Lmh0bWwiPjxpbWcgYm9yZGVyPTAgd2lkdGg9OTAgaGVpZ2h0 PTI4IHNyYz0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20va3NuZXdzL2tlZW5uZXdzMjAwMjA3 MjcuZ2lmIj48L2E+PC90YWJsZT4KPC90ZD48dGQgYWxpZ249InJpZ2h0IiB2YWxpZ249Im1p ZGRsZSI+CjxUQUJMRSBCT1JERVI9IjAiIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElORz0i MCI+CjxTQ1JJUFQgTEFOR1VBR0U9IkphdmFzY3JpcHQiPgo8IS0tCiAgICAgICAgZnVuY3Rp b24ga2VlblN3aXRjaDIodXJsKSAgICAgICAgewogICAgICAgICAgICAgICAgaWYgKHVybCAh PSAnJykgIHsKICAgICAgICAgICAgICAgICAgICAgICAgdG9wLmxvY2F0aW9uLmhyZWYgPSB1 cmw7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQovLy0tPgo8L1NDUklQVD4KPEZPUk0g QUNUSU9OPSJodHRwOi8vd3d3LmtlZW5zcG90LmNvbS9jZ2ktYmluL2Ryb3Bkb3duLmNnaSIg TUVUSE9EPSIiIE5BTUU9ImtlZW5TdHJpcCIgVEFSR0VUPSJjb21pY3dpbmRvdyI+CiAgICAg ICAgPFRSPjxURCBhbGlnbj0iY2VudGVyIj4KPGlucHV0IHR5cGU9aGlkZGVuIG5hbWU9ZG9t YWluIHZhbHVlPXd3dy5zaW5mZXN0Lm5ldD4KPFNFTEVDVCBOQU1FPSJzaXRlSW5kZXgiIG9u Q2hhbmdlPSJrZWVuU3dpdGNoMih0aGlzLm9wdGlvbnNbc2VsZWN0ZWRJbmRleF0udmFsdWUp OyI+CgogICAgICAgICAgICAgICAgPE9QVElPTiBWQUxVRT0iIiBTRUxFQ1RFRD5TZWxlY3Qg YSBTcG90IQo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnNpbmZlc3QubmV0LyI+U2luZmVz dAo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnNvYXByb3BlLmNvbS8iPlNvYXAgb24gYSBS b3BlCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuaG9va2Vkb25jb21pY3MuY29tLyI+U3Bv b25lcgo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnN1YnVyYmFuanVuZ2xlLmNvbS8iPlN1 YnVyYmFuIEp1bmdsZQo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnN1cGVyb3NpdHkuY29t LyI+U3VwZXJvc2l0eQo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LndhbmRlcmluZ29uZXMu Y29tLyI+V2FuZGVyaW5nIE9uZXMKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy53ZW5keWNv bWljLmNvbS8iPldlbmR5CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cueW91ZGFtbmtpZC5j b20vIj5Zb3UgRGFtbiBLaWQKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5hc2hmaWVsZG9u bGluZS5jb20vIj4/CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuYWxpY2Vjb21pY3MuY29t LyI+QWxpY2UhCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuYXZhbG9uaGlnaC5jb20vIj5B dmFsb24KPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5ibG9vZGxhcmsuY29tLyI+Qmxvb2Rs YXJrCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuYm94amFtc2Rvb2RsZS5jb20vIj5Cb3hK YW0ncyBEb29kbGUKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5icnVub3RoZWJhbmRpdC5j b20vIj5CcnVubyB0aGUgQmFuZGl0CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuY3JmaC5u ZXQvIj5DUkZIISEhCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuY2hvcHBpbmdibG9jay5v cmcvIj5DaG9wcGluZyBCbG9jawo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LmNsYW5vZnRo ZWNhdHMuY29tLyI+Q2xhbiBvZiB0aGUgQ2F0cwo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3 LnRoZWNsYXNzbS5jb20vIj5DbGFzcyBNZW5hZ2VyaWUKPE9QVElPTiBWQUxVRT0iaHR0cDov L3d3dy5jb29sY2F0c3R1ZGlvLmNvbS8iPkNvb2wgQ2F0IFN0dWRpbwo8T1BUSU9OIFZBTFVF PSJodHRwOi8vd3d3LkVsZkxpZmUuY29tLyI+RWxmIExpZmUKPE9QVElPTiBWQUxVRT0iaHR0 cDovL3d3dy5ldmVyeXRoaW5namFrZS5jb20vIj5FdmVyeXRoaW5nIEpha2UKPE9QVElPTiBW QUxVRT0iaHR0cDovL3d3dy5leHBsb2l0YXRpb25ub3cuY29tLyI+RXhwbG9pdGF0aW9uIE5v dwo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LmZhYW5zLmNvbS8iPkZhbnMKPE9QVElPTiBW QUxVRT0iaHR0cDovL3d3dy5mYXQtamVzdXMuY29tLyI+RmF0IEplc3VzCjxPUFRJT04gVkFM VUU9Imh0dHA6Ly93d3cuZnVubnlmYXJtY29taWNzLmNvbS8iPkZ1bm55IEZhcm0KPE9QVElP TiBWQUxVRT0iaHR0cDovL3d3dy5ncGYtY29taWNzLmNvbS8iPkdQRgo8T1BUSU9OIFZBTFVF PSJodHRwOi8vd3d3LmdlbmVjYXRsb3cuY29tLyI+R2VuZSBDYXRsb3cKPE9QVElPTiBWQUxV RT0iaHR0cDovL3d3dy5ncmV5c3RvbmVpbm4ubmV0LyI+R3JleXN0b25lIElubgo8T1BUSU9O IFZBTFVFPSJodHRwOi8vd3d3LnViZXJzb2Z0Lm5ldC8iPkhlbHAgRGVzawo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3LmhvdW5kc2hvbWUuY29tLyI+SG91bmQncyBIb21lCjxPUFRJT04g VkFMVUU9Imh0dHA6Ly93d3cuaXRzd2Fsa3kuY29tLyI+SXQncyBXYWxreSEKPE9QVElPTiBW QUxVRT0iaHR0cDovL3d3dy5qdXN0YW5vdGhlcnZpY2UuY29tLyI+SnVzdCBBbm90aGVyIFZp Y2UKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5sb3N0YW5kZm91bmRjb21pYy5jb20vIj5M JkYgSW52ZXN0aWdhdGlvbnMKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5sb29rd2hhdGli cm91Z2h0aG9tZS5jb20vIj5MV0lCSCEKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5yYWRj b21pY3MuY29tLyI+TGlmZSdzIFNvIFJhZAo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3Lmxp emFyZGNvbWljcy5jb20vIj5MaXphcmQKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5tZWxv bnBvb2wuY29tLyI+TWVsb25wb29sCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cubWVuaW5o YXRzLmNvbS8iPk1lbiBpbiBIYXRzCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly90cmVhc3VyZWh1 bnRlcnMua2VlbnNwb3QuY29tLyI+TWluaS1TZXJpZXMgRXZlbnQKPE9QVElPTiBWQUxVRT0i aHR0cDovL3d3dy5tcmNodWNrc2hvdy5jb20vIj5Nci4gQ2h1Y2sgU2hvdwo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3Lm5ld3Nob3VuZHMuY29tLyI+TmV3c2hvdW5kcwo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3Lm51a2Vlcy5jb20vIj5OdWtlZXMKPE9QVElPTiBWQUxVRT0iaHR0 cDovL3d3dy5venlhbmRtaWxsaWUub3JnLyI+T3p5IGFuZCBNaWxsaWUKPE9QVElPTiBWQUxV RT0iaHR0cDovL3d3dy5ycGd3b3JsZGNvbWljLmNvbS8iPlJQRyBXb3JsZAo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3LnJlYWxsaWZlY29taWNzLmNvbS8iPlJlYWwgTGlmZQo8T1BUSU9O IFZBTFVFPSJodHRwOi8vd3d3LnBvaXNvbmVkbWluZHMuY29tLyI+Uy5TLkQuRC4KPE9QVElP TiBWQUxVRT0iaHR0cDovL3d3dy5zY2hsb2NrbWVyY2VuYXJ5LmNvbS8iPlNjaGxvY2sgTWVy Y2VuYXJ5CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cubXJiYW5nLm5ldC8iPlNleCBhbmQg VmlvbGVuY2UKCjwvU0VMRUNUPjxOT1NDUklQVD48aW5wdXQgdHlwZT1zdWJtaXQgdmFsdWU9 IkdvISI+PC9OT1NDUklQVD4KICAgICAgICAgICAgICAgIDwvVEQ+CiAgICAgICAgPC9UUj4K PC9GT1JNPgo8L1RBQkxFPgoKCiAgIDwvdGQ+CiA8L3RyPgogPHRyPgogICA8dGQgY29sc3Bh bj01Pjx0YWJsZSBib3JkZXI9MCB3aWR0aD0xMDAlIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNp bmc9MCBiYWNrZ3JvdW5kPSJodHRwOi8vd3d3LmtlZW5zcG90Lm9yZy9oZWFkZXItY29taWNs aW5raW1hZ2VzL2hlYWRlci1saW5lLmdpZiIgaGVpZ2h0PTMgd2lkdGg9MTAwJT48dHI+PHRk PjxpbWcgc3JjPSJodHRwOi8vd3d3LmtlZW5zcG90Lm9yZy9pbWFnZXMvc3BhY2VyLmdpZiIg aGVpZ2h0PTMgd2lkdGg9Mz48L3RkPjwvdHI+PC90YWJsZT48L3RkPgogPC90cj4KPC90YWJs ZT4NCg0KDQoNCjxjZW50ZXI+PHRhYmxlIEJPUkRFUj0wIENFTExTUEFDSU5HPTAgQ0VMTFBB RERJTkc9MCA+DQo8dHI+DQo8dGQgV0lEVEg9IjQ2OCI+DQo8Y2VudGVyPgogPFNDUklQVCBM QU5HVUFHRT0iSkFWQVNDUklQVCI+CiA8IS0tCmlmIChhZGZ2YWxpZCA9PSB0cnVlKSB7CiBk b2N1bWVudC53cml0ZSgiPGEgaHJlZj0nIithZmJhbmxvYysiJz48aW1nIGJvcmRlcj0wIHdp ZHRoPTQ4NiBoZWlnaHQ9NjAgc3JjPSciK3JlcGxhZCsiJz48L2E+Iik7Cn0gZWxzZSB7Cgpp ZiAob3JkIDwgOTgwMDAwKSB7CmRvY3VtZW50LndyaXRlKCc8UycrJ0NSSVBUIFNSQz0iaHR0 cDovL2FkLmtlZW5zcGFjZS5jb20vYWRzZXJ2MTAuanM/c2luZmVzdCI+Jyk7CmRvY3VtZW50 LndyaXRlKCc8XC9TJysnQ1JJUFQ+Jyk7Cn0KCmlmIChvcmQgPj0gOTgwMDAwICYmIG9yZCA8 IDEwMDAwMDApIHsKZG9jdW1lbnQud3JpdGUoJzxTJysnQ1JJUFQgU1JDPSJodHRwOi8vYWQu a2VlbnNwYWNlLmNvbS9hZHNlcnYzMS5qcz9zaW5mZXN0Ij4nKTsKZG9jdW1lbnQud3JpdGUo JzxcL1MnKydDUklQVD4nKTsKfQogIAp9CiAvLy0tPgogPC9TQ1JJUFQ+Cgo8bm9zY3JpcHQ+ PGEgaHJlZj0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vYWRzL2FkODIyM2EtbWFwLmNnaS9u cyIgdGFyZ2V0PSJfdG9wIj48aW1nIHNyYz0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vY2dp LWJpbi9hZHMvYWQ4MjIzYS5jZ2kvbnMiIHdpZHRoPSI0NjgiIGhlaWdodD0iNjAiIGJvcmRl cj0iMCIgYWx0PSJDbGljayBIZXJlIj48L2E+Cjwvbm9zY3JpcHQ+CiAgPC9jZW50ZXI+DQo8 L3RkPg0KPC90cj4NCjwvdGFibGU+PC9jZW50ZXI+DQoNCjxjZW50ZXI+PHRhYmxlIEJPUkRF Uj0wIENFTExTUEFDSU5HPTAgQ0VMTFBBRERJTkc9MCBDT0xTPTcgV0lEVEg9IjQ2OCIgQkdD T0xPUj0iIzkzOENCRiIgPHRhYmxlID4NCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFj ZT0iQXJpYWwgQmxhY2siPjxmb250IHNpemU9LTI+PGEgaHJlZj0iaHR0cDovL3NpbmZlc3Qu bmV0L3N0cmlwc19wYWdlLmh0bSI+c3RyaXBzPC9hPjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+ DQo8L3RkPg0KDQo8dGQgQkdDT0xPUj0iIzZGOTFCNyI+DQo8Y2VudGVyPjxmb250IGZhY2U9 IkFyaWFsIEJsYWNrIj48Zm9udCBzaXplPS0yPjxhIGhyZWY9Imh0dHA6Ly9zaW5mZXN0Lm5l dC9jYXN0Lmh0bSI+Y2FzdDwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkIEJHQ09MT1I9IiNDRUIzRUMiPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJBcmlhbCBCbGFj ayI+PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJodHRwOi8vc2luZmVzdC5uZXQvZ2FsbGVyeV9w YWdlLmh0bSI+Z2FsbGVyeTwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48 YSBocmVmPSJodHRwOi8vc2luZmVzdC5uZXQvbGlua3MuaHRtIj5saW5rczwvYT48L2ZvbnQ+ PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkIEJHQ09MT1I9IiM3QUE3QjQiPg0KPGNl bnRlcj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJo dHRwOi8vZm9ydW1zLmtlZW5zcG90LmNvbS92aWV3Zm9ydW0ucGhwP2ZvcnVtPTI2JjExNjg0 MSI+Zm9ydW08L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZCBCR0NP TE9SPSIjNEU4QUE3Ij4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250 IHNpemU9LTI+PGEgaHJlZj0ibWFpbHRvOm1ycGludEBob3RtYWlsLmNvbSI+ZS1tYWlsPC9h PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250 IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBzaXplPS0yPjxhIGhyZWY9Imh0dHA6Ly93d3cu Y2FmZXByZXNzLmNvbS9zaW5mZXN0Ij5zdG9yZTwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVy Pg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8YnI+Jm5ic3A7DQo8Y2Vu dGVyPjx0YWJsZSBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgV0lEVEg9IjM2MCIgPg0K PHRyPg0KPHRkIEFMSUdOPVJJR0hUIFZBTElHTj1UT1A+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxp bWcgU1JDPSJzbGljay5naWYiIGhlaWdodD0xNDMgd2lkdGg9Nzc+PC9kaXY+DQo8L3RkPg0K DQo8dGQgVkFMSUdOPVRPUCBXSURUSD0iMjc3Ij4NCjxjZW50ZXI+PGltZyBTUkM9InNpbmZl c3RfbG9nby5naWYiIGhlaWdodD04NiB3aWR0aD0yMjc+DQo8YnI+PHU+PGZvbnQgZmFjZT0i Q291cmllciBOZXcsQ291cmllciI+PGZvbnQgY29sb3I9IiNGRkZGQ0MiPlQgQSBUIFMgVQ0K WSBBJm5ic3A7Jm5ic3A7IEkgUyBIIEkgRCBBPC9mb250PjwvZm9udD48L3U+DQo8YnI+PGZv bnQgZmFjZT0iSGFldHRlbnNjaHdlaWxlciI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlByZXNp ZGVudCwgQ0VPLA0KUmV2b2x1dGlvbmFyeTwvZm9udD48L2ZvbnQ+DQo8L2NlbnRlcj4NCjwv dGQ+DQo8L3RyPg0KPC90YWJsZT48L2NlbnRlcj4NCg0KPGJyPiZuYnNwOw0KPGNlbnRlcj48 dGFibGUgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0wIFdJRFRIPSI1NDUiID4NCjx0cj4N Cjx0ZCBBTElHTj1SSUdIVCBWQUxJR049VE9QIFdJRFRIPSIxNzgiPg0KPGNlbnRlcj48Yj48 Zm9udCBjb2xvcj0iI0ZGQ0NGRiI+PGZvbnQgc2l6ZT0rMz5+PC9mb250PjwvZm9udD48L2I+ DQo8YnI+PGI+PGk+PGZvbnQgZmFjZT0iR2FyYW1vbmQiPjxmb250IGNvbG9yPSIjRkZDQ0ZG Ij5JbmNvbmNlaXZhYmxlITwvZm9udD48L2ZvbnQ+PC9pPjwvYj4NCjxicj48Yj48Zm9udCBm YWNlPSJHYXJhbW9uZCI+PGZvbnQgY29sb3I9IiNGRkNDRkYiPjxmb250IHNpemU9KzM+fjwv Zm9udD48L2ZvbnQ+PC9mb250PjwvYj48L2NlbnRlcj4NCg0KPHA+PGJyPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48YSBocmVm PSJodHRwOi8vc2luZmVzdC5uZXQvc3RyaXBzX3BhZ2UuaHRtIj5zdHJpcHMmbmJzcDs8L2E+ PC9mb250PjwvZm9udD48L2Rpdj4NCg0KPGJyPiZuYnNwOw0KPGNlbnRlcj4NCjxwPjxmb250 IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBzaXplPS0yPjxhIGhyZWY9Im1haWx0bzptcnBp bnRAaG90bWFpbC5jb20iPmUtbWFpbCZuYnNwOzwvYT48L2ZvbnQ+PC9mb250PjxhIGhyZWY9 Im1haWx0bzptcnBpbnRAaG90bWFpbC5jb20iPjxpbWcgU1JDPSJkZXZpbF9wdXBwZXRfcGFu ZWwuZ2lmIiBoZWlnaHQ9MTEyIHdpZHRoPTg3IGFsaWduPUNFTlRFUj48L2E+PC9jZW50ZXI+ DQoNCjxwPjxicj4NCjxkaXYgYWxpZ249cmlnaHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5jYWZl cHJlc3MuY29tL3NpbmZlc3QiPjxpbWcgU1JDPSJkZXZpbHN0b3JlLmdpZiIgQk9SREVSPTAg aGVpZ2h0PTE2NyB3aWR0aD0xMDIgYWxpZ249VEVYVFRPUD48L2E+PC9kaXY+DQo8L3RkPg0K DQo8dGQgVkFMSUdOPUNFTlRFUiBXSURUSD0iMTU1Ij48YSBocmVmPSJodHRwOi8vc2luZmVz dC5uZXQvc3RyaXBzX3BhZ2UuaHRtIj48aW1nIFNSQz0iaGFwcHlfZmFkZS5naWYiIEJPUkRF Uj0wIGhlaWdodD0xOTcgd2lkdGg9MTU1IGFsaWduPUFCU0NFTlRFUj48L2E+DQo8cD48Zm9u dCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJodHRwOi8vZm9y dW1zLmtlZW5zcG90LmNvbS92aWV3Zm9ydW0ucGhwP2ZvcnVtPTI2JjExNjg0MSI+Zm9ydW0m bmJzcDs8L2E+PC9mb250PjwvZm9udD48YSBocmVmPSJodHRwOi8vZm9ydW1zLmtlZW5zcG90 LmNvbS92aWV3Zm9ydW0ucGhwP2ZvcnVtPTI2JjExNjg0MSI+PGltZyBTUkM9Im1vbmlxdWUu R0lGIiBCT1JERVI9MCBoZWlnaHQ9MjEyIHdpZHRoPTc3IGFsaWduPVRFWFRUT1A+PC9hPg0K PHA+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IHNpemU9LTI+PGEgaHJlZj0iaHR0 cDovL3d3dy5jYWZlcHJlc3MuY29tL3NpbmZlc3QiPiZuYnNwO3N0b3JlPC9hPjwvZm9udD48 L2ZvbnQ+DQo8cD4mbmJzcDs8L3RkPg0KDQo8dGQgVkFMSUdOPVRPUD4NCjx0YWJsZSBDRUxM UEFERElORz0wIENPTFM9MSBXSURUSD0iMTAwJSIgPg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48 c3ViPjxmb250IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBjb2xvcj0iIzY2MzM2NiI+PGZv bnQgc2l6ZT0tMT5ub3Rlcw0KZnJvbTwvZm9udD48L2ZvbnQ+PC9mb250Pjwvc3ViPjwvY2Vu dGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZCBCR0NPTE9SPSIjNjYzMzY2Ij4NCjxj ZW50ZXI+PGZvbnQgY29sb3I9IiNGRkZGMDAiPjxiPjxzdXA+VEhFPC9zdXA+PC9iPjxpPjxm b250IGZhY2U9IkltcGFjdCI+PGZvbnQgc2l6ZT0rMj5SDQpFIFMgSSBTIFQgQSBOIEMgRSA6 Jm5ic3A7PC9mb250PjwvZm9udD48L2k+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+ DQoNCjx0cj4NCjx0ZD48Zm9udCBjb2xvcj0iI0NDRkZGRiI+DQo8aT5PbiBsaWZlLjwvaT4g QXQgYW55IGdpdmVuIHBvaW50IGluIGxpZmUsIHlvdSdyZSBlaXRoZXIgaW4gdHJhaW5pbmcg DQpvciB5b3UncmUgaW4gdGhlIHRyZW5jaGVzLiBZb3UncmUgZWl0aGVyIGxlYXJuaW5nIHRo ZSByb3BlcyBvciBwYXZpbmcgDQp0aGUgd2F5LiBZb3UncmUgYnVzeSBzZWFyY2hpbmcgb3Ig YnVzeSByZWFsaXppbmcuIEFuZCBtb3N0IG9mIHVzIGFyZQ0KdHJhaW5lZXMsIGJ1c2ggbGVh Z3VlcnMsIFBhZGF3YW4gbGVhcm5lcnMgbm90IHlldCBhbGxvd2VkIHRvIA0Kc2l0IGF0IHRo ZSBKZWRpIHRhYmxlLiBXZSB1c2Uga2lkcHJvb2YgbGlnaHQgc2FiZXJzLiBTaW11bGF0ZSBi YXR0bGVzDQppbiB0aGUgRGFuZ2VyIFJvb20uIFJpZGUgd2l0aCB0cmFpbmluZyB3aGVlbHMu IFByYWN0aWNlLCBwcmFjdGljZSwgDQpwcmFjdGljZS4gQW5kIHdlJ3JlIGFsbCBzbyBpbXBh dGllbnQgdG8gZW5nYWdlIHdpdGggdGhlDQpyZWFsIHdvcmxkLCBlYWdlciB0byBjaGFuZ2Ug dGhpbmdzIGFuZCBtYWtlIGV2ZXJ5dGhpbmcgcGVyZmVjdCBmb3JldmVyLg0KQW5kIGluIG91 ciBoYXN0ZSB3ZSBkZWZ5IG91ciBoaWdoZXItdXBzLCBzZXQgb2ZmIGZvciB0aGUgYmlnIGJh ZCANCndvcmxkLCBhbmQgcm91bmRseSBnZXQgb3VyIGFzc2VzIHdoaXBwZWQuIEFuZCBldmVy eSBvbmUgb2YgdXMsIHNvb25lcg0Kb3IgbGF0ZXIsIGVuZCB1cCBiYWNrIGluIHNjaG9vbC4N CkJ1dCBhaW4ndCBubyBzaGFtZSBpbiB0aGF0LiBUaGF0J3MgdGhlIHdheSBvZiB0aGUgd29y bGQsIHRoZSBjaXJjbGUNCm9mIGxpZmUsIHRoZSBtYXN0ZXIgcGxhbiwgeW91IGRpZz8NCjxi cj4tVC4gDQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IHNpemU9LTI+PGEg aHJlZj0iaHR0cDovL3NpbmZlc3QubmV0L3Jlc2lzdGFuY2UuaHRtIj5tb3JlDQpyZXNpc3Rh bmNlPC9hPjwvZm9udD48L2ZvbnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KPC90ZD4NCjwv dHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8YnI+Jm5ic3A7DQo8Y2VudGVyPjx0YWJsZSBC T1JERVI9MCBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgV0lEVEg9IjU1MCIgQ09MPSIy IiA+DQo8dHI+DQo8dGQ+Jm5ic3A7DQo8ZGl2IEFMSUdOPXJpZ2h0Pjx0YWJsZSBCT1JERVI9 MyBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgV0lEVEg9IjMzMCIgPg0KPHRyPg0KPHRk IEJHQ09MT1I9IiNGRjAwMDAiPg0KPGNlbnRlcj48Yj48dT48Zm9udCBmYWNlPSJBcmlhbCBC bGFjayI+PGZvbnQgY29sb3I9IiNGRkZGMDAiPjxmb250IHNpemU9KzI+RlVUSUxJVFkNCldB VENIPC9mb250PjwvZm9udD48L2ZvbnQ+PC91PjwvYj4NCjxicj48Zm9udCBmYWNlPSJBcmlh bCxIZWx2ZXRpY2EiPjxmb250IGNvbG9yPSIjQ0NGRkZGIj48Zm9udCBzaXplPS0yPlRyYWNr aW5nDQp0aGUgbnVtYmVyIG9mIHRpbWVzIFRhdHN1eWEgZ2V0cyByZWplY3RlZCBieSB0aGUg c3luZGljYXRlcywgdGh1cyByZWFmZmlybWluZw0KaGlzIHN0YXR1cyBhcyBhIHJlbmVnYWRl IGZvbGsgaGVyby4mbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+ DQoNCjx0ZCBXSURUSD0iNzAiIEJHQ09MT1I9IiNGRkZGOTkiPg0KPGNlbnRlcj48Zm9udCBj b2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT0rND4xMTwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+ DQo8L3RkPg0KPC90cj4NCjwvdGFibGU+PC9kaXY+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVy PjxiPjxmb250IGZhY2U9IlZlcmRhbmEiPjxmb250IGNvbG9yPSIjRkZGRjgyIj48Zm9udCBz aXplPS0xPlNpbmZlc3QNCkhvbWUgRGVsaXZlcnk8L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+ DQo8YnI+Cjx0YWJsZT48dHI+PHRkPgo8Zm9ybSBuYW1lPWVtYWlsbGlzdCBhY3Rpb249Imh0 dHA6Ly93d3cua2VlbnNwb3QuY29tL2NnaS1iaW4vc2VuZHN1YmluZm8uY2dpIj4KPGlucHV0 IHR5cGU9aGlkZGVuIG5hbWU9Y29taWNsaXN0IHZhbHVlPXNpbmZlc3QtZGFpbHk+CjxpbnB1 dCBuYW1lPWVtYWlsIHZhbHVlPSJFbnRlciBFLU1haWwhIiBzaXplPTEzPgo8aW5wdXQgdHlw ZT1zdWJtaXQgdmFsdWU9InN1YnNjcmliZSI+CjwvdGQ+PC90cj4KPC9mb3JtPgo8L3RhYmxl PgogICAgPC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCjwvdGFibGU+PC9jZW50ZXI+DQoNCjxi cj4mbmJzcDsNCjxjZW50ZXI+PHRhYmxlIEJPUkRFUj0wIENFTExTUEFDSU5HPTAgQ0VMTFBB RERJTkc9MCBDT0xTPTIgV0lEVEg9IjcyMCIgPg0KPHN1Yj48Zm9udCBzaXplPSsxPjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbixUaW1lcyI+PGZvbnQgY29sb3I9IiM2NkZGRkYiPlRP REFZJ1MNClNUUklQOiZuYnNwOyA8L2ZvbnQ+PC9mb250Pjxmb250IGZhY2U9IkdhcmFtb25k Ij48Zm9udCBjb2xvcj0iI0NDRkZGRiI+VGh1cnNkYXksIFNlcHRlbWJlciA1LCAyMDAyPC9m b250PjwvZm9udD48L2ZvbnQ+PC9zdWI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8Y2VudGVy Pjx0YWJsZSBCT1JERVI9MyBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgQ09MUz0yIFdJ RFRIPSI3MjAiID4NCjx0cj4NCjx0ZCBXSURUSD0iNzAwIiBCR0NPTE9SPSIjRkZGRkZGIj48 Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNjcmlwdCBsYW5ndWFnZT0iSkFWQVNDUklQVCI+Cjwh LS0KdmFyIHdhcnBlbmFibGVkOwp2YXIgd2FycGFsaXZlOwppZiAoYWRmdmFsaWQgPT0gdHJ1 ZSAmJiB3YXJwZW5hYmxlZCA9PSB0cnVlICYmIHdhcnBhbGl2ZSA9PSB0cnVlKSB7CiBkb2N1 bWVudC53cml0ZSgnPElNRyBBTFQ9ImNvbWljIiBCT1JERVI9MCBTUkM9Imh0dHA6Ly9zaW5m ZXN0LndhcnBrZWVuLmNvbS9jb21pY3Mvc2YyMDAyMDkwNS5naWYiIEhFSUdIVD0iMjc2IiBX SURUSD0iNjY1Ij4nKTsKfSBlbHNlIHsKIGRvY3VtZW50LndyaXRlKCc8SU1HIEFMVD0iY29t aWMiIEJPUkRFUj0wIFNSQz0iL2NvbWljcy9zZjIwMDIwOTA1LmdpZiIgSEVJR0hUPSIyNzYi IFdJRFRIPSI2NjUiPicpOwp9Ci8vLS0+Cjwvc2NyaXB0Pgo8bm9zY3JpcHQ+CjxJTUcgQUxU PSJjb21pYyIgQk9SREVSPTAgU1JDPSIvY29taWNzL3NmMjAwMjA5MDUuZ2lmIiBIRUlHSFQ9 IjI3NiIgV0lEVEg9IjY2NSI+Cjwvbm9zY3JpcHQ+CjwvZm9udD4NCjxicj48Zm9udCBmYWNl PSJUYWhvbWEiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPS0yPkNPUFlSSUdI VCZjb3B5OzIwMDINClNJTkZFU1QgUFJPRFVDVElPTlMvQWxsIHJpZ2h0cyByZXNlcnZlZCwg YmFieS48L2ZvbnQ+PC9mb250PjwvZm9udD48L3RkPg0KDQo8dGQgQkdDT0xPUj0iIzAwMDAw MCIgbGluaz0iI0ZGRkZGRiIgdmxpbms9IiNGRkZDQ0MiIGFsaW5rPSIjRkZDQzAwIj4NCjxj ZW50ZXI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxhIGhyZWY9Ii9kLzIwMDAwMTE3Lmh0bWwi PlRoZSBmaXJzdCBjb21pYzwvYT48L2ZvbnQ+DQo8cD48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+ PGEgaHJlZj0iL2QvMjAwMjA5MDQuaHRtbCI+UHJldmlvdXMgY29taWM8L2E+PC9mb250Pjwv Y2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQoNCjxicj48YnI+ DQo8Y2VudGVyPjx0YWJsZSBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgQ09MUz0yIFdJ RFRIPSI1MDAiID4NCjx0cj4NCjx0ZD4NCjxjZW50ZXI+DQo8dGFibGUgYm9yZGVyPSIxIiB3 aWR0aD0iMTc1Ij4KICAgIDx0cj4KICAgICAgICA8dGQgYmdjb2xvcj0iV0hJVEUiPjxwIGFs aWduPSJjZW50ZXIiPjxhCiAgICAgICAgaHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20i Pjxmb250IGNvbG9yPSIjRkZGRkZGIj48c3Ryb25nPjxpbWcKICAgICAgICBzcmM9Imh0dHA6 Ly9rZWVuc3BvdC5jb20vZGF0YS9uZXdzbGlnaHRsb2dvLmdpZiIKICAgICAgICBib3JkZXI9 IjAiIHdpZHRoPSIxNTciIGhlaWdodD0iMjgiPjwvc3Ryb25nPjwvZm9udD48L2E+PC9wPgog ICAgICAgIDwvdGQ+CiAgICA8L3RyPgogICAgPHRyPgogICAgICAgIDx0ZCBiZ2NvbG9yPSIj MDAwMDAwIj48cCBhbGlnbj0iY2VudGVyIj48Zm9udAogICAgICAgIGNvbG9yPSJ3aGl0ZSIg c2l6ZT0iMiIgZmFjZT0iQXJpYWwiPjxzdHJvbmc+UEFSVFknUyBPVkVSLjwvc3Ryb25nPjwv Zm9udD48Zm9udAogICAgICAgIGNvbG9yPSIjRkZDQzAwIiBzaXplPSIxIiBmYWNlPSJBcmlh bCI+PHN0cm9uZz48YnI+CiAgICAgICAgPC9zdHJvbmc+PC9mb250PjxhCiAgICAgICAgaHJl Zj0iaHR0cDovL3d3dy50aGVjbGFzc20uY29tL2QvMjAwMjA4MjYuaHRtbCI+PGltZwogICAg ICAgIHNyYz0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20vZGF0YS9uZXdzLWNsYXNzbWVuYWdl cmllLXNlcDAyLmdpZiIKICAgICAgIGJvcmRlcj0wPjwvYT48YnI+CgoKPGZvbnQKICAgICAg ICBjb2xvcj0id2hpdGUiIHNpemU9IjEiIGZhY2U9IkFyaWFsIj5UaGUgYmVsZWFndWVyZWQg RGVNb250Zm9ydApjYW1wdXMgPC9mb250Pjxmb250CiAgICAgICAgY29sb3I9IndoaXRlIiBz aXplPSIxIiBmYWNlPSJBcmlhbCI+PGEgaHJlZj0iaHR0cDovL3d3dy50aGVjbGFzc20uY29t L2QvMjAwMjA3MTUuaHRtbCI+bXVzaWNhbDwvYT4gaGFzIHN1cnZpdmVkCm1pc2Nhc3Rpbmcs IGluZmlnaHRpbmcsIGFuZCBhIHJpZGljdWxvdXNseSBoaWdoIGNvcHkgYnVkZ2V0LiAgQnV0 IHRoZSBiaWdnZXN0CnRocmVhdCB5ZXQgbm93IHN0cmlrZXMgaW4gYSBkYXJrIGFsbGV5d2F5 LiAgV2lsbCB0aGUgc2hvdyBnbyBvbj88L2ZvbnQ+PC9hPgogICAgICAgIAogICAgICAgIDwv dGQ+CiAgICA8L3RyPgo8L3RhYmxlPjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRl cj48YSBocmVmPSJodHRwOi8vd3d3LnRvcHNpdGVsaXN0cy5jb20vYmVzdHNpdGVzL2NvbWlj c3RyaXAvdG9wc2l0ZXMuY2dpP0lEPTEwMSI+PGltZyBTUkM9InRvcDEwMGNvbWljc3RyaXAu Z2lmIiBCT1JERVI9MCBoZWlnaHQ9MTIyIHdpZHRoPTEwOD48L2E+DQo8cD48YSBocmVmPSJo dHRwOi8vd3d3LmJpZ3BhbmRhLm5ldC8iPjxpbWcgU1JDPSJ0b3AuZ2lmIiBCT1JERVI9MCBo ZWlnaHQ9NjQgd2lkdGg9NjQ+PC9hPg0KPHA+PGEgaHJlZj0iaHR0cDovL3d3dy50aGVmdW5u eXBhcGVycy5jb20vdG9wY2dpL3RvcHNpdGVzLmNnaT9zaW5mZXN0IiBUQVJHRVQ9Il9CTEFO SyI+PGltZyBTUkM9ImZwdm90ZTMuZ2lmIiBCT1JERVI9MCA+PC9hPjwvY2VudGVyPg0KPC90 ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8Y2VudGVyPg0KPHA+PGltZyBTUkM9 InRpbnlfbG9nby5naWYiIGhlaWdodD02NSB3aWR0aD0xMTQ+PC9jZW50ZXI+DQoNCjxjZW50 ZXI+PHRhYmxlIENFTExTUEFDSU5HPTAgQ0VMTFBBRERJTkc9MCBDT0xTPTcgV0lEVEg9IjQw MCIgPg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250IHNp emU9LTE+PGEgaHJlZj0iaHR0cDovL3NpbmZlc3QubmV0L3N0cmlwc19wYWdlLmh0bSI+c3Rh c2g8L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+ PGZvbnQgZmFjZT0iSW1wYWN0Ij48Zm9udCBzaXplPS0xPjxhIGhyZWY9Imh0dHA6Ly9zaW5m ZXN0Lm5ldC9jYXN0Lmh0bSI+Y3JldzwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90 ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250IHNpemU9LTE+ PGEgaHJlZj0iaHR0cDovL3NpbmZlc3QubmV0L2dhbGxlcnlfcGFnZS5odG0iPmphbTwvYT48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBm YWNlPSJJbXBhY3QiPjxmb250IHNpemU9LTE+PGEgaHJlZj0iaHR0cDovL3NpbmZlc3QubmV0 L2xpbmtzLmh0bSI+cGx1ZzwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250IHNpemU9LTE+PGEgaHJl Zj0iaHR0cDovL2ZvcnVtcy5rZWVuc3BvdC5jb20vdmlld2ZvcnVtLnBocD9mb3J1bT0yNiYx MTY4NDEiPnJhdmU8L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4N CjxjZW50ZXI+PGZvbnQgZmFjZT0iSW1wYWN0Ij48Zm9udCBzaXplPS0xPjxhIGhyZWY9Im1h aWx0bzptcnBpbnRAaG90bWFpbC5jb20iPnBvc3RhbDwvYT48L2ZvbnQ+PC9mb250PjwvY2Vu dGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250 IHNpemU9LTE+PGEgaHJlZj0iaHR0cDovL3d3dy5jYWZlcHJlc3MuY29tL3NpbmZlc3QiPnBp bXA8L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT48 L2NlbnRlcj4NCg0KPGNlbnRlcj48Zm9udCBjb2xvcj0iI0ZGQ0MzMyI+PGZvbnQgc2l6ZT0t MT5Db3B5cmlnaHQgJmNvcHk7IDIwMDEgYnkgU2luZmVzdA0KUHJvZHVjdGlvbnMuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuPC9mb250PjwvZm9udD4NCg0KPGNlbnRlcj48dGFibGUgQk9SREVS PTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0wID4NCjx0cj4NCjx0ZCBXSURUSD0iNDY4 Ij4NCjxjZW50ZXI+CjxzY3JpcHQ+CjwhLS0KaWYgKCFhZGZ2YWxpZCkgewpkb2N1bWVudC53 cml0ZSgnPFMnKydDUklQVCBTUkM9Imh0dHA6Ly9hZC5rZWVuc3BhY2UuY29tL2Fkc2VydjEx LmpzP3NpbmZlc3QiPjxcL1MnKydDUklQVD4nKTsKfQovLyAtLT48L3NjcmlwdD4KPG5vc2Ny aXB0Pgo8aWZyYW1lIFNSQz0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vY2dpLWJpbi9hZHMv YmE4MjIzYS5jZ2kvUkVUVVJOLUNPREUvaWYvNDk3NTAwLyIgc2Nyb2xsaW5nPSJubyIgbWFy Z2lud2lkdGg9IjAiIG1hcmdpbgpoZWlnaHQ9IjAiIGZyYW1lYm9yZGVyPSIwIiB2c3BhY2U9 IjAiIGhzcGFjZT0iMCIgd2lkdGg9IjQ2OCIgaGVpZ2h0PSI2MCI+CjxBIHRhcmdldD0iX3Rv cCIgSFJFRj0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vYWRzL2JhODIyM2EtbWFwLmNnaS80 OTc1MDAiPjxJTUcgU1JDPSJodHRwOi8vd3d3LmJ1cnN0bmV0LmNvbS9jZ2ktYmluL2Fkcy9i YTgyMjNhLmNnaS80OTc1MDAiIGJvcmRlcj0iMCIgd2lkdGg9IjQ2OCIgaGVpZ2h0PSI2MCIg YWx0PSJQbGVhc2Ugc3VwcG9ydCBvdXIgc3BvbnNvci4iPgo8L2E+PC9pZnJhbWU+Cjwvbm9z Y3JpcHQ+CjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxmb250IHNpemU9LTE+U0lORkVTVCBpcyBo b3N0ZWQgYnkgPGEgaHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20iPktFRU5TUE9UPC9h Pi4NCjxhIGhyZWY9Imh0dHA6Ly93d3cua2VlbnNwb3QuY29tL3ByaXZhY3kuaHRtbCI+UHJp dmFjeQ0KUG9saWN5PC9hPjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQoNCjxicj48Y2VudGVy Pg0KPGEgdGFyZ2V0PSJfdG9wIiBocmVmPSJodHRwOi8veS5leHRyZW1lLWRtLmNvbS9zLz90 YWc9bXVzZXBpbXAiPg0KPGltZyBuYW1lPWltIHNyYz0iaHR0cDovL3kwLmV4dHJlbWUtZG0u Y29tL2kvIiBoZWlnaHQ9MzggYm9yZGVyPTANCndpZHRoPTQxIGFsdD0iIj48L2E+PHNjcmlw dCBsYW5ndWFnZT0iamF2YXNjcmlwdCI+PCEtLQ0KYW49bmF2aWdhdG9yLmFwcE5hbWU7ZD1k b2N1bWVudDtmdW5jdGlvbg0KcHIoKXtkLndyaXRlKCI8aW1nIHNyYz1cImh0dHA6Ly95MS5l eHRyZW1lLWRtLmNvbSIsDQoiL3ovP3RhZz1tdXNlcGltcCZqPXkmc3J3PSIrc3J3KyImc3Ji PSIrc3JiKyImIiwNCiJycz0iK3IrIiZsPSIrZXNjYXBlKGQucmVmZXJyZXIpKyJcIiBoZWln aHQ9MSAiLA0KIndpZHRoPTE+Iik7fXNyYj0ibmEiO3Nydz0ibmEiOy8vLS0+DQo8L3Njcmlw dD48c2NyaXB0IGxhbmd1YWdlPSJqYXZhc2NyaXB0MS4yIj48IS0tDQpzPXNjcmVlbjtzcnc9 cy53aWR0aDthbiE9Ik5ldHNjYXBlIj8NCnNyYj1zLmNvbG9yRGVwdGg6c3JiPXMucGl4ZWxE ZXB0aDsvLy0tPg0KPC9zY3JpcHQ+PHNjcmlwdCBsYW5ndWFnZT0iamF2YXNjcmlwdCI+PCEt LQ0Kcj00MTtkLmltYWdlcz9yPWQuaW0ud2lkdGg6ej0wO3ByKCk7Ly8tLT4NCjwvc2NyaXB0 Pjxub3NjcmlwdD48aW1nIGhlaWdodD0xIHdpZHRoPTEgYWx0PSIiIA0Kc3JjPSJodHRwOi8v eTEuZXh0cmVtZS1kbS5jb20vei8/dGFnPW11c2VwaW1wJmo9biI+PC9ub3NjcmlwdD4NCjwv Y2VudGVyPg0KDQo8L2JvZHk+DQo8L2h0bWw+DQ=9 --Bq50vA3GEMK-- From owner-linux-xfs@oss.sgi.com Thu Sep 5 11:52:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 11:52:54 -0700 (PDT) Received: from mailrtr1.mailzone.edeltacom.com (IDENT:mirapoint@mailrtr1.mailzone.edeltacom.com [216.248.176.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85IqntG029069 for ; Thu, 5 Sep 2002 11:52:50 -0700 Received: (from Administrator@localhost) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) id ACQ88044; Thu, 5 Sep 2002 14:56:56 -0400 (EDT) Date: Thu, 5 Sep 2002 14:56:56 -0400 (EDT) From: Message-Id: <200209051856.ACQ88044@mailrtr1.mailzone.edeltacom.com> To: linux-xfs@oss.sgi.com Subject: Virus Alert X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Administrator@mailrtr1.mailzone.edeltacom.com Precedence: bulk X-list: linux-xfs The WORM_KLEZ.H virus was detected in email from nmcminn@charter.net (09/05/2002 14:56:56). The attachment (alt.pif) was deleted. From owner-linux-xfs@oss.sgi.com Thu Sep 5 12:49:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 12:49:51 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85JnntG031525 for ; Thu, 5 Sep 2002 12:49:49 -0700 Received: from dialup-63.214.86.178.dial1.boston1.level3.net ([63.214.86.178] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17n2hQ-0006gx-00 by VAauthid with fixed_plain for ; Thu, 05 Sep 2002 12:53:57 -0700 Message-ID: <3D77B641.1020407@osdn.com> Date: Thu, 05 Sep 2002 15:53:37 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] return() cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs Patch 4 for the latest 2.4 cvs http://www.axehind.com/xfs/xfs-cleanup-4-linux-2.4.patch changes return(i); - > return i; in fs/xfs/dmapi Brian From owner-linux-xfs@oss.sgi.com Thu Sep 5 15:38:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 15:38:20 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85McEtG002996 for ; Thu, 5 Sep 2002 15:38:15 -0700 Received: from dialup-63.214.75.234.dial1.boston1.level3.net ([63.214.75.234] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17n5KL-00079A-00 by VAauthid with fixed_plain for ; Thu, 05 Sep 2002 15:42:17 -0700 Message-ID: <3D77DD83.5050206@osdn.com> Date: Thu, 05 Sep 2002 18:41:07 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] last 2.4 return() cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs This is the last patch against the 2.4 cvs making return(i); - > return i; http://www.axehind.com/xfs/xfs-cleanup-5-linux-2.4.patch Since no one has told me I'm wasting my time yet, I'll start on 2.5 now. Brian From owner-linux-xfs@oss.sgi.com Thu Sep 5 15:55:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 15:56:02 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85MtttG003889 for ; Thu, 5 Sep 2002 15:55:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA29927; Thu, 5 Sep 2002 17:59:58 -0500 (CDT) Received: from [192.168.1.101] (IDENT:qV/unN4YeuRVq9ubgy7fyJBM6WHhO4P6@cf-vpn-sw-corp-64-52.corp.sgi.com [134.15.64.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA63965; Thu, 5 Sep 2002 17:59:57 -0500 (CDT) Subject: Re: [PATCH] last 2.4 return() cleanup From: Stephen Lord To: Brian Pontz Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D77DD83.5050206@osdn.com> References: <3D77DD83.5050206@osdn.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 05 Sep 2002 18:01:39 -0500 Message-Id: <1031266902.1240.0.camel@snafu> Mime-Version: 1.0 X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-05 at 17:41, Brian Pontz wrote: > This is the last patch against the 2.4 cvs > making return(i); - > return i; > > http://www.axehind.com/xfs/xfs-cleanup-5-linux-2.4.patch > > Since no one has told me I'm wasting my time yet, I'll start on 2.5 now. > > Brian There should be no need to do 2.5, we can merge the 2.4 changes into 2.5 when we integrate them. Thanks for the cleanup. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 5 20:13:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 20:13:41 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g863DZtG007880 for ; Thu, 5 Sep 2002 20:13:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 UAA07995 for ; Thu, 5 Sep 2002 20:17:41 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA25509; Fri, 6 Sep 2002 13:16:13 +1000 (EST) Date: Fri, 6 Sep 2002 13:16:13 +1000 (EST) From: Nathan Scott Message-Id: <200209060316.NAA25509@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - attr/acl X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 5 20:15:41 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126816a cmd/acl/doc/CHANGES - 1.42 cmd/attr/doc/CHANGES - 1.28 cmd/attr/libattr/syscalls.c - 1.15 cmd/acl/setfacl/setfacl.c - 1.4 cmd/acl/setfacl/do_set.c - 1.8 cmd/acl/po/de.po - 1.3 cmd/acl/po/acl.pot - 1.3 - updates from Andreas. From owner-linux-xfs@oss.sgi.com Thu Sep 5 23:27:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 23:27:56 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g866RntG014588 for ; Thu, 5 Sep 2002 23:27:49 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g866VvQ4064991; Fri, 6 Sep 2002 08:31:57 +0200 (CEST) Message-Id: <4.3.2.7.2.20020906083021.02ca1da8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Sep 2002 08:30:46 +0200 To: James Rich , XFS mailing list From: Seth Mos Subject: Re: update summary page In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:01 5-9-2002 -0600, James Rich wrote: >I've updated the CVS summary for August 27 - September 5. Quite a bit of >work has been done during that period. If people feel there are some >significant issues or important checkins that should be listed in the >"Significant issues" section please let me know. Great I'll add a link from the FAQ to it. Thanks! -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 6 02:11:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 02:11:08 -0700 (PDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g869B1tG021236 for ; Fri, 6 Sep 2002 02:11:01 -0700 Received: (qmail 546 invoked from network); 6 Sep 2002 09:15:09 -0000 Received: from unknown (HELO mountainviewdata.com) (210.72.245.13) by relay1.pair.com with SMTP; 6 Sep 2002 09:15:09 -0000 X-pair-Authenticated: 210.72.245.13 Message-ID: <3D7944C7.6020309@mountainviewdata.com> Date: Fri, 06 Sep 2002 17:13:59 -0700 From: tom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: a deadlock problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: twang@mountainviewdata.com Precedence: bulk X-list: linux-xfs Hi XFS developers, When studying xfs code(2.4.19), I found that the inode will be locked by XFS_ILOCK_SHARE flags before we get acl, which may cause deadlock. Because when getting acl, it will allocate memory in KM_SLEEP, If the memory is tight, the process will call xfs_strategy, and may lock(XFS_ILOCK_SHARE)the same inode again. If between these two locks, another process try to lock the inode by XFS_ILOCK_EXCL, these two processes will be deadlock. As follows, A process get ea B process want lock ipA 1) xfs_ilock(ipA, XFS_ILOCK_SHARE) ..................... | | | | get acl 2) xfs_ilock(ipA, XFS_ILOCK_EXCL) | | | | memory tight | | xfs_stragegy | | 3)xfs_ilock(ipA, XFS_ILOCK_SHARE) ............................ these two processes will be dead lock. So I believe that acl allocation GFP_MASKshould be changed to KM_NOFS. right? best regards wdd From owner-linux-xfs@oss.sgi.com Fri Sep 6 04:29:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 04:30:14 -0700 (PDT) Received: from mail.blazebox.homeip.net (postfix@pool-141-155-135-124.ny5030.east.verizon.net [141.155.135.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g86BTvtG025301 for ; Fri, 6 Sep 2002 04:29:58 -0700 Received: from blaze.homeip.net (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 2F9A99E2F for ; Fri, 6 Sep 2002 07:34:21 -0400 (EDT) Subject: XFS patch for kernel 2.4.20-pre5. From: Paul Blazejowski To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-a7YMRB0N+v4sk+C1dcX/" X-Mailer: Ximian Evolution 1.0.8 Date: 06 Sep 2002 07:34:21 -0400 Message-Id: <1031312061.3104.16.camel@blaze> Mime-Version: 1.0 X-archive-position: 290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs --=-a7YMRB0N+v4sk+C1dcX/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello folks, If i can recall someone on the list was asking for patches against latest -preXX of 2.4 kernel...i have created a cvs patch for my own use/testing/fun :D. The patch is from cvs tree as of 9-6-02 and should be applied to kernel 2.4.20-pre5 from kernel.org, it comes in bzip2 format. http://www.blazebox.homeip.net:81/~paul/linux=20 Regards, Paul B. --=-a7YMRB0N+v4sk+C1dcX/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9eJK9IymMQsXoRDARAunLAKCQ/V9Oq5MzHEHDEsQp1d8agqNGUQCfZb2O /+2LLRk9/u4auPjtYsgBXFk= =h9pb -----END PGP SIGNATURE----- --=-a7YMRB0N+v4sk+C1dcX/-- From owner-linux-xfs@oss.sgi.com Fri Sep 6 10:26:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 10:26:33 -0700 (PDT) Received: from endeavour.uwyo.edu (endeavour.uwyo.edu [129.72.10.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g86HQUtG002181 for ; Fri, 6 Sep 2002 10:26:31 -0700 Received: from CONVERSION-DAEMON.endeavour.uwyo.edu by endeavour.uwyo.edu (PMDF V6.1-1 #40460) id <0H21006011Z652@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Fri, 06 Sep 2002 11:30:42 -0600 (MDT) Received: from asuwlink.uwyo.edu (asuwlink.uwyo.edu [129.72.60.2]) by endeavour.uwyo.edu (PMDF V6.1-1 #40460) with ESMTP id <0H21003DF1Z60L@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Fri, 06 Sep 2002 11:30:42 -0600 (MDT) Received: from localhost (fletcher@localhost) by asuwlink.uwyo.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA10193 for ; Fri, 06 Sep 2002 11:30:41 -0600 (MDT) Date: Fri, 06 Sep 2002 11:30:41 -0600 (MDT) From: Walter R Fletcher Subject: Re: XFS bad block recording? To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: asuwlink.uwyo.edu: fletcher owned process doing -bs X-archive-position: 291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fletcher@uwyo.edu Precedence: bulk X-list: linux-xfs People, I must have missed something. Disk drives have had for some years the logic to detect and remap detected bad sectors on the fly. Some drives did this silently while others have had additional functionality to report a developing problem. At any rate, the disks have already dealt with the problem (reported or not), so remapping a sector (that is already remapped) makes not one whit of sense. As has already been said, if the disk has run out of spare sectors, the disk is in serious trouble already and probably scraping itself out of existence. Given this, why insert code into a filesystem to deal with errors that are already remedied? Perhaps the device driver might stimulate an alarm or at least an entry in the syslog so the admin would be aware of a developing failure. That is not a filesystem's task. What should the filesystem do? Handle errors from a device that doesn't remap? How much responsibility does the filesystem have with regard to hardware reliability? -- Reid Walter Reid Fletcher, WB7CJO Department of Geology and Geophysics P. O. Box 3006 University of Wyoming 1-307-766-6227 Laramie, WY 82071 Internet: Fletcher @ UWyo.Edu Are we all roadkill on the information highway? - Jeff Greenfield From owner-linux-xfs@oss.sgi.com Fri Sep 6 14:44:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 14:44:54 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g86LiltG018973 for ; Fri, 6 Sep 2002 14:44:47 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id <3M5Q1PKT>; Fri, 6 Sep 2002 14:48:52 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F1F8@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-xfs@oss.sgi.com '" Subject: Oops in init on 9/5/02 XFS cvs code Date: Fri, 6 Sep 2002 14:48:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C255EF.30234E00" X-archive-position: 292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dale.stephenson@quantum.com Precedence: bulk X-list: linux-xfs 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_01C255EF.30234E00 Content-Type: text/plain Here's the situation -- kdb build using XFS cvs tree from 9/5/02. 11 drive RAID5 with spare setup, created an lvm volume on the RAID. Failed a drive in the RAID5 during the sync, then created an xfs filesystem on the volume. When mounting the volume, the init processes oopses. In kdb I found the oops was inside kmem_cache_alloc(). Somehow, the slabs_free structure inside of names_cache's kmem_cache_t had become corrupted. The other list heads in the structure seemed fine. Any idea what could possibly cause this? Attached is the back trace of init, of the mount, of the raid5 recovery daemon, dissasembly of the relevant part of kmem_cache_alloc, and the kmem_cache_t structure. Dale Stephenson steph@snapserver.com ------_=_NextPart_000_01C255EF.30234E00 Content-Type: application/octet-stream; name="oops.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="oops.txt" oops into kdb, in process 1 (init). Failed raid5 during sync, then created an xfs filesystem on a logical volume on the raid5. Possibly relevant info: kdb> bt EBP EIP Function (args) 0xc1c17f58 0xc012acd3 kmem_cache_alloc+0x53 (0xc1c0fea0, 0x1f0, 0xc1c16000,= 0xc1c17fa0, 0xc1c17fa0) kernel .text 0xc0100000 0xc012ac80 0xc012ad44 0xc1c17f74 0xc013b3db getname+0x1b (0x804dcef, 0xc1c16000, 0xc1c17fa0, 0x80= 4dea7, 0x9) kernel .text 0xc0100000 0xc013b3c0 0xc013b464 0xc1c17f90 0xc013c464 __user_walk+0x14 (0xc1c16000, 0xbffffa70, 0xc0346000,= 0xc1c16000, 0xef164080) kernel .text 0xc0100000 0xc013c450 0xc013c4a8 0xc1c17fbc 0xc0139402 sys_stat64+0x1a (0x804dcef, 0xbffff6a0, 0x80500c8, 0x= bffffa70, 0x804dea7) kernel .text 0xc0100000 0xc01393e8 0xc013945c 0xc0108c6b system_call+0x33 kernel .text 0xc0100000 0xc0108c38 0xc0108c70 kdb> id kmem_cache_alloc+0x35 0xc012acb5 kmem_cache_alloc+0x35: pushf 0xc012acb6 kmem_cache_alloc+0x36: popl 0xfffffffc(%ebp) 0xc012acb9 kmem_cache_alloc+0x39: cli 0xc012acba kmem_cache_alloc+0x3a: lea 0x8(%esi),%ebx 0xc012acbd kmem_cache_alloc+0x3d: mov 0x8(%esi),%ecx 0xc012acc0 kmem_cache_alloc+0x40: cmp %ebx,%ecx 0xc012acc2 kmem_cache_alloc+0x42: jne 0xc012ace6 kmem_cache_alloc+0x66 0xc012acc4 kmem_cache_alloc+0x44: lea 0x10(%esi),%eax 0xc012acc7 kmem_cache_alloc+0x47: mov 0x10(%esi),%ecx 0xc012acca kmem_cache_alloc+0x4a: cmp %eax,%ecx 0xc012accc kmem_cache_alloc+0x4c: je 0xc012ad20 kmem_cache_alloc+0xa0 0xc012acce kmem_cache_alloc+0x4e: mov 0x4(%ecx),%eax 0xc012acd1 kmem_cache_alloc+0x51: mov (%ecx),%edx 0xc012acd3 kmem_cache_alloc+0x53: mov %eax,0x4(%edx) 0xc012acd6 kmem_cache_alloc+0x56: mov %edx,(%eax) 0xc012acd8 kmem_cache_alloc+0x58: mov 0x8(%esi),%eax kdb> rd eax =3D 0x00000000 ebx =3D 0xc1c0fea8 ecx =3D 0xcfa45500 edx =3D 0x00000400 esi =3D 0xc1c0fea0 edi =3D 0x000001f0 esp =3D 0xc1c17f48 eip =3D 0xc012acd3 ebp =3D 0xc1c17f58 xss =3D 0x00000018 xcs =3D 0x00000010 eflags =3D 0x00010= 006 xds =3D 0x00000018 xes =3D 0x00000018 origeax =3D 0xffffffff ®s =3D 0xc1= c17f14 kdb> md 0xc1c0fea0 0xc1c0fea0 efe0fee0 efe0f780 c1c0fea8 c1c0fea8 0xc1c0feb0 cfa45500 cfa45500 00001000 00012000 0xc1c0fec0 00000001 00000000 00000000 00000000 ................ 0xc1c0fed0 00000000 00000020 00000000 c1c0f0a0 .... .......=20 0xc1c0fee0 00000000 00000001 00000000 00000000 ................ 0xc1c0fef0 00000000 656d616e 61635f73 00656863 ....names_cache. 0xc1c0ff00 00000000 00000000 c1c0fe98 c1c0ff78 ..........@..@. 0xc1c0ff10 eddd4040 efded000 ee164000 ee164000 @@ kdb> md 0xcfa45500 0xcfa45500 00000400 00000000 00000000 00000000 ................ kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc1c16000 00000001 00000000 1 000 run 0xc1c16270*init 0xefe06000 00000009 00000001 1 000 run 0xefe06270 mdrecoveryd 0xeeb02000 00002900 00002868 1 000 stop 0xeeb02270 mount kdb> btp 2900 EBP EIP Function (args) 0xeeb03ae8 0xc0113ad3 schedule+0x363 (0xcfdfb300, 0xcfdfb300, 0xecfeec00, 0= xcfdfb360, 0xeeb03b04) kernel .text 0xc0100000 0xc0113770 0xc0113af8 0xeeb03b14 0xc0107a8d __down+0x61 (0xcfdfb358, 0x3, 0x0) kernel .text 0xc0100000 0xc0107a2c 0xc0107ad8 0xeeb03b28 0xc0107bfb __down_failed+0xb (0x1, 0xeeb03b4c, 0xc01d5ac4, 0xcfd= fb300, 0x20000) kernel .text 0xc0100000 0xc0107bf0 0xc0107c04 0xc01d85f7 .text.lock.page_buf+0x23 kernel .text 0xc0100000 0xc01d85d4 0xc01d8600 0xeeb03b34 0xc01d79f1 pagebuf_iowait+0x29 (0xcfdfb300, 0x20000, 0xcfdfb300,= 0xcfd143a0) kernel .text 0xc0100000 0xc01d79c8 0xc01d79fc 0xeeb03b4c 0xc01d5ac4 xfs_bwrite+0x6c (0xecfeec00, 0xcfdfb300, 0xcfdfb300, = 0xcfdfb300, 0x100) kernel .text 0xc0100000 0xc01d5a58 0xc01d5b3c 0xeeb03b78 0xc01c1bfc xlog_bwrite+0x60 (0xcfd143a0, 0x2, 0x100, 0xcfdfb300,= 0x200) kernel .text 0xc0100000 0xc01c1b9c 0xc01c1c28 0xeeb03bd0 0xc01c2cc3 xlog_write_log_records+0x163 (0xcfd143a0, 0x0, 0x2, 0= x200, 0x1) kernel .text 0xc0100000 0xc01c2b60 0xc01c2d00 0xeeb03c04 0xc01c2de1 xlog_clear_stale_blocks+0xe1 (0xcfd143a0, 0x0, 0x1, 0= xcfd143a0, 0xeeb03c74) kernel .text 0xc0100000 0xc01c2d00 0xc01c2df4 0xeeb03c50 0xc01c290f xlog_find_tail+0x357 (0xcfd143a0, 0xeeb03c74, 0xeeb03= c7c, 0x0, 0xcfd143a0) kernel .text 0xc0100000 0xc01c25b8 0xc01c2940 0xeeb03c84 0xc01c58e2 xlog_recover+0x1e (0xcfd143a0, 0x0, 0x3, 0x14) more> kernel .text 0xc0100000 0xc01c58c4 0xc01c5980 0xeeb03c9c 0xc01bef75 xfs_log_mount+0x71 (0xecfeec00, 0x3a00, 0xc800080, 0x= 0, 0x40000) kernel .text 0xc0100000 0xc01bef04 0xc01befa8 0xeeb03db0 0xc01c7166 xfs_mountfs+0xab2 (0xcfa453e0, 0xecfeec00, 0x3a00, 0x= 0, 0xcf13e800) kernel .text 0xc0100000 0xc01c66b4 0xc01c7670 0xeeb03dec 0xc01ce5e2 xfs_cmountfs+0x52e (0xcfa453e0, 0x3a00, 0x3a00, 0x0, = 0xcf13e800) kernel .text 0xc0100000 0xc01ce0b4 0xc01ce678 0xeeb03e1c 0xc01ce6bd xfs_mount+0x45 (0xcfa453e0, 0xcf13e800, 0x0, 0x3a00, = 0x200) kernel .text 0xc0100000 0xc01ce678 0xc01ce6c8 0xeeb03e98 0xc01e05cf linvfs_read_super+0xff (0xecfee800, 0xcf85d000, 0x0, = 0xfffffff4, 0xc1c1f3a0) kernel .text 0xc0100000 0xc01e04d0 0xc01e0740 0xeeb03ee4 0xc013785a get_sb_bdev+0x20e (0xc033836c, 0x0, 0xed2bf000, 0xcf8= 5d000, 0xedc53000) kernel .text 0xc0100000 0xc013764c 0xc01378b8 0xeeb03f08 0xc0137a12 do_kern_mount+0x56 (0xedc53000, 0x0, 0xed2bf000, 0xcf= 85d000, 0x0) kernel .text 0xc0100000 0xc01379bc 0xc0137abc 0xeeb03f3c 0xc0147e89 do_add_mount+0x6d (0xeeb03f70, 0xedc53000, 0x0, 0x0, = 0xed2bf000) kernel .text 0xc0100000 0xc0147e1c 0xc0147f6c 0xeeb03f8c 0xc014814c do_mount+0x138 (0xed2bf000, 0xefe00000, 0xedc53000, 0= xc0ed0000, 0xcf85d000) kernel .text 0xc0100000 0xc0148014 0xc0148168 0xeeb03fbc 0xc01484d0 sys_mount+0x7c (0x8059aa8, 0x8059ac0, 0x8059ad8, 0xc0= ed0000, 0x8059b48) kernel .text 0xc0100000 0xc0148454 0xc0148510 0xc0108c6b system_call+0x33 kernel .text 0xc0100000 0xc0108c38 0xc0108c70 more> kdb> btp 9 EBP EIP Function (args) 0xefe07e08 0xc0113ad3 schedule+0x363 (0xcfb03800, 0x161458, 0x5, 0x1, 0x1) kernel .text 0xc0100000 0xc0113770 0xc0113af8 0xefe07e58 0xc022bc45 get_active_stripe+0xa1 (0xcfb03800, 0x161458, 0x0, 0x= 0, 0x1) kernel .text 0xc0100000 0xc022bba4 0xc022c054 0xefe07ea4 0xc022df82 raid5_sync_request+0x42 (0xcfd142a0, 0x161458, 0xcfd1= 42a0, 0xecd19000, 0xefe07fa4) kernel .text 0xc0100000 0xc022df40 0xc022e000 0xefe07f7c 0xc0236636 md_do_sync+0x21a (0xcfd142a0, 0xecd19780, 0xefe06000,= 0xefe0d220, 0xefe06000) kernel .text 0xc0100000 0xc023641c 0xc0236900 0xefe07fa8 0xc02369f6 md_do_recovery+0xf6 (0x0, 0x100, 0xc1c17ecc, 0x0, 0xe= fe0d228) kernel .text 0xc0100000 0xc0236900 0xc0236b38 0xefe07fec 0xc0235932 md_thread+0xfe kernel .text 0xc0100000 0xc0235834 0xc0235980 0xc0107543 kernel_thread+0x23 kernel .text 0xc0100000 0xc0107520 0xc0107558 ------_=_NextPart_000_01C255EF.30234E00-- From owner-linux-xfs@oss.sgi.com Fri Sep 6 18:16:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 18:16:38 -0700 (PDT) Received: from nm.ru (node13ae8.a2000.nl [24.132.58.232]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g871FwtG024090 for ; Fri, 6 Sep 2002 18:16:05 -0700 Message-ID: <000e01c255fd$2756ec10$0100a8c0@slashx> From: "Julia" To: linux-xfs@oss.sgi.com Subject: Hi! Weisste noch wer ich bin ? Date: Sat, 7 Sep 2002 01:28:49 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 418 X-archive-position: 293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andream@yajoo.de Precedence: bulk X-list: linux-xfs Hallo !=20 Ganz schon viel Zeit vergangen seitdem ich dich das letzte Mal gesehen habe= , aber wie du siehst , vergessen habe ich dich nicht ;). Bin jetzt aus dem Urlaub zur=FCck, braun gebrant und happy . Wie ich jetzt = aussehe kannste dir auf meiner neuen Homepage ansehen : http://www.julia.5x= x.net , hoffe dir f=E4llt auch dann ein wer ich bin ;). Naja, bis dann mal ! [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Sep 6 19:32:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 19:32:30 -0700 (PDT) Received: from mail.miratek.com ([216.97.55.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g872WNtG025098 for ; Fri, 6 Sep 2002 19:32:24 -0700 Received: from maherxp [24.145.147.99] by mail.miratek.com with ESMTP (SMTPD32-7.12) id A4D33D1024A; Fri, 06 Sep 2002 21:30:43 -0500 Reply-To: From: "Mike" To: Subject: mkfs.xfs tune performance options (sunit and swidth) Date: Fri, 6 Sep 2002 22:35:46 -0400 Message-ID: <000001c25617$45e86590$967ba8c0@maherxp> 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, Build 10.0.3416 Importance: Normal In-Reply-To: <1031266902.1240.0.camel@snafu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: samba@miratek.com Precedence: bulk X-list: linux-xfs We are creating a single large filesystem 7x72GB using SCSI 10k disks. The system is 2x2.4 GHz and 4GB RAM. The application which will be accessing those drives creates large files and gets accessed sequentially (not database) with multi reads and writes. I configured the 7 disks using RAID0 (/etc/raidtab below) and created xfs filesystem: raiddev /dev/md7 raid-level 0 nr-raid-disks 7 chunk-size 256k persistent-superblock 1 nr-spare-disks 0 device /dev/sdd1 raid-disk 0 device /dev/sde1 raid-disk 1 device /dev/sdf1 raid-disk 2 device /dev/sdg1 raid-disk 3 device /dev/sdh1 raid-disk 4 device /dev/sdi1 raid-disk 5 device /dev/sdj1 raid-disk 6 #mkfs -t xfs -V -f -l internal,size=32768b -b size=4k /dev/md7 # xfs_info /data2 meta-data=/data2 isize=256 agcount=119, agsize=1048576 blks data = bsize=4096 blocks=124473216, imaxpct=25 = sunit=64 swidth=448 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768 realtime =none extsz=1835008 blocks=0, rtextents=0 My question is how can I tune this to perform better for large file reads and writes. The RAID Chunk size is 256K. Shall I make it larger? What should I use for sunit, swidth, su, or sw. sunit and swidth are confusiong, how those values relate to stride option on ext2/3? Any other considerations? Thanks, Mike From owner-linux-xfs@oss.sgi.com Fri Sep 6 19:35:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 19:35:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g872Z2tG025568 for ; Fri, 6 Sep 2002 19:35:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA39921 for ; Fri, 6 Sep 2002 21:39:10 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id VAA30739 for ; Fri, 6 Sep 2002 21:39:10 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g872ZhP25081; Fri, 6 Sep 2002 21:35:43 -0500 Message-Id: <200209070235.g872ZhP25081@stout.americas.sgi.com> Date: Fri, 6 Sep 2002 21:35:43 -0500 Subject: TAKE - Backport kmem_cache_size from 2.5 X-archive-position: 295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs From Christoph: "Backport kmem_cache_size from 2.5 (already in 2.4.20-pre) and use it to implement kmem_zone_zalloc. Remove kmem_cache_zalloc." This will reduce our footprint in 2.4.20. Backport kmem_cache_size from 2.5 Date: Fri Sep 6 19:38:01 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126898a linux/mm/slab.c - 1.31 linux/kernel/ksyms.c - 1.135 linux/include/linux/slab.h - 1.22 linux/fs/xfs/support/kmem.c - 1.22 From owner-linux-xfs@oss.sgi.com Sat Sep 7 01:45:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 01:45:14 -0700 (PDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g878j9tG029530 for ; Sat, 7 Sep 2002 01:45:09 -0700 Received: (qmail 41573 invoked from network); 7 Sep 2002 08:49:20 -0000 Received: from unknown (HELO mountainviewdata.com) (210.72.245.13) by relay1.pair.com with SMTP; 7 Sep 2002 08:49:20 -0000 X-pair-Authenticated: 210.72.245.13 Message-ID: <3D79BCE4.9050703@mountainviewdata.com> Date: Sat, 07 Sep 2002 16:46:28 +0800 From: Eric Mei User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: xfs-list Subject: hardlink overflow Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ericm@mountainviewdata.com Precedence: bulk X-list: linux-xfs Hi, recently I noticed XFS's strange behaviour on hardlink. i_nlink is defined as "unsigned short" in kernel, although xfs_dinode_core defined it as "unint32". it seems linux-XFS didn't check it's overflow. simply add 65536 hardlink to a file will make their nlink to 0. I'm using latest 2.4.19 CVS version. Best Wishs Eric From owner-linux-xfs@oss.sgi.com Sat Sep 7 03:09:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 03:09:57 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87A9ptG031577 for ; Sat, 7 Sep 2002 03:09:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 DAA05203 for ; Sat, 7 Sep 2002 03:14:03 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA88744 for linux-xfs@oss.sgi.com; Sat, 7 Sep 2002 20:12:44 +1000 (EST) Date: Sat, 7 Sep 2002 20:12:44 +1000 (EST) From: Nathan Scott Message-Id: <200209071012.UAA88744@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - v2 log X-archive-position: 297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Sat Sep 7 03:11:28 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126903a linux/fs/xfs/xfs_log_recover.c - 1.242 - Fixed a typo bug (& != &&) in the v2 log recovery code - found by inspection, not sure it caused any problems in the wild. tidied some code around it to be max 80chars wide. From owner-linux-xfs@oss.sgi.com Sat Sep 7 06:25:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 06:25:29 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87DPLtG002841 for ; Sat, 7 Sep 2002 06:25:22 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id XAA07383; Sat, 7 Sep 2002 23:22:18 +0930 Message-ID: <3D7A020D.E3C1C512@rebel.net.au> Date: Sat, 07 Sep 2002 23:11:33 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Walter R Fletcher CC: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Hmmm... > of a developing failure. That is not a filesystem's task. What should > the filesystem do? Be aware of possible errors reported by lower level handlers (in this case the device driver for the hard disk) and deal with them in a configurable, sensible and logical manner. > How much responsibility does the filesystem have with regard to hardware > reliability? None, but if it is possible it should use as much of the information available to it, eg errors logged by lower device handlers, in the decisions it makes. :-) DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 06:46:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 06:46:39 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87DkYtG003568 for ; Sat, 7 Sep 2002 06:46:34 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA43921; Sat, 7 Sep 2002 08:50:44 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA14756; Sat, 7 Sep 2002 08:50:43 -0500 (CDT) Date: Sat, 7 Sep 2002 08:50:49 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Saji Kumar VR cc: Subject: Re: How can I become a part of XFS development team In-Reply-To: <00ac01c25346$cea919c0$670b720a@wipro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Saji - Sorry for the late reply. The main activity lately has been massaging XFS to get it ready for inclusion in the 2.5 kernel. Future plans include updated releases, and addition of some features like unwritten extents and realtime subvolume support, off the top of my head. Anyone is welcome to help with development, but it will have to be a mostly self-directed exercise. We're down to a handful of developers working on the project, with other internal projects, so unfortunately there's not a whole lot of time for tuturials, etc. If you're looking for a place to start, there are often bugs reported to the list; if you think you can tackle one, go for it! Other known bugs I can think of are occasional hangs on shutdown, and xfs_fsr is not properly zeroing the last bit of the last block of a file. -Eric On Tue, 3 Sep 2002, Saji Kumar VR wrote: > Hi, > > I would like to know about this project, like what are the future plans? Can I join the development team? > what are the current activities going on... > > Thanks & Rgds, > Saji > > > From owner-linux-xfs@oss.sgi.com Sat Sep 7 06:54:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 06:54:02 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87DrxtG005160 for ; Sat, 7 Sep 2002 06:54:00 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id XAA07989; Sat, 7 Sep 2002 23:50:37 +0930 Message-ID: <3D7A08AF.5A442BB8@rebel.net.au> Date: Sat, 07 Sep 2002 23:39:51 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Saji Kumar VR , linux-xfs@oss.sgi.com Subject: Re: How can I become a part of XFS development team References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Eric, > Anyone is welcome to help with development, but it will have to be > a mostly self-directed exercise. We're down to a handful of developers > working on the project, with other internal projects, so unfortunately > there's not a whole lot of time for tuturials, etc. I don't know whether I have the expertise, although I could attempt it I guess, but maybe becoming the "holder of tutorials for new developers" could be where I might fit in... Are there any starter documents that you have somewhere? DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:02:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:02:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87E29tG005763 for ; Sat, 7 Sep 2002 07:02:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA43375; Sat, 7 Sep 2002 09:06:18 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA82723; Sat, 7 Sep 2002 09:06:18 -0500 (CDT) Date: Sat, 7 Sep 2002 09:06:19 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: David Lloyd cc: Saji Kumar VR , Subject: Re: How can I become a part of XFS development team In-Reply-To: <3D7A08AF.5A442BB8@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi David - A good overview document of XFS features is chapter 9(?) of the "Advanced Filesystem Implementer's Guide" that Daniel Robbins did for IBM's DeveloperWorks web site. For lower-level technical info, there are XFS design papers on our website, but those are fairly dated, and have no Linux-specific info. Unfortunately, that's probably the best info in writing for now. I always thought that a document that showed basic filesystem layout, superblock structure, allocation group header info, etc and tied it to the structures in the code would be nice. Most of that information is in the design papers mentioned above, but it could be tied together, updated, and tidied up. Thanks, -Eric On Sat, 7 Sep 2002, David Lloyd wrote: > > Eric, > > I don't know whether I have the expertise, although I could attempt it I > guess, but maybe becoming the "holder of tutorials for new developers" > could be where I might fit in... > > Are there any starter documents that you have somewhere? From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:11:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:11:09 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.tellurian.com.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EB3tG006335 for ; Sat, 7 Sep 2002 07:11:04 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA08451; Sun, 8 Sep 2002 00:07:50 +0930 Message-ID: <3D7A0CB9.2B6870D6@rebel.net.au> Date: Sat, 07 Sep 2002 23:57:05 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Saji Kumar VR , linux-xfs@oss.sgi.com Subject: Re: How can I become a part of XFS development team References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Eric, > I always thought that a document that showed basic filesystem layout, > superblock structure, allocation group header info, etc and tied it > to the structures in the code would be nice. Most of that information > is in the design papers mentioned above, but it could be tied together, > updated, and tidied up. Would SGI have a problem if the document was auspiced under The Linux Documentation Project? This would have the effect of throwing it to a wider audience, a peer review system some of whom have no idea what I'm talking about (always a good thing -- this is a tutorial, so the only thing I'd assume is that the person knows a little about working with the Linux Kernel source code and file system concepts)... Would SGI mind if the document were under the GNU Document Licence? (I forget the correct acronym) DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:13:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:13:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EDDtG006818 for ; Sat, 7 Sep 2002 07:13:13 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA44355; Sat, 7 Sep 2002 09:17:24 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA68024; Sat, 7 Sep 2002 09:17:24 -0500 (CDT) Date: Sat, 7 Sep 2002 09:17:29 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Saji Kumar VR cc: Subject: Re: How can I become a part of XFS development team In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 7 Sep 2002, Eric Sandeen wrote: > Other known bugs I can think of are occasional hangs on shutdown, > and xfs_fsr is not properly zeroing the last bit of the last block of a > file. Oh, actually - the problem is not with xfs_fsr, but with truncate(). A patch was posted to fix up xfs_fsr (Subject: [PATCH] xfs_fsr causes mapcheck to trigger) but it's really truncate() that needs to be fixed. -Eric From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:18:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:18:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EI9tG007317 for ; Sat, 7 Sep 2002 07:18:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA44497; Sat, 7 Sep 2002 09:22:19 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA70509; Sat, 7 Sep 2002 09:22:19 -0500 (CDT) Date: Sat, 7 Sep 2002 09:22:24 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: David Lloyd cc: Saji Kumar VR , Subject: Re: How can I become a part of XFS development team In-Reply-To: <3D7A0CB9.2B6870D6@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I think that if you author a document from publicly available information, you can put it under any license you'd like. Although I'm not a lawyer... If you take the design documents (which are still incorrectly marked "confidential") and cut and paste from them, then that probably raises different issues. Although I am not a lawyer. :) -Eric On Sat, 7 Sep 2002, David Lloyd wrote: > > Eric, > > Would SGI have a problem if the document was auspiced under The Linux > Documentation Project? > > This would have the effect of throwing it to a wider audience, a peer > review system some of whom have no idea what I'm talking about (always a > good thing -- this is a tutorial, so the only thing I'd assume is that > the person knows a little about working with the Linux Kernel source > code and file system concepts)... > > Would SGI mind if the document were under the GNU Document Licence? (I > forget the correct acronym) > > DSL > -- > Con te partiro, su navi per mari > Che io lo so, no, no non esistono piu > Con te io li vivro. > (Sartori F, Quarantotto E) > From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:21:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:21:16 -0700 (PDT) Received: from rebel.net.au (IDENT:root@mail.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87ELDtG007805 for ; Sat, 7 Sep 2002 07:21:14 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA08725; Sun, 8 Sep 2002 00:18:01 +0930 Message-ID: <3D7A0F1B.34A826C8@rebel.net.au> Date: Sun, 08 Sep 2002 00:07:15 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Saji Kumar VR , linux-xfs@oss.sgi.com Subject: Re: How can I become a part of XFS development team References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Eric, > I think that if you author a document from publicly available information, > you can put it under any license you'd like. Although I'm not a lawyer... I know, but upsetting SGI unnecessarily would be a little pointless woudln't it? > If you take the design documents (which are still incorrectly marked > "confidential") and cut and paste from them, then that probably > raises different issues. Although I am not a lawyer. :) I'd need someone inside SGI or a contact to actually work out what the issues might be... DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:26:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:26:29 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EQPtG008301 for ; Sat, 7 Sep 2002 07:26:27 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA42408; Sat, 7 Sep 2002 09:30:36 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA42603; Sat, 7 Sep 2002 09:30:35 -0500 (CDT) Date: Sat, 7 Sep 2002 09:30:41 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: David Lloyd cc: Saji Kumar VR , Subject: Re: How can I become a part of XFS development team In-Reply-To: <3D7A0F1B.34A826C8@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I don't think you have anything to worry about, but I can't speak for SGI on legal issues. I'll try to find someone who can and let you know. -Eric On Sun, 8 Sep 2002, David Lloyd wrote: > I'd need someone inside SGI or a contact to actually work out what the > issues might be... > From owner-linux-xfs@oss.sgi.com Sat Sep 7 13:46:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 13:46:40 -0700 (PDT) Received: from bonzo.nirvana (pD9E7D8BE.dip.t-dialin.net [217.231.216.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87KkUtG012122 for ; Sat, 7 Sep 2002 13:46:31 -0700 Date: Sat, 7 Sep 2002 22:50:41 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Cc: linux-bugs@nvidia.com, =?iso-8859-1?Q?J=F6rg_Prante?= Subject: XFS & NVIDIA Bug? Message-ID: <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by bonzo.nirvana id g87Kofj25934 I am using J=F6rg Prante's kernel patch set 2.4.19-jp14 from http://infolinux.de/jp/, which includes among others o XFS for 2.4.19 o rmap-13b o O1-Scheduler o low-latency patches o preempt-kernel If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get= a kernel BUG at filemap.c:236 in Trace; c012cc26 Trace; c012ccee Trace; c01b2de3 Trace; c01c95e6 Trace; c01d6399 Trace; c0155efd Trace; c013bb09 Trace; c013bddc Trace; c014e76f Trace; c0108a3b (the whole Oops is attached.) This happens reproducably with VMware, but also with Samba (nmbd), which is pure userland. It causes severe filesystem corruption. Using the XFree86 nv driver keeps the system stable (and the NVIDIA card useless). Using 2.4.18-4SGI_XFS_1.1 (with the root access fix applied) and = the NVIDIA module also works. The XFS FAQ mentions that any NVIDIA driver later than 1.0-1251 would fit. = Do maybe the newest NVIDIA modules break XFS again? --=20 Axel.Thimm@physik.fu-berlin.de --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Description: Oops.txt Content-Disposition: attachment; filename="delme.log" ksymoops 2.4.4 on i686 2.4.18-4SGI_XFS_1.1-puariko. Options used -v /usr/src/linux-2.4.19-jp14-puariko/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.19-jp14-puariko (specified) -S Reading Oops report from the terminal Sep 5 19:33:29 puariko kernel: kernel BUG at filemap.c:236! Sep 5 19:33:29 puariko kernel: invalid operand: 0000 Sep 5 19:33:29 puariko kernel: CPU: 0 Sep 5 19:33:29 puariko kernel: EIP: 0010:[] Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 Sep 5 19:33:29 puariko kernel: EFLAGS: 00213286 Sep 5 19:33:29 puariko kernel: eax: da7ebd88 ebx: c148f490 ecx: da7ea000 edx: d9fb4ad8 Sep 5 19:33:29 puariko kernel: esi: 00000000 edi: c148f490 ebp: 00000006 esp: da7ebd28 Sep 5 19:33:29 puariko kernel: ds: 0018 es: 0018 ss: 0018 Sep 5 19:33:29 puariko kernel: Process vmware (pid: 7115, stackpage=da7eb000) Sep 5 19:33:29 puariko kernel: Stack: c148f490 c012cc26 c148f490 dc0536e0 00000000 00000001 00000000 00000000 Sep 5 19:33:29 puariko kernel: 000186fe 00000003 00000000 00000000 c18b1000 da7ea000 00000000 da7ebd88 Sep 5 19:33:29 puariko kernel: dbb68110 00000000 c012ccee dbb68110 dbb68120 00000000 da7ebd88 da7ebd88 Sep 5 19:33:29 puariko kernel: Call Trace: [] [] [] [] [] Sep 5 19:33:29 puariko kernel: [] [] [] [] [] Sep 5 19:33:29 puariko kernel: Code: 0f 0b ec 00 5d fc 2a c0 8b 43 28 85 c0 74 0e 6a 00 53 e8 ad >>EIP; c012ca7c <===== Trace; c012cc26 Trace; c012ccee Trace; c01b2de3 Trace; c01c95e6 Trace; c01d6399 Trace; c0155efd Trace; c013bb09 Trace; c013bddc Trace; c014e76f Trace; c0108a3b Code; c012ca7c 00000000 <_EIP>: Code; c012ca7c 0: 0f 0b ud2a <===== Code; c012ca7e 2: ec in (%dx),%al Code; c012ca7f 3: 00 5d fc add %bl,0xfffffffc(%ebp) Code; c012ca82 6: 2a c0 sub %al,%al Code; c012ca84 8: 8b 43 28 mov 0x28(%ebx),%eax Code; c012ca87 b: 85 c0 test %eax,%eax Code; c012ca89 d: 74 0e je 1d <_EIP+0x1d> c012ca99 Code; c012ca8b f: 6a 00 push $0x0 Code; c012ca8d 11: 53 push %ebx Code; c012ca8e 12: e8 ad 00 00 00 call c4 <_EIP+0xc4> c012cb40 --Kj7319i9nmIyA2yE Content-Type: application/x-bzip2 Content-Description: Kernel_config.bz2 Content-Disposition: attachment; filename=".config.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWdpvDbwAB+HfgEAQWOf/8j////C////gYB/8AAHMHSi91HA5 UFAb46U+xaACN61LWUpTXSgOi29e9jVHvWFA6A9B3e3RF73atgG3W89utWvX ElVSffPnc3dy32++3w1MQBMRkJiNIE1NNTMoYmTMo8kANBpoIAgTQFJmmqGQ AAA0AAAxAkNTSaeoyDVH6p6QD1PU08UekwNTQ9Q9QBJpJIaRqYJimmp6TQ0G 0EGJkYmgHqGgkoRpqaT09TIanpT9R5Rkj1GTyZGiA00aNpAEiIEAICImSNDU AAAAAAft/D8fcsq1bI0pRrJWKttBiFKWoCom0mJ1e4HSX3YZheFwykFNggFp 9z/RM5IcOr/Nz/beJeK7U/BzZn4pj3ELAefRyiRawrUxKyW1SoCyFctihiYw aWChiLFrJWI5SyVhWVKkWGCEKwCpUByyityiwUgVXFMMyONrZlkMGKYmJJ3J pJjK6ZUK1hjDEMcRSTGYMgYwgYzBC2lYpJUUMZWYmOMLlrjWCixYEFwSLAWu DMaitwIBVuWqxRssaI2mDKz4GmhtaavrvvuC6axsqiloYeyzXsu3EqTSExg5 kVbnws4JtJotNmmMkKxSIYhV43MLcumGFujJhcjBW0wtcsDC2Kc2QNMk1Lpu DmZZiXMuJV5uGF0ZkWEEcK23MsxRlSmTMUoOJaiYkU0hphmu9HQcuuXwvxfv vn19+Q4Ld5hgO1fPEuCSQQN6zWS1+bDsnlVQPNZoGgjwxYbUIUIDTHWnyU9D GySHYmQNkRVWc5UYnZgNA0gBIlKpr8LP/PocZn+n5RWTx+pgssbw6ZCHvX1q uGrExgzT79Ofy+O3Xb7MdPx/p6SwZ2g/6TjsSy+Ua+Hya2Mij1ZPzu0Ln9k2 JCI/m59C0+eeWGDW2N+jPg9v2tGkp2+NJLojFrBNyt8+hk0PL5nh8eMW40pZ hjSNcXjszDjHmLHNLQnat1+7CDr4yltES0v9G0ZpHBIurOkITyhq2la87s2c bkTu9p8HSmI74mWLWvO2j0bHZFxMMQrXiekfKmniNuVxjPi787uPppmobu3E CvpClz1xazHl8JlXprBkAQBOFMw7YdFo7F+O8bQg92syl9EgkM15QyP6HpAr YLcyi7GzxfA6VVmxhVha1a/XrOYjYWrq1XMHsfMZtiY30Par8k78bdvSnXGn Dsw0q7jqWjcq6kb+bX0XoSGvfu8NEmW4nKFq9ntxa0ZTbAWm4s7p5dmX2pnw beeStxHWGuuXGlYjH3bb0ppCkt+MGZoi2+xvC4gZ/OHWnpR78SB6EnTu5+Tw 55X0oauysDNXlhfh6Z8687Hbrthjp2veLmSnW0bPTl7rWVdEHRjMP9zerkOr frEkhBv2dnR+czZNtGEwiSQgI5v5i/uwHZHyo46bM88aU08cfqUX6x+48QAQ CD6vaCn+r10U25a3zSW1ds7Z6m9ZMN4R/1++U58MdGPB406OwztW20br8Kft 2tSTWezJlYMFLc69iEVL+DFg6fCHCFVUQWNdzwngY1BSLn7NQebdrM+QzUYt vztesC7xhKkQlJ8af0d3eO7Nnxx8hhQWmnluG3hEen2Z9eOnVdDq1/JTbJxT LY/w/yOf0RA+MMBj6sCmindHF0+wmmrujYjx8+Pli7Ah6FHLx1bXoN9/OOPb R0Z4doJKvivz6YshacMmY+/fux3gq+sSzkHTQmxvXszVkU4+MhstqK3oepIo sViOJ0mcLAiUQAV1y7oAIQpmQPvzU12jerctpeULRFNs8DD6WPHbHa0WBsqb rfcdN+r01KsnAhEwq2nRK8sKQQlAuvcwMttriWVh4pdNM84xDmrrvQkwk+eN pjC8pvgV+IDFQ1qBbaETNT1W+mudl8SK7zrI9xuSSFygiuqies0ZGBARsw+/ FqxL5AuhE+d6iBcDZR6vGfYXpRjE694pIE+oPIzfswJZmLtINF+1cMaKbwRk KEAFcSeXORiUu0q5rYbJvftSLF1FHcXn1ym3YUIU1KvrGTEARSnbRhn5N1V+ ehJ3wNXkVwZAKjalmgB/dFgwAqTHNsX8B4AKbhbCHZO3p055GauFfFYYIhj5 PlmGXrga7uIaSDAQYDEHHO3ivnoN8cMCioUXMBSb9vhPrW5UNCWYIufk/zi2 6t/kXsaXn1wj19jSrH02wRrW25xYxm+B+1t2L8FuZJGZ6wEmMthFz38WHpLr iRyy2f2ModdfAzm2BHDd1GKc8hyacRT3j6JNStA4NJtEd1LiXd2z60417eJv f3jxj9eq82m4c8ewdTqaJyvmzc/RxNQ2tcGIjmm9N/r68al0PxTLzrhLHJbX uhZ5Oqwr3bFvkeuDiIXwHgvSfG7YQcguj/CSeQj5VjsbMOzK+HCJr1g1bLXG hu8KnvS/eGUr1zu+TSItIsguuRveWbdGuFobTZeHn234kjzLN19DWvHyyryY 401Gu8l1LArQNZPc6MOZOguCB25xyLuh5PesGe+rZbG5zkw11zLci5ktYe3s cJROpkUic9ZdZvY8Pw2jxJ73pwEJaiID2FVgHpNaSmEESf27kNGAVtTJsmOx LDSRPihJobl1oEDjmxqN627aN4LEgzgRdmFv1WlvY/OMMSJAgqkoEcyermnr 9fmkm94i22iDFD4vTGURjIBQ0EBOppCOVeiclJ97NcOZ41priD3l0ucwOcr8 WLdeLWwuOGBsQKF5MBg/ciQqRggDkETPL7TwN78kU74rVb6kXEcPSI1DMoJO 0IXi3U+MLFtS0b58ZR5OaPmkNEmVtw0QsjfZm1is5ELXeTcmwwlcUUJdsP6n UAoQ9ptvpnR3KdDBR2C8IMoB47rXJ8Q4HS+M42pE+uFKXz58fbFLGg6GXadG vlt7XRCBBbR56zxWGRefm2Vj4ZLS5SQ9ZI1erFrRjSYzEPHLDGVjksoirJIp BYIo+KTiDS3Osqd6LO1Tjfw/2jY4qwFKUDJ7CLqs7iwsImUxZdJlpnShqLdM 1cyggZfcVuIj2E5CUasGHTol3TSeiG9GDkPy4XIvJzolQLT1d+hYAjWnkPSa kl22gkYirNzkHawUnYOuM1hFm+LuG2wacPfO4ipZEIoyxvTKhhiRfe1/Dbfe z0bHcB9TEiiyMiICqxIKjGMVQigisiqIqKgwRBQEiLEQFkUiikRUkYKDCKLB iLBYsBggiQRIqxSCSLBSDEVjFRjIsiIxCJBQEYQEUYoowRRijEgqMVgrIgjF YAxSCjGKKiERikIIiiIwQRIiqAikWDJBRYqxZIRAUgsRgMVYgqIgsgqwVBBQ GIxWQWKsWIwhEYsUVGRBgpGAoNNJsGmUS9fZKPqbbT+fPHQFirAKHiRUmKRI RNC54lbsKJADirF6c+Kv1S9Yx3+FTDLV0vk7ryyE2IyagasOWqjorzJNdpRO 0NDuwCgkoAVVWWaq1ZKBympQffM/V+uXWd9tcGlPYbLeQw9C0dxgLvZjAwSq YmSlJrvqw95B9aNbhaYxAdmPT9T+RuRbQrSyssO6oQFjaVdO0Ced4dgFI0kc o1YBLby3kEShqwxBYSJgrPZhBjSMfN7e3GHQdSgREUFAlsgixAwJZ9g9DTa+ UjpKs0l7M8XKazI0Ds76OHYId4i0MG0PJ/B0b77BXIui91RSnvvH0aCnMKNf AKJ99hhoVRsgWQuqptlQOxqdu6gF6tEoRjlWIPo8VBeAs3W+22jgZS6JjAo0 MrtSrE8V9GQhJWK1Ix7PXDH7qyyZn4PTR9i+8KdSHEk6RBdxVmFBirtLTv5W eeokffL5NrutFgpPfeZrsfq3IJ0zSSs0BL2VR0NNKrO1QRSzJ38/Qla4MCx9 Sb8ONngIMEScCyzwHqQ+/T04FaJBRbVh7rrMKBAUKM0siiyrrcANzQyMzeha qgQaVhAsUyzqa3tSE7x7z6Oe29irX4Msz32t2DpggwpIeeMS/rOYoQIJOKwb FWqZyHjpS+6dg468bF3GjDmJhZqT8Lz26xxAGtI1rDzg500J4zgEaBnCIGCi FCoVyENoBEtnUE/oYr8MReMGecAjUypI2cKSLnRguQXhpsKrWXQ1cCU7WY/E c/Ve0xM9dDz57dz7Pu/osggDdgjw/uzPOI+5P3l3qeRIQAbfWemP6x7fBeCH v+dFwPcqJj9NIOWUY4qLMBQguaKaqTJ15u03x4f1dMJDim8pTpOnZtTdQirL 2OdaFZ7NGbQUeZ7sjRy0kd3DQfufY+7FOAaXna9bmZljPS1mrulmOdfl6ey9 7e05nJWlJOcQa0Pt4hWxXHhBhAqtEW3tZEVaH954sWcpmjhwWAvrS0QkIyzg KN4SSEHLkkgoBBYAQ4oEqSAoAAsIm0lLQkI7H24bSb0Daci8xMG82eWb5m4n EKqN3FG23jxKhrFuCyo/wxI9ApYMVEShUgIRXaIGCN1cu2d+ivXiNrxP3Iw8 OjLlFZ+AoRXPZAm0tWLkrZt4xJDDy48yjdCBhjaIOsFoLfhjsaQjLbGUmcZc FdAkeZRrV+mOO+sdGDSD/iECk2EEI4YpLaE+TUyn7X/Hru/vUsaaeX1IXjct 5wJCAD3Lx9vC6tN9JFld02BRb1FZq+0RwB8jtTFPFAxmh8Pci54zIlNxmrk1 aAN2fPJAqFZjEuOsqhZtVKNNgNsJ2KFklnRm56z7O+ZX3KO7KKkCHjEoEs2/ EDfiQ+eSiehyVaPwqirMnKqhQhfoLxOg2y+54u2x68IEPm7B6Mrcr5E0qGmJ cwHMumSKvqSdq4pVItSXrbMC0FOauM34WbDbRLo7UhNjZE+A9W2PLR6apU1L 5fsJxQaj7tj8CsuRIU4zKrpUQ++wFB2gEEOAxIaYvWSqwz5vWY7bUwaMEBkj Te0o42mq8PziDvSsrIxjU6ZmvQPcXJhgJKcissHNTIuvYxbPhV7yo0VeHax3 XoyX1FTOizAvfkuKYAHxF4MqwfRY8ZvSK3VtNRICfiazA4RAyNIO5aEUyzla egg7mUQ30eNaanZ+mAoYk2xPTZnQogRo+Dgy9Rp1NM1kfXWEI7tLDRcMammt ifXxBgzhuCpFMrvV5ZQEzymUvRU0UhXGgEgT29BSVYhrfCcQLzY6tsMNvLTO TusvUlftCS5YFRFA5elNn2GmUNADUatCCjgVDuixDaxqRqgzEqLgh+Ji6X6L NEQaQZMM36Yc9UxtXR/qzJ45qjPELl+BsbYO6K1od3l80r77W8/GuudToaqP 7v8tSD2iAgRy178uHglldYalkD3exXr9LSqr5rh2dGNk8FFUypZtcyWbO+Hf rt29G7AeQ92pMmahKmGgSM3gOMU5ChGFEkgJ7DmZrrk35HDXbflxTnrnJFAD ReNJCABYZJIMKml1c1gylw7T3t66i4wawyGXSEXT5rPuiu93qPyFskgMx0RO 1hCIRCSTM7SxsZFkFiTq1Kw2or2+5WrGmw8OGDzzgRmeUp/ToXf4d48vN2ZD XzfehFPKEybQYHcp4n2QZ0WYxk9KXgJPPxeHRqSD1O91MHpz8S7K+XWKKltF dPZiTbN5SNFPyjT8rcTEJv1rM5MXRUcM0YHXWUnJ9rsYkIAM+xvqqdsQiGdw rFBg2Mz4MeR721k2L7JDXB3xQtxpfV7S4sxHYO0chwdaz9SmSSW4Ha8IWobb 6FH9adq0ZZZ9s+8fB58KcFSEjHAIssndgu/1f1boCzOPfcfcHRyV+N7n0zIr C4+aGLQVZF5hyOGQ2S4bQ6omNLkhVsj4hqW0zQaGbeIzcJPdApEa4YTKKxoD R5CRIjJykHtoM3QggMeIpEReDE7SX11lK7QN+MELDDJo20DbSkQT1+kZemvZ pZ+84TD4zrGsy3xCOLIZuQYHYAZN6ObdGcksuQBDZVrYvmnEsFaA7WgrcmUH UyKypekIxEJEcWphImpBHAO81y4XfBzrn3SAgyq9HqPwd5o+mb47XL4LMQKS H9PQr4/Pz+Hk9MxfrToLNJv2yrKEa1D2cQQ+ojZ0mB+cp+kZAYXIluVJh6Nq UlJUtal0cKOpqURH6UQD2tGVhM+I8UgswGsG7g9bc7FA0jEBdzaKTtzrSgUg nvsSiXSmcY1mB4jNMQ7kQJBdkbamo6FR2hRXO/nO/bL5doygMCEXX6dcYd8m TIEKRgkWoat2aOWKT+GHefqBDOTnq+N8Y9NBFd/no5Yk352V6FJjPqNjQiQA bCrJlkFoSy6SFE6csJwyW65XsnPM0trl9U9vmc0/MRlcVpa7LSNTOasWT0TO W0jjoCaH4YIVtExIQgRqXI2K8Mri2ueKLh822MLsHed6oAKrMzOWRZB9GqHS zWb5tpdeHheZyAeL5iOQizo0QBHXeenakAsMfrL5gKS0CWnaMXvMmSkoacvg w7Ep5aFRkFRIjCGTDp6znkkjNUkBOnGmHJ0wrrrnehWeOocTwQoGgJNb41BZ KGv1fFniw0G9O8HjCaSnbDypMSklIIngg8CMRdldYyzvJzeplozFYyL8YuRc 1KrPTGVIyvIiiZER2fzEJFHjMiI8yFqwaNHba6OPPgSKUlEjIGkumNrZyMpB zOBMRkqzra8KawYM45VypbHh3+Uj3bLwzL0GbX2kVJ1VpCau0qFQeWnTigcT JRq0cati5Nrw8n1UeirPrSl0RhFWuBGRlgGFjATQMkVYQex8YHOo8sy9Sdqh WiCDmCZIcxaRBCUdhNpxoTdQFGtm+eJCuZ3cwKcHDBb7sRZlDAR2niqVix66 l68xj6TlaxpBxFdDnKj3jRqDxgRhgkgugTQThxIRqsYs03HxxkEoc1+9Ypw/ FlQA2AvoKXBrxFnxsV2g0BhYDCEpLWu5isfqa+R2Q7uzwxS83Lqd4uXqXIes crVBT2yJdZgbJM1IWpiVQlPeJUxDKu94e1VaSPNy0wqSQMAcqKwpmG8Rgant 9A5quA5/M22tU2NLRHeR0PokQ0DahdU2vr62vRUQQT21mLH5zXWyneGkFCGS EKUOmhPuiqWOODDqyoHQERCa5YAjIE0ciqjxekeLCuMFTslfFUAazBqrJXmt Fqw6y6REzpklla01iLJl2Iu5GINsQvVjPFE7F7OilwIIYCXBwfI6rmuhLGZ+ yV4XQp1nwVZERQNyvG6wmFbxmeIHJ1FO8kX3XHmVtSHum8rIv22PYnu+tPtJ Q9R4XXAg+AkxQCkBZepzfTq46LTzZewtmoYjTr6b0ruPw5fWe1ibWBjj9UQh CckCGNyMIZePJNOc33Wu2RjpDquHKrkDNrYS+JQahAQJu8470nqLoB9JtPJG L+4G7rfRvqe3VXSqFLW4bj2yT6JIM5hgGa0o6Ne7AEMhMAXuNuFQgRZzsQYa kZqttB4iVklmte62VAMMPsUglXhcLNs8a+Kmtsq0NWEfnAkBa0G8fUz7VYfK nPGbDM4bE/mZb56momBxFqas4QSA+k0WoDMBlcVtiFKDYaK0vo9L4rxTQTnq wwKxol5ZLtnzyz82o+ySuobl/BTaq6vpVKlJZmLdY136MkHqyBWkkasTYNig tplptv1cztHGMWvE/tWQX28VoiBRcGRkUFqyZGeT4pXWfyqJAw7TDgsqUvta JWSE4fmSTx3mvFTnyVPnxWcX++4fi0Ue22co26hTSw9c26M79DyBUJQy1rBN yqQGrs2hJiB7rapFdeFwEkNhT0Rzy1AWGtXtaHW84xCBQxR51iV2cdzN5FFi sUY9lKonneZvv1GjfOmjlsIDV4fuvzzzfnrFe2ezB51Qd2AlWszGY7Ts3Pmw CLAXzAcATXQbh0e6IKNQLm3MCxHFT1pEVQUWdZMLF9ljGs3hlCYIzkVae15w GQJGbmu/qE0Njc5NSg0L1x1eUKBAgKARvM1cZgd6+YdM9+4PBzBk6GlY08bd 7ojxiYR3hB2qoN+YBI7+/vWiOXwkgmZu0kNiTdHbhxzbximzXqM7zxzf3tis 71aHtXmYfso4KBOl+niq95vvasu8gG0gOGgeLs0gzBD9tUZLccOONMsjqvcY vYdYqDEljztp+PMFIsgh5O562NL8TamklaezKAkGZd/UmPMU8NWkIif3ynVj nwSQG813q6HM+4wL9zMSHhvARkppfyZ9WO9z8O19u3Pq61lIuTdoQs2T7t7x cskkeiqCUJREJIKEoobmkWM72pBcV23rLNoIe8UYcuMoOzQiD4jLEMjcrqg4 5znvlZi1yiM9dELiGUHYfBeUAYaxnvxmJDovFqVwe+2zXNVuw4zL8eeuLGiP yLtW8axr6mBoC8LocEDI8gC7UBABG+9LFddOw44Me+1VljRv3lxnzoWV2IH8 RExdpvvSFoM2evbd+u35R8X/XMcPnv56ohNgvU+vVEYte5GYXwO30Ptu69dg 7++czMEnzZ5MnljOjyKYKbEoV6LvB8Lwy1PmEL7qiucfxGnL6/XEGUR5BEMi ejVupxMiCzx8RqRYKPSFNjYC6BFhJ9zc0AjTBdPxQrP/uX9Hb+pOSXt7ppg0 EhgjcI1dNjfHD6vhhs6QutOL7lhBmQvLqQp66zrcUE6QMhZYMW+FA5ZBREK/ cZ5EFdCECVJ33EkhBROn4+ZhEVofyciTHmezq+ax3rLYWytX4vufK175RsH3 +yqSRg0yDYkdTuWsQNNPSZVsGSKTTzu09OeSmiKmOViV+fVFkBJIQVEPQZ/D BmGMELuNXjsDpPv2YwgvQAnDr+738+EccEa+JE7wrgsFEvwB8czlcCr38gTS BJIPfhb8LutVxMYQg0l06ZGIR3ZQtJ2spAr9f0ZNiSQg0sjIi8tjk5grOPxu xVGrH7+SEuyeHtl10FTDBK2/iY0GrNDigjTqyYp9qIO5khVbogAkFlVhlx6P oXO8y9MmbZiSRWxjDmwgW1bEBgje+MrMeIgxBH446pHx+78dVzLLLMjDRJQ+ Q8EDYiD9HRxOBCBX4okFrsvmD86PYFo/dlVYzL5GNKdHGZ7O1e4kkIGJ1X0A AkHt1qsXeMPf4RGEkeXCSRokGUIBICErMWd/+fmWAiIgQAuZgrQd85F0+j3p A2FJ1u37RVkQYqaCZQAZJEDYnI1glD73iQ5kyX7XMv21/irb100++ofsbaTY jbcpZ2PjzH6/XjIaCHAgpxhHv6U+/gcME3DcgGsBIRTRdda92vI42SHGWUn/ F3JFOFCQ2m8NvA== --Kj7319i9nmIyA2yE-- From owner-linux-xfs@oss.sgi.com Sat Sep 7 14:59:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 14:59:41 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87LxZtG013291 for ; Sat, 7 Sep 2002 14:59:35 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 5EF8DED2BE; Sat, 7 Sep 2002 15:03:52 -0700 (PDT) Date: Sat, 7 Sep 2002 15:03:52 -0700 From: Chris Wedgwood To: Axel Thimm Cc: linux-xfs@oss.sgi.com, linux-bugs@nvidia.com, =?iso-8859-1?Q?J=F6rg?= Prante Subject: Re: XFS & NVIDIA Bug? Message-ID: <20020907220352.GA2594@tapu.f00f.org> References: <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020907225041.A10340@bonzo.nirvana> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 10:50:41PM +0200, Axel Thimm wrote: o XFS for 2.4.19 o rmap-13b o O1-Scheduler o low-latency patches o preempt-kernel You have *many* variables here. Perhaps you should try with plan 2.4.19-xfs and the NV module and see if that is any better. FWIW, I use 2.4.19-cvs+rmap14a with the NV driver and don't see any crashes, but it may be I just have luck on my side. --cw From owner-linux-xfs@oss.sgi.com Sat Sep 7 15:21:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 15:21:56 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87MLrtG013970 for ; Sat, 7 Sep 2002 15:21:54 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1DEA61D9A03; Sat, 7 Sep 2002 15:26:11 -0700 (PDT) Date: Sat, 7 Sep 2002 15:26:11 -0700 From: Chris Wedgwood To: Eric Mei Cc: xfs-list Subject: Re: hardlink overflow Message-ID: <20020907222611.GA2652@tapu.f00f.org> References: <3D79BCE4.9050703@mountainviewdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D79BCE4.9050703@mountainviewdata.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 04:46:28PM +0800, Eric Mei wrote: > it seems linux-XFS didn't check it's overflow. simply add 65536 > hardlink to a file will make their nlink to 0. Yes, I can confirm I've seen this too. It's not hard to patch this in XFS, but in general I wonder if this fix doesn't really belong in the VFS layer and there *are* system calls that can return larger than the 16-bit value. --cw From owner-linux-xfs@oss.sgi.com Sat Sep 7 18:44:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 18:44:22 -0700 (PDT) Received: from dns1.nvidia.com ([209.249.170.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g881iItG016258 for ; Sat, 7 Sep 2002 18:44:18 -0700 Received: from NVVwall.nvidia.com (z06.nvidia.com [209.213.198.25]) by dns1.nvidia.com (8.12.4/8.12.4) with SMTP id g881mMrE009938; Sat, 7 Sep 2002 18:48:22 -0700 (PDT) Received: from 172.16.217.105 by NVVwall.nvidia.com (InterScan E-Mail VirusWall NT); Sat, 07 Sep 2002 18:48:17 -0700 Received: by mail-sc-0.nvidia.com with Internet Mail Service (5.5.2653.19) id ; Sat, 7 Sep 2002 18:48:17 -0700 Received: from [172.16.224.92] (172.16.224.92 [172.16.224.92]) by mail-sc-0.nvidia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0337BJS; Sat, 7 Sep 2002 18:48:11 -0700 From: Andy Ritger To: Chris Wedgwood Cc: Axel Thimm , linux-xfs@oss.sgi.com, linux-bugs@nvidia.com, =?ISO-8859-1?Q?J=F6rg_Prante?= Date: Sat, 7 Sep 2002 21:46:05 -0400 (EDT) Subject: Re: XFS & NVIDIA Bug? In-Reply-To: <20020907220352.GA2594@tapu.f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ARitger@nvidia.com Precedence: bulk X-list: linux-xfs Yes, if you could narrow down which of these patches are required to reproduce the problem, that would be very helpful. My development machine is 2.4.18+xfs and I've not experienced any problems. - Andy Ritger On Sat, 7 Sep 2002, Chris Wedgwood wrote: > On Sat, Sep 07, 2002 at 10:50:41PM +0200, Axel Thimm wrote: > > o XFS for 2.4.19 > o rmap-13b > o O1-Scheduler > o low-latency patches > o preempt-kernel > > You have *many* variables here. > > Perhaps you should try with plan 2.4.19-xfs and the NV module and see > if that is any better. > > FWIW, I use 2.4.19-cvs+rmap14a with the NV driver and don't see any > crashes, but it may be I just have luck on my side. > > > > --cw > From owner-linux-xfs@oss.sgi.com Sat Sep 7 19:32:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 19:33:01 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g882WxtG017133 for ; Sat, 7 Sep 2002 19:32:59 -0700 Received: (qmail 23223 invoked by uid 500); 8 Sep 2002 02:36:41 -0000 Subject: Re: XFS & NVIDIA Bug? From: Austin Gonyou To: Axel Thimm Cc: linux-xfs@oss.sgi.com, linux-bugs@nvidia.com, =?ISO-8859-1?Q?J=F6rg?= Prante In-Reply-To: <20020907225041.A10340@bonzo.nirvana> References: <20020907225041.A10340@bonzo.nirvana> Content-Type: text/plain; charset=ISO-8859-1 Organization: Coremetrics, Inc. Message-Id: <1031452601.22717.12.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 07 Sep 2002 21:36:41 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g882WxtG017170 X-archive-position: 312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Just curious...have you used the -aa1 patch? On Sat, 2002-09-07 at 15:50, Axel Thimm wrote: > I am using Jörg Prante's kernel patch set 2.4.19-jp14 from > http://infolinux.de/jp/, which includes among others > > o XFS for 2.4.19 > o rmap-13b > o O1-Scheduler > o low-latency patches > o preempt-kernel > > If I try to use NVIDIA's modules (the latest available are 1.0-2960), > I get a > kernel BUG at filemap.c:236 in > > Trace; c012cc26 > Trace; c012ccee > Trace; c01b2de3 > Trace; c01c95e6 > Trace; c01d6399 > Trace; c0155efd > Trace; c013bb09 > Trace; c013bddc > Trace; c014e76f > Trace; c0108a3b > (the whole Oops is attached.) > > This happens reproducably with VMware, but also with Samba (nmbd), > which is > pure userland. It causes severe filesystem corruption. > > Using the XFree86 nv driver keeps the system stable (and the NVIDIA > card > useless). Using 2.4.18-4SGI_XFS_1.1 (with the root access fix applied) > and the > NVIDIA module also works. > > The XFS FAQ mentions that any NVIDIA driver later than 1.0-1251 would > fit. Do > maybe the newest NVIDIA modules break XFS again? > -- > Axel.Thimm@physik.fu-berlin.de > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Sat Sep 7 19:32:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 19:32:59 -0700 (PDT) Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g882WqtG017137 for ; Sat, 7 Sep 2002 19:32:53 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g882b3s27269; Sun, 8 Sep 2002 04:37:03 +0200 Date: Sun, 8 Sep 2002 04:37:03 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Chris Wedgwood Cc: Eric Mei , xfs-list Subject: Re: hardlink overflow Message-ID: <20020908043703.A24188@vestdata.no> References: <3D79BCE4.9050703@mountainviewdata.com> <20020907222611.GA2652@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020907222611.GA2652@tapu.f00f.org>; from cw@f00f.org on Sat, Sep 07, 2002 at 03:26:11PM -0700 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g882b3s27269 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g882WstG017139 X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 03:26:11PM -0700, Chris Wedgwood wrote: > On Sat, Sep 07, 2002 at 04:46:28PM +0800, Eric Mei wrote: > > it seems linux-XFS didn't check it's overflow. simply add 65536 > > hardlink to a file will make their nlink to 0. > > Yes, I can confirm I've seen this too. It's not hard to patch this in > XFS, but in general I wonder if this fix doesn't really belong in the > VFS layer and there *are* system calls that can return larger than the > 16-bit value. There is a thread on l-k and reiserfs about this. Basicly it has been proposed to change VFS to truncate nlink or use special values (0 or 1) when nlink is to large to be exported to userspace. -- Ragnar Kjørstad From owner-linux-xfs@oss.sgi.com Sun Sep 8 04:02:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Sep 2002 04:02:42 -0700 (PDT) Received: from netmail.netcologne.de (netmail.netcologne.de [194.8.194.109]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g88B2XtG023579 for ; Sun, 8 Sep 2002 04:02:33 -0700 Received: from jungle (xdsl-213-168-110-59.netcologne.de [213.168.110.59]) by netmail.netcologne.de (Mirapoint Messaging Server MOS 2.9.3.5) with ESMTP id AZZ04660; Sun, 8 Sep 2002 13:06:14 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?q?J=F6rg=20Prante?= Reply-To: joerg@infolinux.de Organization: Linux Kernel Pacthset (http://infolinux.de) To: Axel Thimm , linux-xfs@oss.sgi.com Subject: Re: XFS & NVIDIA Bug? Date: Sun, 8 Sep 2002 13:05:52 +0200 X-Mailer: KMail [version 1.4] Cc: linux-bugs@nvidia.com References: <20020907225041.A10340@bonzo.nirvana> In-Reply-To: <20020907225041.A10340@bonzo.nirvana> MIME-Version: 1.0 Message-Id: <200209081305.52636.joergprante@netcologne.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g88B2YtG023580 X-archive-position: 313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joergprante@netcologne.de Precedence: bulk X-list: linux-xfs > Do maybe the newest NVIDIA modules break XFS again? Axel, maybe you should add that the bug you have reported to me has been initiated by vmware. Also it would be helpful to note what kind of video card you use. Even more helpful it would be to describe the steps in detail how to reproduce it. Vmware is a very powerful software with many dependencies, and maybe there are certain actions you took when the bug occured. I for myself don't use vmware, but I still encounter random crashes with the nvidia driver on a Geforce 2 Go since I installed the nvidia driver many versions before, so I'm getting used to it, it's getting old. It shouldn't be concerned too much to XFS. Most it's due to dependencies between the modified kernel memory management patches in the -jp kernel patch set I guess, and that concerns both nvidia and XFS modules, and much more. The XFree86 4.2.0 server is probably concerned, too. What I observe are infrequent freezes, sometimes NULL pointers in page_alloc, sometimes panicking. I don't have much time to spend on debugging. I comfort myself that it's absolutely normal in a bleeding edge development kernel under stress testing conditions. The hard one to deal with is the nvidia driver, because I'm bound to it, but it's impossible to trace the source code, and I know most kernel hackers wish they could do so. I wish I could help to make the nvidia driver more stable, or adjustable to patches, but I can't. The file system corruption you reported is "only" a side effect of the crash. Here is the nvidia driver version I currently use: NVRM version: NVIDIA NVdriver Kernel Module 1.0-2960 Tue May 14 07:41:42 PDT 2002 GCC version: gcc version 2.95.3 20010315 (SuSE) Best Regards, Jörg From owner-linux-xfs@oss.sgi.com Sun Sep 8 13:06:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Sep 2002 13:06:57 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g88K6ntG009107 for ; Sun, 8 Sep 2002 13:06:50 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-26.quicknet.nl [212.58.163.26]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g88KAniX065196; Sun, 8 Sep 2002 22:10:49 +0200 (CEST) Message-Id: <4.3.2.7.2.20020908220418.03797d20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Sep 2002 22:09:31 +0200 To: Axel Thimm , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS & NVIDIA Bug? Cc: linux-bugs@nvidia.com, =?iso-8859-1?Q?J=F6rg?= Prante In-Reply-To: <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 22:50 7-9-2002 +0200, Axel Thimm wrote: >If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get a >kernel BUG at filemap.c:236 in The kernel developers can't help you when using the nVIDIA driver for the obvious reasons also mentioned on lkml. (closed source, direct access to system resources). AFAIK the vmware modules are much of the same. Sorry! Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Sep 9 07:40:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Sep 2002 07:40:47 -0700 (PDT) Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g89EedtG008345 for ; Mon, 9 Sep 2002 07:40:40 -0700 Received: from rebel.net.au (dialup-4.rebel.net.au [203.20.69.74]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA08669 for ; Tue, 10 Sep 2002 00:38:14 +0930 Message-ID: <3D7CB6CC.9D464863@rebel.net.au> Date: Tue, 10 Sep 2002 00:27:16 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Technical Documentation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Ok, I reckon I might be able to start this off; my aim would be to create documentation similar to that contained in O'Reilly's book "Understanding the Linux Kernel" with perhaps a little more detail. It is possible that I may approach O'Reilly with the aim of including the material into their book with the provision that the material remains licenced to the XFS team to develop and amend. But I am jumping ahead of myself. DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Tue Sep 10 01:04:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 01:04:37 -0700 (PDT) Received: from MailUser (tamqfl1-ar8-4-46-216-017.tamqfl1.dsl-verizon.net [4.46.216.17]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8A84VtG022973 for ; Tue, 10 Sep 2002 01:04:31 -0700 Message-Id: <200209100804.g8A84VtG022973@oss.sgi.com> Reply-To: cranfordlines.claimscenter@verizon.net From: "Steve Kelly" To: "" Subject: What happened with your forms processing idea? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Sep 2002 03:54:46 -0400 X-archive-position: 316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Cranfordlines.claimscenter@verizon.net Precedence: bulk X-list: linux-xfs We are struggling with the decisions related to wether or not to go ahead with our plans to purchase an OCR and forms scanning solution. An outside consultant mentioned that he had heard that not to long ago you folks were considering implementing OCR technology to reduce data entry costs and improve efficiency. If you could let us know if you did move forward with any plans in that direction it would be of great help to us. May I ask what initialy prompted you to consider OCR? Did you decide it could help your compamy? What software did you go with? Would you recomend we take a look at it? At present we are still planning to continue our research until we decide which OCR system best suits our needs, then implement it quickly. If you are just starting to consider this technology feel free to stay in touch. We will let you know what we decide on and if it works for us. If you cannot advise on this please forward this E-mail to the proper individual in your company who might be able to help with this. Thanks, Steve From owner-linux-xfs@oss.sgi.com Tue Sep 10 06:53:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 06:54:01 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ADrqtG007468 for ; Tue, 10 Sep 2002 06:53:55 -0700 Received: (qmail 26708 invoked by uid 1010); 10 Sep 2002 13:58:20 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.147.29]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 13:58:20 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id 1CA43132EC for ; Tue, 10 Sep 2002 15:58:17 +0200 (CEST) Date: Tue, 10 Sep 2002 15:58:14 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <527280437.20020910155814@huno.net> To: linux-xfs@oss.sgi.com Subject: raid1 (u)mount error MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs hello, i've got a RAID1 running that seems to not umount itself properly. so when i try to mount the system after a reboot i see: md: raid1 personality registered as nr 3 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. ... md: md0: raid array is not clean -- starting background reconstruction ... raid1: raid set md0 not clean; reconstructing mirrors ... md: syncing RAID array md0 ... XFS mounting filesystem md(9,0) XFS: failed to locate log tail XFS: log mount/recovery failed XFS: log mount failed now i don't have /dev/md0 in fstab just to be sure that it doesn't try to mount itself before the raid array is started. but it doesn't matter. whatever i try the only thing that helps is xfs_repair -L /dev/md0, after that it mounts without any problems. stock 2.4.19 kernel with xfs patch applied, compiled with gcc3.1.1 - anyone got a clue what is going on? thx thomas From owner-linux-xfs@oss.sgi.com Tue Sep 10 08:27:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 08:27:49 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AFRgtG015988 for ; Tue, 10 Sep 2002 08:27:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA66115 for ; Tue, 10 Sep 2002 10:32:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA07113 for ; Tue, 10 Sep 2002 10:32:06 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AFTlG00913; Tue, 10 Sep 2002 10:29:47 -0500 Message-Id: <200209101529.g8AFTlG00913@jen.americas.sgi.com> Date: Tue, 10 Sep 2002 10:29:47 -0500 Subject: TAKE - merge up to 2.5.34 To: linux-xfs@oss.sgi.com X-archive-position: 318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Getting to be almost a noop now, just remove a list_t use from xfs Date: Tue Sep 10 08:28:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127018a linux/include/asm-i386/max_numnodes.h - 1.1 linux/arch/i386/mm/discontig.c - 1.1 linux/arch/i386/kernel/numaq.c - 1.1 linux/include/asm-alpha/kmap_types.h - 1.1 linux/include/asm-i386/mmzone.h - 1.1 linux/include/asm-i386/numaq.h - 1.1 linux/include/linux/rmap-locking.h - 1.1 linux/net/x25/x25_in.c - 1.10 linux/net/socket.c - 1.41 linux/net/packet/af_packet.c - 1.34 linux/net/ipx/Makefile - 1.8 linux/net/ipv6/af_inet6.c - 1.25 linux/net/ipv4/tcp_output.c - 1.32 linux/net/ipv4/tcp_input.c - 1.40 linux/net/ipv4/igmp.c - 1.18 linux/net/ipv4/af_inet.c - 1.39 linux/net/core/sock.c - 1.27 linux/net/core/dst.c - 1.10 linux/net/802/Makefile - 1.10 linux/mm/vmscan.c - 1.110 linux/mm/page_alloc.c - 1.89 linux/mm/memory.c - 1.90 linux/mm/filemap.c - 1.132 linux/kernel/sysctl.c - 1.56 linux/kernel/softirq.c - 1.28 linux/kernel/signal.c - 1.39 linux/kernel/sched.c - 1.80 linux/kernel/ksyms.c - 1.162 linux/kernel/fork.c - 1.68 linux/kernel/exit.c - 1.52 linux/init/main.c - 1.89 linux/include/net/tcp.h - 1.35 linux/include/net/sock.h - 1.33 linux/include/net/inet_common.h - 1.5 linux/include/linux/sysctl.h - 1.60 linux/include/linux/sched.h - 1.81 linux/include/linux/ptrace.h - 1.4 linux/include/linux/pci.h - 1.63 linux/include/linux/mm.h - 1.98 linux/include/linux/list.h - 1.18 linux/include/linux/igmp.h - 1.7 linux/include/linux/genhd.h - 1.23 linux/include/linux/fs.h - 1.189 linux/include/linux/blkdev.h - 1.66 linux/include/asm-sparc64/hardirq.h - 1.17 linux/include/asm-sparc/hardirq.h - 1.14 linux/include/asm-ppc/semaphore.h - 1.9 linux/include/asm-ppc/pci-bridge.h - 1.10 linux/include/asm-ppc/io.h - 1.18 linux/include/asm-ppc/hardirq.h - 1.20 linux/include/asm-ppc/elf.h - 1.12 linux/include/asm-i386/spinlock.h - 1.27 linux/include/asm-i386/pgtable.h - 1.37 linux/include/asm-i386/page.h - 1.29 linux/include/asm-i386/io.h - 1.28 linux/include/asm-alpha/user.h - 1.3 linux/include/asm-alpha/pgtable.h - 1.36 linux/include/asm-alpha/ide.h - 1.11 linux/include/asm-alpha/floppy.h - 1.6 linux/include/asm-alpha/dma.h - 1.6 linux/include/asm-alpha/core_t2.h - 1.9 linux/fs/sysv/dir.c - 1.17 linux/fs/namei.c - 1.60 linux/fs/minix/dir.c - 1.14 linux/fs/locks.c - 1.31 linux/fs/lockd/svc.c - 1.19 linux/fs/lockd/clntlock.c - 1.12 linux/fs/file_table.c - 1.22 linux/fs/fcntl.c - 1.24 linux/fs/fat/inode.c - 1.47 linux/fs/ext2/dir.c - 1.24 linux/fs/exec.c - 1.63 linux/fs/buffer.c - 1.132 linux/fs/block_dev.c - 1.57 linux/fs/binfmt_elf.c - 1.46 linux/fs/affs/file.c - 1.30 linux/fs/Makefile - 1.68 linux/drivers/video/Makefile - 1.44 linux/drivers/scsi/sym53c8xx.c - 1.34 linux/drivers/scsi/st.c - 1.51 linux/drivers/scsi/sr_vendor.c - 1.13 linux/drivers/scsi/sr_ioctl.c - 1.26 linux/drivers/scsi/sr.h - 1.9 linux/drivers/scsi/sr.c - 1.50 linux/drivers/scsi/sd.h - 1.8 linux/drivers/scsi/sd.c - 1.68 linux/drivers/scsi/scsi_error.c - 1.29 linux/drivers/scsi/qlogicfc.h - 1.11 linux/drivers/scsi/qlogicfc.c - 1.30 linux/drivers/pci/quirks.c - 1.30 linux/drivers/isdn/sc/timer.c - 1.6 linux/drivers/isdn/sc/shmem.c - 1.4 linux/drivers/isdn/sc/packet.c - 1.5 linux/drivers/isdn/sc/message.c - 1.6 linux/drivers/isdn/sc/ioctl.c - 1.7 linux/drivers/isdn/sc/interrupt.c - 1.6 linux/drivers/isdn/sc/event.c - 1.4 linux/drivers/isdn/sc/command.c - 1.7 linux/drivers/isdn/pcbit/drv.c - 1.14 linux/drivers/isdn/hisax/teles3.c - 1.15 linux/drivers/isdn/hisax/teles0.c - 1.13 linux/drivers/isdn/hisax/teleint.c - 1.12 linux/drivers/isdn/hisax/tei.c - 1.11 linux/drivers/isdn/hisax/sportster.c - 1.12 linux/drivers/isdn/hisax/sedlbauer.c - 1.19 linux/drivers/isdn/hisax/q931.c - 1.7 linux/drivers/isdn/hisax/niccy.c - 1.17 linux/drivers/isdn/hisax/netjet.c - 1.21 linux/drivers/isdn/hisax/mic.c - 1.11 linux/drivers/isdn/hisax/lmgr.c - 1.7 linux/drivers/isdn/hisax/l3dss1.c - 1.15 linux/drivers/isdn/hisax/l3_1tr6.c - 1.11 linux/drivers/isdn/hisax/ix1_micro.c - 1.12 linux/drivers/isdn/hisax/isdnl3.c - 1.15 linux/drivers/isdn/hisax/isdnl2.c - 1.14 linux/drivers/isdn/hisax/isdnl1.c - 1.16 linux/drivers/isdn/hisax/isac.c - 1.13 linux/drivers/isdn/hisax/hscx.c - 1.12 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.15 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.15 linux/drivers/isdn/hisax/fsm.c - 1.12 linux/drivers/isdn/hisax/elsa.c - 1.20 linux/drivers/isdn/hisax/diva.c - 1.16 linux/drivers/isdn/hisax/callc.c - 1.18 linux/drivers/isdn/hisax/avm_a1.c - 1.12 linux/drivers/isdn/hisax/asuscom.c - 1.15 linux/drivers/isdn/hisax/arcofi.c - 1.11 linux/drivers/isdn/hisax/amd7930.c - 1.12 linux/drivers/isdn/act2000/capi.c - 1.7 linux/drivers/isdn/act2000/act2000_isa.c - 1.9 linux/drivers/char/tty_io.c - 1.50 linux/drivers/char/ftape/lowlevel/Makefile - 1.5 linux/drivers/char/Makefile - 1.71 linux/drivers/cdrom/sbpcd.h - 1.5 linux/drivers/cdrom/sbpcd.c - 1.27 linux/drivers/cdrom/mcdx.c - 1.18 linux/drivers/cdrom/cdu31a.c - 1.20 linux/drivers/cdrom/cdrom.c - 1.45 linux/drivers/block/xd.c - 1.43 linux/drivers/block/rd.c - 1.57 linux/drivers/block/ps2esdi.c - 1.45 linux/drivers/block/paride/pd.c - 1.35 linux/drivers/block/paride/pcd.c - 1.23 linux/drivers/block/loop.c - 1.64 linux/drivers/block/ll_rw_blk.c - 1.111 linux/drivers/block/genhd.c - 1.32 linux/drivers/block/floppy.c - 1.47 linux/drivers/block/acsi.c - 1.36 linux/drivers/block/Makefile - 1.28 linux/drivers/acorn/block/mfmhd.c - 1.29 linux/arch/sparc64/mm/init.c - 1.48 linux/arch/sparc64/lib/VIScsum.S - 1.6 linux/arch/sparc64/kernel/process.c - 1.40 linux/arch/sparc64/kernel/ioctl32.c - 1.56 linux/arch/sparc64/defconfig - 1.74 linux/arch/sparc/mm/sun4c.c - 1.36 linux/arch/sparc/mm/srmmu.c - 1.36 linux/arch/sparc/mm/fault.c - 1.21 linux/arch/sparc/kernel/process.c - 1.30 linux/arch/sparc/kernel/pcic.c - 1.22 linux/arch/ppc/mm/fault.c - 1.22 linux/arch/ppc/kernel/smp.c - 1.43 linux/arch/ppc/kernel/setup.c - 1.49 linux/arch/ppc/kernel/process.c - 1.41 linux/arch/ppc/kernel/ppc_ksyms.c - 1.49 linux/arch/ppc/kernel/ppc_htab.c - 1.19 linux/arch/ppc/kernel/pci.c - 1.28 linux/arch/ppc/kernel/indirect_pci.c - 1.8 linux/arch/ppc/kernel/Makefile - 1.30 linux/arch/ppc/amiga/config.c - 1.19 linux/arch/ppc/amiga/Makefile - 1.8 linux/arch/ppc/8xx_io/uart.c - 1.21 linux/arch/m68k/sun3x/Makefile - 1.5 linux/arch/m68k/hp300/Makefile - 1.4 linux/arch/i386/vmlinux.lds - 1.19 linux/arch/i386/mm/init.c - 1.41 linux/arch/i386/mm/Makefile - 1.8 linux/arch/i386/kernel/setup.c - 1.82 linux/arch/i386/kernel/irq.c - 1.47 linux/arch/i386/kernel/init_task.c - 1.10 linux/arch/i386/kernel/Makefile - 1.34 linux/arch/i386/config.in - 1.88 linux/arch/i386/Makefile - 1.30 linux/arch/arm/mm/init.c - 1.32 linux/arch/alpha/kernel/traps.c - 1.22 linux/arch/alpha/kernel/time.c - 1.23 linux/arch/alpha/kernel/sys_sable.c - 1.10 linux/arch/alpha/kernel/sys_rx164.c - 1.10 linux/arch/alpha/kernel/sys_alcor.c - 1.11 linux/arch/alpha/kernel/smp.c - 1.38 linux/arch/alpha/kernel/proto.h - 1.19 linux/arch/alpha/kernel/process.c - 1.28 linux/arch/alpha/kernel/irq.c - 1.24 linux/arch/alpha/kernel/core_tsunami.c - 1.21 linux/arch/alpha/kernel/core_t2.c - 1.13 linux/arch/alpha/kernel/core_polaris.c - 1.13 linux/arch/alpha/kernel/core_mcpcia.c - 1.19 linux/arch/alpha/kernel/core_lca.c - 1.14 linux/arch/alpha/kernel/core_cia.c - 1.25 linux/arch/alpha/kernel/core_apecs.c - 1.14 linux/arch/alpha/Makefile - 1.18 linux/Makefile - 1.215 linux/MAINTAINERS - 1.116 linux/include/linux/ide.h - 1.61 linux/drivers/isdn/hisax/telespci.c - 1.12 linux/drivers/isdn/hisax/s0box.c - 1.9 linux/drivers/isdn/hisax/isar.c - 1.18 linux/drivers/isdn/hisax/avm_pci.c - 1.15 linux/drivers/isdn/hisax/avm_a1p.c - 1.9 linux/drivers/isdn/eicon/eicon_idi.c - 1.15 linux/drivers/block/blkpg.c - 1.27 linux/arch/ppc/xmon/start.c - 1.20 linux/arch/i386/vmlinux.lds.S - 1.6 linux/drivers/block/cpqarray.c - 1.54 linux/kernel/ptrace.c - 1.25 linux/include/asm-i386/setup.h - 1.3 linux/include/linux/threads.h - 1.5 linux/drivers/net/ppp_generic.c - 1.30 linux/fs/partitions/check.c - 1.50 linux/fs/partitions/Makefile - 1.11 linux/drivers/isdn/hisax/saphir.c - 1.10 linux/drivers/isdn/hisax/jade.c - 1.10 linux/drivers/isdn/hisax/isurf.c - 1.12 linux/drivers/isdn/hisax/hfcscard.c - 1.10 linux/drivers/isdn/hisax/hfc_pci.c - 1.24 linux/drivers/isdn/hisax/gazel.c - 1.14 linux/drivers/isdn/hisax/bkm_a8.c - 1.13 linux/drivers/isdn/hisax/bkm_a4t.c - 1.13 linux/drivers/isdn/divert/divert_procfs.c - 1.20 linux/arch/alpha/kernel/pci_impl.h - 1.11 linux/arch/alpha/kernel/pci.c - 1.22 linux/drivers/block/DAC960.h - 1.18 linux/drivers/block/DAC960.c - 1.53 linux/arch/sparc64/kernel/pci_sabre.c - 1.31 linux/arch/sparc64/kernel/pci_psycho.c - 1.29 linux/arch/sh/mm/init.c - 1.20 linux/include/asm-i386/pci.h - 1.19 linux/drivers/pcmcia/Makefile - 1.19 linux/include/linux/pci_ids.h - 1.72 linux/mm/highmem.c - 1.42 linux/mm/bootmem.c - 1.22 linux/include/linux/highmem.h - 1.25 linux/include/linux/bootmem.h - 1.9 linux/include/asm-i386/highmem.h - 1.13 linux/drivers/isdn/hisax/w6692.c - 1.13 linux/include/asm-ppc/pgalloc.h - 1.12 linux/include/asm-i386/pgalloc.h - 1.22 linux/arch/alpha/kernel/core_irongate.c - 1.12 linux/mm/numa.c - 1.12 linux/include/linux/mmzone.h - 1.25 linux/drivers/char/agp/agp.h - 1.27 linux/drivers/i2c/Makefile - 1.7 linux/drivers/pci/setup-res.c - 1.11 linux/arch/ppc/kernel/galaxy_pci.c - 1.5 linux/arch/ia64/config.in - 1.35 linux/arch/alpha/kernel/pci_iommu.c - 1.19 linux/include/linux/raid/md.h - 1.18 linux/drivers/net/8139too.c - 1.42 linux/drivers/isdn/hisax/hfc_sx.c - 1.13 linux/drivers/isdn/hysdn/hysdn_net.c - 1.10 linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.15 linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.14 linux/include/asm-mips64/pgtable.h - 1.14 linux/include/asm-mips64/mmzone.h - 1.8 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.10 linux/net/econet/af_econet.c - 1.13 linux/drivers/ide/ide.c - 1.64 linux/drivers/ide/ide-probe.c - 1.35 linux/drivers/ide/ide-geometry.c - 1.16 linux/drivers/ide/ide-floppy.c - 1.34 linux/drivers/ide/ide-disk.c - 1.46 linux/drivers/ide/ide-cd.c - 1.46 linux/drivers/ide/hd.c - 1.28 linux/drivers/ide/Makefile - 1.27 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.13 linux/net/ipv4/netfilter/ipchains_core.c - 1.12 linux/net/ipv4/netfilter/Makefile - 1.17 linux/fs/ramfs/inode.c - 1.29 linux/arch/ppc/8260_io/uart.c - 1.12 linux/drivers/s390/block/dasd.c - 1.28 linux/fs/xfs/xfs_dmapi.c - 1.84 linux/drivers/usb/storage/usb.c - 1.27 linux/arch/alpha/kernel/core_titan.c - 1.6 linux/arch/alpha/kernel/core_wildfire.c - 1.3 linux/include/asm-arm/memory.h - 1.6 linux/fs/jffs/inode-v23.c - 1.31 linux/drivers/mtd/ftl.c - 1.22 linux/drivers/net/tun.c - 1.16 linux/net/ipv4/tcp_minisocks.c - 1.15 linux/include/asm-sparc/highmem.h - 1.6 linux/drivers/usb/storage/sddr09.c - 1.17 linux/drivers/isdn/hisax/nj_u.c - 1.10 linux/drivers/isdn/hisax/nj_s.c - 1.11 linux/drivers/isdn/hisax/l3ni1.c - 1.8 linux/drivers/isdn/hisax/icc.c - 1.7 linux/drivers/isdn/eicon/linchr.c - 1.7 linux/drivers/block/cciss.c - 1.41 linux/drivers/block/cciss.h - 1.13 linux/drivers/md/md.c - 1.53 linux/fs/dnotify.c - 1.6 linux/include/asm-ppc/highmem.h - 1.9 linux/arch/i386/kernel/dmi_scan.c - 1.20 linux/fs/reiserfs/stree.c - 1.27 linux/fs/reiserfs/super.c - 1.28 linux/fs/reiserfs/tail_conversion.c - 1.18 linux/fs/reiserfs/resize.c - 1.8 linux/fs/reiserfs/namei.c - 1.26 linux/arch/sparc64/kernel/pci_schizo.c - 1.16 linux/fs/reiserfs/journal.c - 1.33 linux/fs/reiserfs/inode.c - 1.34 linux/fs/reiserfs/hashes.c - 1.4 linux/fs/reiserfs/fix_node.c - 1.26 linux/include/linux/reiserfs_fs.h - 1.31 linux/include/linux/reiserfs_fs_i.h - 1.7 linux/include/linux/reiserfs_fs_sb.h - 1.15 linux/fs/reiserfs/bitmap.c - 1.19 linux/arch/cris/mm/init.c - 1.9 linux/net/wanrouter/af_wanpipe.c - 1.8 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.5 linux/include/linux/compiler.h - 1.6 linux/include/asm-alpha/mmzone.h - 1.3 linux/arch/alpha/mm/numa.c - 1.5 linux/drivers/mtd/nftlcore.c - 1.22 linux/drivers/acpi/Config.in - 1.7 linux/drivers/char/sonypi.h - 1.9 linux/arch/mips/au1000/common/Makefile - 1.4 linux/drivers/net/ns83820.c - 1.14 linux/fs/jffs2/background.c - 1.10 linux/fs/jffs2/file.c - 1.10 linux/drivers/mtd/devices/blkmtd.c - 1.13 linux/drivers/i2c/i2c-proc.c - 1.6 linux/drivers/message/i2o/i2o_block.c - 1.20 linux/drivers/message/i2o/Makefile - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.7 linux/fs/ext3/inode.c - 1.18 linux/fs/intermezzo/kml_utils.c - 1.2 linux/fs/reiserfs/procfs.c - 1.10 linux/fs/driverfs/inode.c - 1.20 linux/include/linux/device.h - 1.15 linux/init/do_mounts.c - 1.18 linux/include/linux/init_task.h - 1.11 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.4 linux/arch/i386/Config.help - 1.11 linux/drivers/pnp/pnpbios_core.c - 1.11 linux/arch/ppc/4xx_io/serial_sicc.c - 1.2 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.2 linux/arch/ppc/iSeries/LparData.c - 1.2 linux/arch/ppc/iSeries/rtc.c - 1.4 linux/arch/ppc/kernel/ppc4xx_serial.c - 1.2 linux/arch/ppc/platforms/apus_pci.c - 1.2 linux/arch/ppc/platforms/apus_setup.c - 1.5 linux/arch/ppc/platforms/chrp_pci.c - 1.2 linux/arch/ppc/platforms/gemini_pci.c - 1.2 linux/arch/ppc/platforms/pmac_pci.c - 1.3 linux/arch/ppc/platforms/proc_rtas.c - 1.2 linux/include/asm-ppc64/page.h - 1.6 linux/drivers/isdn/hisax/hisax_hfcpci.c - 1.3 linux/fs/jfs/jfs_metapage.h - 1.5 linux/drivers/hotplug/ibmphp_hpc.c - 1.4 linux/fs/jfs/file.c - 1.10 linux/fs/jfs/inode.c - 1.12 linux/fs/jfs/jfs_dtree.c - 1.7 linux/fs/jfs/jfs_extendfs.h - 1.3 linux/fs/jfs/jfs_extent.c - 1.4 linux/fs/jfs/jfs_incore.h - 1.9 linux/fs/jfs/jfs_imap.c - 1.7 linux/fs/jfs/namei.c - 1.11 linux/fs/jfs/jfs_logmgr.c - 1.15 linux/fs/jfs/super.c - 1.13 linux/fs/jfs/jfs_mount.c - 1.9 linux/fs/jfs/jfs_superblock.h - 1.4 linux/fs/jfs/jfs_txnmgr.c - 1.14 linux/fs/jfs/jfs_umount.c - 1.5 linux/fs/jfs/jfs_metapage.c - 1.10 linux/kernel/futex.c - 1.7 linux/include/asm-i386/tlbflush.h - 1.3 linux/include/asm-generic/percpu.h - 1.3 linux/mm/pdflush.c - 1.5 linux/drivers/isdn/i4l/isdn_ppp.c - 1.6 linux/drivers/block/umem.c - 1.7 linux/arch/i386/pci/fixup.c - 1.3 linux/drivers/pci/probe.c - 1.5 linux/include/linux/page-flags.h - 1.7 linux/kernel/suspend.c - 1.10 linux/drivers/char/hvc_console.c - 1.4 linux/drivers/isdn/hisax/amd7930_fn.c - 1.3 linux/drivers/isdn/hisax/enternow_pci.c - 1.2 linux/drivers/isdn/hisax/ipacx.c - 1.3 linux/drivers/s390/block/dasd_genhd.c - 1.5 linux/drivers/char/agp/agp.c - 1.2 linux/mm/rmap.c - 1.5 linux/include/asm-ppc64/mmzone.h - 1.3 linux/arch/i386/mm/pgtable.c - 1.2 linux/include/linux/preempt.h - 1.4 linux/drivers/base/fs/Makefile - 1.3 linux/fs/jfs/resize.c - 1.3 linux/fs/aio.c - 1.2 linux/fs/jfs/xattr.c - 1.2 linux/net/sctp/protocol.c - 1.2 linux/net/sctp/associola.c - 1.2 linux/net/sctp/bind_addr.c - 1.2 linux/net/sctp/endpointola.c - 1.2 linux/net/sctp/outqueue.c - 1.2 linux/net/sctp/sm_make_chunk.c - 1.2 linux/net/sctp/sm_sideeffect.c - 1.2 linux/net/sctp/sm_statefuns.c - 1.2 linux/include/net/sctp/structs.h - 1.2 linux/net/sctp/socket.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Sep 10 09:28:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 09:29:05 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AGSxtG018034 for ; Tue, 10 Sep 2002 09:28:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA66110 for ; Tue, 10 Sep 2002 11:33:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA21459 for ; Tue, 10 Sep 2002 11:33:22 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AGTTM21387; Tue, 10 Sep 2002 11:29:29 -0500 Message-Id: <200209101629.g8AGTTM21387@stout.americas.sgi.com> Date: Tue, 10 Sep 2002 11:29:29 -0500 Subject: TAKE - teach icmn_err about CE_WARN X-archive-position: 319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs XFS error messages have different levels, although in practice they almost all turn into just a printk. icmn_err() didn't know about CE_WARN though, and so it printed out a rather cryptic message that's probably not very helpful. Add CE_WARN to the cases so it just turns into a printk like the others. Also added CE_WARN to cmn_err for consistency, although this won't change behavior at all. teach icmn_err about CE_WARN Date: Tue Sep 10 09:30:10 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127029a linux/fs/xfs/support/debug.c - 1.9 From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:18:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:18:17 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIICtG021268 for ; Tue, 10 Sep 2002 11:18:12 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id BEC701D9F5F; Tue, 10 Sep 2002 11:22:41 -0700 (PDT) Date: Tue, 10 Sep 2002 11:22:41 -0700 From: Chris Wedgwood To: thomas Cc: linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910182241.GA5230@tapu.f00f.org> References: <527280437.20020910155814@huno.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527280437.20020910155814@huno.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 03:58:14PM +0200, thomas wrote: > i've got a RAID1 running that seems to not umount itself properly. so > when i try to mount the system after a reboot i see: > now i don't have /dev/md0 in fstab just to be sure that it > doesn't try to mount itself before the raid array is > started. but it doesn't matter. whatever i try the only thing > that helps is xfs_repair -L /dev/md0, after that it mounts > without any problems. Is this / on raid1? If so, I also see this... I put some stack dump stuff in to verify that /dev/md0 get opened *twice* as / is mounted, once I assume for the auto-raid stuff (or something?) and then again to mount / The raid1 code won't switch to RO in there is more than one reference and thus it's never able to be mounted cleanly. Sorry this doesn't provide a solution, I was tracking this down under time pressure and had to fix the problem using another means. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:26:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:26:22 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIQGtG021931 for ; Tue, 10 Sep 2002 11:26:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA67249; Tue, 10 Sep 2002 13:30:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA16097; Tue, 10 Sep 2002 13:30:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AISHn09474; Tue, 10 Sep 2002 13:28:17 -0500 Subject: Re: raid1 (u)mount error From: Steve Lord To: Chris Wedgwood Cc: thomas , linux-xfs@oss.sgi.com In-Reply-To: <20020910182241.GA5230@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 13:28:17 -0500 Message-Id: <1031682497.22845.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-10 at 13:22, Chris Wedgwood wrote: > On Tue, Sep 10, 2002 at 03:58:14PM +0200, thomas wrote: > > > i've got a RAID1 running that seems to not umount itself properly. so > > when i try to mount the system after a reboot i see: > > > now i don't have /dev/md0 in fstab just to be sure that it > > doesn't try to mount itself before the raid array is > > started. but it doesn't matter. whatever i try the only thing > > that helps is xfs_repair -L /dev/md0, after that it mounts > > without any problems. > > Is this / on raid1? > > If so, I also see this... I put some stack dump stuff in to verify > that /dev/md0 get opened *twice* as / is mounted, once I assume for > the auto-raid stuff (or something?) and then again to mount / > > The raid1 code won't switch to RO in there is more than one reference > and thus it's never able to be mounted cleanly. > > Sorry this doesn't provide a solution, I was tracking this down under > time pressure and had to fix the problem using another means. > Are you doing this with current cvs code? The xfs log used to effectively open the device again. I think this has been reworked in the current code to avoid the double open. I have not checked into this, so I might be wrong. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:37:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:38:09 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIbwtG022774 for ; Tue, 10 Sep 2002 11:37:58 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 15AA51D9F6F; Tue, 10 Sep 2002 11:42:28 -0700 (PDT) Date: Tue, 10 Sep 2002 11:42:28 -0700 From: Chris Wedgwood To: Steve Lord Cc: thomas , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910184228.GA5323@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031682497.22845.97.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 01:28:17PM -0500, Steve Lord wrote: > Are you doing this with current cvs code? I saw this about two weeks ago, whatever was current then. From the call path, XFS was only responsible for the second open though, might this still be the problem? > The xfs log used to effectively open the device again. I think this > has been reworked in the current code to avoid the double open. > I have not checked into this, so I might be wrong. I can, if you like, retest fairly easily with the head of the tree. Note, I'm talking about 2.4.x here in both messages. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:45:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:45:46 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIjitG023390 for ; Tue, 10 Sep 2002 11:45:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA68106; Tue, 10 Sep 2002 13:50:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA04689; Tue, 10 Sep 2002 13:50:08 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AIlmW09510; Tue, 10 Sep 2002 13:47:48 -0500 Subject: Re: raid1 (u)mount error From: Steve Lord To: Chris Wedgwood Cc: thomas , linux-xfs@oss.sgi.com In-Reply-To: <20020910184228.GA5323@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 13:47:48 -0500 Message-Id: <1031683668.22845.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-10 at 13:42, Chris Wedgwood wrote: > On Tue, Sep 10, 2002 at 01:28:17PM -0500, Steve Lord wrote: > > > Are you doing this with current cvs code? > > I saw this about two weeks ago, whatever was current then. Hmm, the code I am thinking of went on August 16th, so probably you already had it. > > >From the call path, XFS was only responsible for the second open > though, might this still be the problem? So one open for the raid resync, and one for the mount - both of those are outside XFS's control. The attempt to replay the log by making the filesystem writable in the middle of this operation is probably what gets thrown here. We remount read/write, run recovery, then remount readonly again, finally user space does its own remount read/write. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:52:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:52:55 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIqrtG024049 for ; Tue, 10 Sep 2002 11:52:53 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 56180ED2C0; Tue, 10 Sep 2002 11:57:23 -0700 (PDT) Date: Tue, 10 Sep 2002 11:57:23 -0700 From: Chris Wedgwood To: Steve Lord Cc: thomas , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910185723.GA5375@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031683668.22845.102.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 01:47:48PM -0500, Steve Lord wrote: > Hmm, the code I am thinking of went on August 16th, so probably you > already had it. Yes, I'm pretty sure I would have. I will check though. > So one open for the raid resync, and one for the mount - both of > those are outside XFS's control. Yes. It seems for any other FS other than / you can remount the raid-superblock RO with "ref == 1" as the reference that is open is the process calling the ioctl to remount RO. For / fs, you always have a second reference and this screws you. I'm actually not sure how / is supposed to work on RAID so perhaps I have this wrong. > The attempt to replay the log by making the filesystem writable in > the middle of this operation is probably what gets thrown here. We > remount read/write, run recovery, then remount readonly again, > finally user space does its own remount read/write. Possibly, but this should get released again making XFS no different than any other fs... so I'm not sure XFS is to blame. I will try to get call-chains from *all* calls to the open on /dev/md0 and see what falls out. I should probably also get release information too :) --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:10:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:10:49 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJAktG024906 for ; Tue, 10 Sep 2002 12:10:46 -0700 Received: (qmail 22337 invoked by uid 500); 10 Sep 2002 19:14:34 -0000 Subject: What does this message actually mean? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031685274.21941.2.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 10 Sep 2002 14:14:34 -0500 X-archive-position: 325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs xfs_alloc_read_agf: error in AG 51 bad agf_magicnum 0x0 Bad version number 0x0 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:15:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:15:58 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJFstG025462 for ; Tue, 10 Sep 2002 12:15:54 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id DDE5C1D9F5F; Tue, 10 Sep 2002 12:20:23 -0700 (PDT) Date: Tue, 10 Sep 2002 12:20:23 -0700 From: Chris Wedgwood To: thomas Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910192023.GA5470@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1298234671.20020910211407@huno.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 09:14:07PM +0200, thomas wrote: > nope / is reiserfs. and this is /dev/md0 for you? or something else? if this is the device with umount errors, then I'm pretty sure we can't blame XFS :) > i am a bit confused now though cause i'm not completely sure if two > threads didn't get mixed together here :) so do you suggest steve to > get current cvs for the fix you put in august 16th? the changed to cvs by sandeclaws on the 16th will only affect XFS, so unless this is the fs with has umount problems, it won't affect you --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:17:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:17:56 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJHrtG025957 for ; Tue, 10 Sep 2002 12:17:53 -0700 Received: (qmail 5485 invoked by uid 1010); 10 Sep 2002 19:14:12 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.153.65]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 19:14:12 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id DADD3134C6; Tue, 10 Sep 2002 21:14:09 +0200 (CEST) Date: Tue, 10 Sep 2002 21:14:07 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <1298234671.20020910211407@huno.net> To: Chris Wedgwood , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error In-Reply-To: <20020910185723.GA5375@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs > Is this / on raid1? nope / is reiserfs. i am a bit confused now though cause i'm not completely sure if two threads didn't get mixed together here :) so do you suggest steve to get current cvs for the fix you put in august 16th? thomas From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:22:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:22:16 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJMEtG026512 for ; Tue, 10 Sep 2002 12:22:14 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA66365; Tue, 10 Sep 2002 14:26:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA30117; Tue, 10 Sep 2002 14:26:38 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AJOIk09568; Tue, 10 Sep 2002 14:24:18 -0500 Subject: Re: What does this message actually mean? From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031685274.21941.2.camel@UberGeek.coremetrics.com> References: <1031685274.21941.2.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 14:24:17 -0500 Message-Id: <1031685857.22954.107.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-10 at 14:14, Austin Gonyou wrote: > xfs_alloc_read_agf: error in AG 51 > bad agf_magicnum 0x0 > Bad version number 0x0 It means you got zeros on the disk where there was supposed to be metadata. I would run xfs_check on the unmounted fs, and then run xfs_repair. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:39:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:39:37 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJdWtG027231 for ; Tue, 10 Sep 2002 12:39:32 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id E913D1D9F8F; Tue, 10 Sep 2002 12:44:01 -0700 (PDT) Date: Tue, 10 Sep 2002 12:44:01 -0700 From: Chris Wedgwood To: Steve Lord Cc: thomas , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910194401.GA9951@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031682497.22845.97.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 01:28:17PM -0500, Steve Lord wrote: > I have not checked into this, so I might be wrong. <7 reboots of a test machine later> Actually... turns out you are correct :) At least I think so ... post Aug15 test kernels work as expected, they do not prevent / on md XFS to fail as I saw earlier. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:52:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:52:36 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJqXtG027849 for ; Tue, 10 Sep 2002 12:52:33 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 70D8F1D9FBC; Tue, 10 Sep 2002 12:57:03 -0700 (PDT) Date: Tue, 10 Sep 2002 12:57:03 -0700 From: Chris Wedgwood To: thomas Cc: linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910195703.GA9987@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> <20020910192023.GA5470@tapu.f00f.org> <1019359078.20020910213251@huno.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1019359078.20020910213251@huno.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 09:32:51PM +0200, thomas wrote: > +[~]: df -Th > Filesystem Type Size Used Avail Use% Mounted on > /dev/hda1 reiserfs 2.2G 430M 1.8G 20% / > /dev/hdc1 reiserfs 2.2G 1.6G 634M 72% /var > /dev/md0 xfs 75G 69G 5.9G 93% /data so what does umount /data raidstop /dev/md0 do? > now if there is a chance that cvs *might* help here i'm on my way to > grab it. can i patch cvs with 2.4.19 or do i have to get > 2.4.20-pre5? 2.4.20-pre5/6 won't help ... you want xfs from CVS post Aug 16. Are you able to give that a go? --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 13:17:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 13:17:48 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AKHhtG028830 for ; Tue, 10 Sep 2002 13:17:44 -0700 Received: (qmail 5836 invoked by uid 1010); 10 Sep 2002 20:22:12 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.147.22]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 20:22:12 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id F1C1A134F5; Tue, 10 Sep 2002 22:22:08 +0200 (CEST) Date: Tue, 10 Sep 2002 22:22:03 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <5112311328.20020910222203@huno.net> To: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error In-Reply-To: <20020910195703.GA9987@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> <20020910192023.GA5470@tapu.f00f.org> <1019359078.20020910213251@huno.net> <20020910195703.GA9987@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs while i was waiting for the responses i made a fresh 2.4.19-xfs with gcc2.95 just for kicks and guess what the error vanished. now the only difference between this kernel and the older one was the gcc version (3.1.1 vs 2.95.4) and the older one had some crazy CFLAGS, because i tried to optimize it for my VIA C3. i double checked and booted with the old kernel again and the error is back. i did this several times (new>old>new>old>new) just to be extra sure. false alarm, no xfs problem :) thomas From owner-linux-xfs@oss.sgi.com Tue Sep 10 13:23:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 13:23:12 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AKNAtG029393 for ; Tue, 10 Sep 2002 13:23:10 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA68639 for ; Tue, 10 Sep 2002 15:27:34 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA63815 for ; Tue, 10 Sep 2002 15:27:34 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AKNdB29305; Tue, 10 Sep 2002 15:23:39 -0500 Message-Id: <200209102023.g8AKNdB29305@stout.americas.sgi.com> Date: Tue, 10 Sep 2002 15:23:39 -0500 Subject: TAKE - change symlink perms to 777 X-archive-position: 332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs XFS symlinks were behaving a little differently than every other filesystem on linux... we set perms as: mode = 0777 & ~current->fs->umask; which is how irix does it as well. but ext2/3/reiser etc all just set it to 777, so we'll do that too. change symlink perms to 777 Date: Tue Sep 10 13:21:58 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127049a linux/fs/xfs/linux/xfs_iops.c - 1.173 From owner-linux-xfs@oss.sgi.com Tue Sep 10 14:21:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 14:21:52 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ALLitG030886 for ; Tue, 10 Sep 2002 14:21:44 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 848F11DA025; Tue, 10 Sep 2002 14:26:14 -0700 (PDT) Date: Tue, 10 Sep 2002 14:26:14 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020910212614.GA10273@tapu.f00f.org> References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <200209102023.g8AKNdB29305@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > XFS symlinks were behaving a little differently than every other > filesystem on linux... we set perms as: > mode = 0777 & ~current->fs->umask; > which is how irix does it as well. > but ext2/3/reiser etc all just set it to 777, so we'll do that too. > change symlink perms to 777 ... to fix those already on your fs --cw P.S. Don't bitch, just send patches. --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=GNUmakefile # GNUmakefile for sl-frob # # $Id: GNUmakefile,v 1.1 2002/09/10 21:23:27 cw Exp $ CFLAGS+="-Wall" all: strip sl-frob: sl-frob.o strip: sl-frob strip sl-frob clean: rm -f *~ *.o sl-frob rcsclean --R3G7APHDIzY6R/pk Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="sl-frob.c" /* * sl-frob.c * * 'stat' and recreate symlink is the perms are not 0777 as they * should be. This may be required if symlink permissions for all * hosed or messed up (for example, early versions of XFS would create * symlinks as non-0777 as it obeyed the umask). * * Usage is something like: * * find /path/to/fs -mount -type l -not -perm 777 -print0 | xargs -0 /path/to/sl-frob * * $Id: sl-frob.c,v 1.1 2002/09/10 21:19:37 cw Exp $ */ #include #include #include #include #include #include int main(int ac, char **av) { int i; struct stat st; char lpath[4096]; int nchar; if (ac < 2) { fprintf(stderr, "%s: filename \n\trecreate symlinks with busted perms\n", av[0]); return 1; } /* old versions of XFS will obey the umask */ umask(0); for (i=1; i '%s' (%s)\n", av[i], lpath, strerror(errno)); fprintf(stderr, "\tTHIS IS BAD --- MANUALLY FIX THIS\n"); continue; } } } return 0; } --R3G7APHDIzY6R/pk-- From owner-linux-xfs@oss.sgi.com Tue Sep 10 15:56:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 15:56:28 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AMuMtG004213 for ; Tue, 10 Sep 2002 15:56:22 -0700 Received: (qmail 22774 invoked by uid 500); 10 Sep 2002 23:00:21 -0000 Subject: Re: What does this message actually mean? From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031685857.22954.107.camel@jen.americas.sgi.com> References: <1031685857.22954.107.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031698821.21946.15.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 10 Sep 2002 18:00:21 -0500 X-archive-position: 334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs It appears that we're all good after running the xfs_repair. Everything seemed to be working ok otherwise, so I didn't know why this error would be there. Either way..it looks happy now.:) On Tue, 2002-09-10 at 14:24, Steve Lord wrote: > On Tue, 2002-09-10 at 14:14, Austin Gonyou wrote: > > xfs_alloc_read_agf: error in AG 51 > > bad agf_magicnum 0x0 > > Bad version number 0x0 > > It means you got zeros on the disk where there was supposed to be > metadata. I would run xfs_check on the unmounted fs, and then run > xfs_repair. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 11 00:13:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 00:14:06 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8B7DxtG032603 for ; Wed, 11 Sep 2002 00:13:59 -0700 Received: from erbenson.alaska.net (6-pm29.nwc.alaska.net [209.112.158.6]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8B7IQBs039973 for ; Tue, 10 Sep 2002 23:18:27 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 6B0363A0F for ; Tue, 10 Sep 2002 23:18:25 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id BF3CC4104E2; Tue, 10 Sep 2002 23:18:24 -0800 (AKDT) Date: Tue, 10 Sep 2002 23:18:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020911071824.GG714@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f5QefDQHtn8hx44O" Content-Disposition: inline In-Reply-To: <20020910212614.GA10273@tapu.f00f.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --f5QefDQHtn8hx44O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: >=20 > > XFS symlinks were behaving a little differently than every other > > filesystem on linux... we set perms as: >=20 > > mode =3D 0777 & ~current->fs->umask; >=20 > > which is how irix does it as well. >=20 > > but ext2/3/reiser etc all just set it to 777, so we'll do that too. >=20 > > change symlink perms to 777 >=20 > ... to fix those already on your fs why? symlink permissions are completly irrelevant. bsd also sets symlink perms according to umask, i actually prefer that since world writable files throw a red flag in my mind when inspecting permission.=20 i think if one were to set a standard uniform permission on symlinks it should be 444 or 555, symlinks by thier nature are readonly, the only way to alter them is unlink() and re symlink() so why pretend. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --f5QefDQHtn8hx44O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1+7kAACgkQJKx7GixEevyOHQCfTIeQVuTZf7VD3h/YrDTY2Brf M2UAnRr5YLsTPwHQe7Ect6mxANbBQ+/2 =0VJu -----END PGP SIGNATURE----- --f5QefDQHtn8hx44O-- From owner-linux-xfs@oss.sgi.com Wed Sep 11 05:19:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 05:19:09 -0700 (PDT) Received: from fruit.eu.org (qmailr@d5111f5b.cable.wanadoo.nl [213.17.31.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BCJ1tG013698 for ; Wed, 11 Sep 2002 05:19:02 -0700 Received: (qmail 25463 invoked by uid 500); 11 Sep 2002 12:23:32 -0000 Date: Wed, 11 Sep 2002 14:23:32 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020911122332.GD17696@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020911071824.GG714@plato.local.lan> User-Agent: Mutt/1.4i X-oi: oi X-archive-position: 336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-10 23:18:24-0800, Ethan Benson wrote: > On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > > > mode = 0777 & ~current->fs->umask; > why? symlink permissions are completly irrelevant. They are not. Consider a sticky directory. > i think if one were to set a standard uniform permission on symlinks > it should be 444 or 555, symlinks by thier nature are readonly, the > only way to alter them is unlink() and re symlink() so why pretend. That's a change that needs to be at the VFS level. For now it would just look bad for XFS to differ in behaviour. Kind regards, -- Wessel Dankers The static electricity routing is acting up... From owner-linux-xfs@oss.sgi.com Wed Sep 11 06:38:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 06:38:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BDcftG016326 for ; Wed, 11 Sep 2002 06:38:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA75089; Wed, 11 Sep 2002 08:43:05 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA87801; Wed, 11 Sep 2002 08:43:04 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA10993; Wed, 11 Sep 2002 08:43:04 -0500 (CDT) Message-Id: <200209111343.IAA10993@fsgi158.americas.sgi.com> Subject: Re: TAKE - change symlink perms to 777 To: wsl@fruit.eu.org (Wessel Dankers) Date: Wed, 11 Sep 2002 08:43:03 -0500 (CDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020911122332.GD17696@fruit.eu.org> from "Wessel Dankers" at Sep 11, 2002 02:23:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tbd@sgi.com Precedence: bulk X-list: linux-xfs > > On 2002-09-10 23:18:24-0800, Ethan Benson wrote: > > On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > > > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > > > > mode = 0777 & ~current->fs->umask; > > > why? symlink permissions are completly irrelevant. > > They are not. Consider a sticky directory. > > > i think if one were to set a standard uniform permission on symlinks > > it should be 444 or 555, symlinks by thier nature are readonly, the > > only way to alter them is unlink() and re symlink() so why pretend. > > That's a change that needs to be at the VFS level. For now it would just > look bad for XFS to differ in behaviour. > This was discussed internally at SGI some time ago in PV 831071. At that time nobody could find any POSIX or other standard mandating that symlink perms be set to 777. Furthermore, at the time xfsrestore relied on the symlink perms being set using the umask. I don't know if this is still the case. Tad From owner-linux-xfs@oss.sgi.com Wed Sep 11 07:14:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 07:14:44 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BEEftG019159 for ; Wed, 11 Sep 2002 07:14:42 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA75171; Wed, 11 Sep 2002 09:19:08 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA31213; Wed, 11 Sep 2002 09:19:08 -0500 (CDT) Subject: Re: TAKE - change symlink perms to 777 From: Eric Sandeen To: Tad Dolphay Cc: Wessel Dankers , linux-xfs@oss.sgi.com In-Reply-To: <200209111343.IAA10993@fsgi158.americas.sgi.com> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Sep 2002 09:15:06 -0500 Message-Id: <1031753707.9726.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Ok, it sounds like there's enough going on here that I'll revert the mod for now, until I'm sure there are no other implications. (Nathan had some concerns about acls as well...) -Eric On Wed, 2002-09-11 at 08:43, Tad Dolphay wrote: > This was discussed internally at SGI some time ago in PV 831071. At that time > nobody could find any POSIX or other standard mandating that symlink > perms be set to 777. Furthermore, at the time xfsrestore relied on > the symlink perms being set using the umask. I don't know if this is > still the case. > > Tad > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 11 07:25:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 07:25:54 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BEPjtG019762 for ; Wed, 11 Sep 2002 07:25:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA75269 for ; Wed, 11 Sep 2002 09:30:13 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA28271 for ; Wed, 11 Sep 2002 09:30:13 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8BEQBp10144; Wed, 11 Sep 2002 09:26:11 -0500 Message-Id: <200209111426.g8BEQBp10144@stout.americas.sgi.com> Date: Wed, 11 Sep 2002 09:26:11 -0500 Subject: TAKE - Back out that symlink/777 change for now X-archive-position: 339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Need to make sure that xfsdump, acls, dmapi, nathan, dean, ethan, linus, and al are happy, first. ;-) Date: Wed Sep 11 07:29:13 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean Undoes mod: 2.4.x-xfs:slinx:127049a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127120a linux/fs/xfs/linux/xfs_iops.c - 1.174 From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:12:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:12:20 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BICFtG026735 for ; Wed, 11 Sep 2002 11:12:16 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA12593; Wed, 11 Sep 2002 20:16:45 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pC1y-0003qV-00; Wed, 11 Sep 2002 20:16:02 +0200 Date: Wed, 11 Sep 2002 20:16:02 +0200 From: Christian Guggenberger To: linux-kernel@vger.kernel.org Cc: andrea@suse.de, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911201602.A13655@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 24 X-archive-position: 340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Hi! just tried out 2.4.20-pre5aa2 with xfs enabled as module. But I can't load the xfs Module... modprobe xfs just won't work. Via top on another console I see two modpobe processes, each consuming 99.9% CPU time. Then, after a minute or so, the machine reboots... System is a Dell Precision with 2 Intel Xeons@2.2GHz and 2GB RDRAM and hyper-threading enabled, OS is Debian/GNU Linux 3.0 with: gcc-2.95.4 20011002 (Debian prerelease) ld-2.12.90.0.1 20020307 Debian/GNU Linux I tried to disable HT, but then it was even worse. Then my machine crashed hard after starting "modprobe xfs". thanks in advance Christian P.S. if needed, I could post my .config, or other relevant things... From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:20:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:20:18 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIKGtG027285 for ; Wed, 11 Sep 2002 11:20:16 -0700 Received: (qmail 25103 invoked by uid 500); 11 Sep 2002 18:24:15 -0000 Subject: Re: 2.4.20pre5aa2 From: Austin Gonyou To: Christian Guggenberger Cc: linux-kernel@vger.kernel.org, andrea@suse.de, linux-xfs@oss.sgi.com In-Reply-To: <20020911201602.A13655@pc9391.uni-regensburg.de> References: <20020911201602.A13655@pc9391.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031768655.24629.23.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 11 Sep 2002 13:24:15 -0500 X-archive-position: 341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Did you try just using insmod, instead of modprobe. To use modprobe, your module must have something defined in /etc/modules.conf On Wed, 2002-09-11 at 13:16, Christian Guggenberger wrote: > Hi! > > just tried out 2.4.20-pre5aa2 with xfs enabled as module. But I can't > load > the xfs Module... > modprobe xfs just won't work. Via top on another console I see two > modpobe > processes, each consuming 99.9% CPU time. Then, after a minute or so, > the > machine reboots... > > System is a Dell Precision with 2 Intel Xeons@2.2GHz and 2GB RDRAM and > hyper-threading enabled, OS is Debian/GNU Linux 3.0 with: > > gcc-2.95.4 20011002 (Debian prerelease) > ld-2.12.90.0.1 20020307 Debian/GNU Linux > > > I tried to disable HT, but then it was even worse. Then my machine > crashed > hard after starting "modprobe xfs". > > > thanks in advance > Christian > > P.S. if needed, I could post my .config, or other relevant things... > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:24:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:24:19 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIOFtG027799 for ; Wed, 11 Sep 2002 11:24:16 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA13154; Wed, 11 Sep 2002 20:28:44 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pCDZ-0003x0-00; Wed, 11 Sep 2002 20:28:01 +0200 Date: Wed, 11 Sep 2002 20:28:01 +0200 From: Christian Guggenberger To: Austin Gonyou Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911202801.C13655@pc9391.uni-regensburg.de> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1031768655.24629.23.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Mit, Sep 11, 2002 at 20:24:15 +0200 X-Mailer: Balsa 1.2.4 Lines: 9 X-archive-position: 342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Am 11 Sep 2002 20:24:15 schrieb(en) Austin Gonyou: > Did you try just using insmod, instead of modprobe. To use modprobe, > your module must have something defined in /etc/modules.conf > > yep, I tried this before, but causes the same bad result... Christian From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:31:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:31:25 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIVJtG028331 for ; Wed, 11 Sep 2002 11:31:19 -0700 Received: from fwd07.sul.t-online.de by mailout10.sul.t-online.com with smtp id 17pCL8-00059d-02; Wed, 11 Sep 2002 20:35:51 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.254.84]) by fmrl07.sul.t-online.com with esmtp id 17pCKz-14tYfYC; Wed, 11 Sep 2002 20:35:41 +0200 Date: Wed, 11 Sep 2002 20:35:32 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com, Chris Wedgwood , Andy Ritger , Austin Gonyou , Knut J Bjuland , joerg@infolinux.de, Seth Mos Cc: linux-bugs@nvidia.com Subject: Re: XFS & NVIDIA Bug? Message-ID: <20020911203532.A17044@bonzo.nirvana> References: <200209081305.52636.joergprante@netcologne.de> <20020907225041.A10340@bonzo.nirvana> <3D7AEB85.9F2FBA65@online.no> <20020907225041.A10340@bonzo.nirvana> <1031452601.22717.12.camel@UberGeek.coremetrics.com> <20020907220352.GA2594@tapu.f00f.org> <20020907225041.A10340@bonzo.nirvana> <20020907220352.GA2594@tapu.f00f.org> <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020907225041.A10340@bonzo.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Sat, Sep 07, 2002 at 10:50:41PM +0200 X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 10:50:41PM +0200, Axel Thimm wrote: > I am using Jörg Prante's kernel patch set 2.4.19-jp14 from > http://infolinux.de/jp/, which includes among others > > o XFS for 2.4.19 > o rmap-13b after some further tests to narrow the possible causes down, the non-working combination seem to be XFS & NVIDIA & rmap-13b Upgrading to rmap-13c fixed the kernel Oops. Credits go to Knut J Bjuland for pointing out to me a race condition in rmap-13b. Why only that particular combination triggered that bug escapes me. And it only hit applications like vmware or Samba (nmbd). Thanks to all people for a lot of helpful remarks! > o O1-Scheduler > o low-latency patches > o preempt-kernel P.S. Jörg Prante's kernel patch set with this fix applied (rmap-13c) is really impressive concerning performance. > If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get a > kernel BUG at filemap.c:236 in > > Trace; c012cc26 > Trace; c012ccee > Trace; c01b2de3 > Trace; c01c95e6 > Trace; c01d6399 > Trace; c0155efd > Trace; c013bb09 > Trace; c013bddc > Trace; c014e76f > Trace; c0108a3b > (the whole Oops is attached.) > > This happens reproducably with VMware, but also with Samba (nmbd), which is > pure userland. It causes severe filesystem corruption. > > Using the XFree86 nv driver keeps the system stable (and the NVIDIA card > useless). Using 2.4.18-4SGI_XFS_1.1 (with the root access fix applied) and the > NVIDIA module also works. > > The XFS FAQ mentions that any NVIDIA driver later than 1.0-1251 would fit. Do > maybe the newest NVIDIA modules break XFS again? -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:36:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:36:17 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIa9tG028866 for ; Wed, 11 Sep 2002 11:36:11 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id VAA12495; Wed, 11 Sep 2002 21:12:54 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8BIfeoq006056; Wed, 11 Sep 2002 20:41:40 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8BIfG8Q031734; Wed, 11 Sep 2002 20:41:16 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8BIfB27031733; Wed, 11 Sep 2002 20:41:11 +0200 Date: Wed, 11 Sep 2002 20:41:11 +0200 From: Andrea Arcangeli To: Austin Gonyou Cc: Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911184111.GY17868@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031768655.24629.23.camel@UberGeek.coremetrics.com> User-Agent: Mutt/1.3.27i X-archive-position: 344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs was a collision between new xfs and new scheduler, you can use this fix in the meantime: --- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 2002 +++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 @@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( spin_unlock_irq(¤t->sigmask_lock); /* Migrate to the right CPU */ - current->cpus_allowed = 1UL << cpu; - while (smp_processor_id() != cpu) - schedule(); + set_cpus_allowed(current, 1UL << cpu); + if (cpu() != cpu) + BUG(); sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); also remeber to apply the O_DIRECT fixes for reiserfs and ext3 (that were left over after merging the new nfs stuff). all will be fixed in next -aa of course. --- 2.4.19pre3aa1/fs/reiserfs/inode.c.~1~ Tue Mar 12 00:07:18 2002 +++ 2.4.19pre3aa1/fs/reiserfs/inode.c Tue Mar 12 01:24:21 2002 @@ -2161,10 +2161,11 @@ } } -static int reiserfs_direct_io(int rw, struct inode *inode, +static int reiserfs_direct_io(int rw, struct file * filp, struct kiobuf *iobuf, unsigned long blocknr, int blocksize) { + struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; return generic_direct_IO(rw, inode, iobuf, blocknr, blocksize, reiserfs_get_block_direct_io) ; } --- 2.4.20pre5aa2/fs/ext3/inode.c.~1~ Mon Sep 9 02:38:08 2002 +++ 2.4.20pre5aa2/fs/ext3/inode.c Tue Sep 10 05:22:18 2002 @@ -1385,9 +1385,10 @@ static int ext3_releasepage(struct page } static int -ext3_direct_IO(int rw, struct inode *inode, struct kiobuf *iobuf, +ext3_direct_IO(int rw, struct file * filp, struct kiobuf *iobuf, unsigned long blocknr, int blocksize) { + struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; struct ext3_inode_info *ei = EXT3_I(inode); handle_t *handle = NULL; int ret; Andrea From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:41:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:41:06 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIertG029425 for ; Wed, 11 Sep 2002 11:41:01 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17pCTn-0001rI-00; Wed, 11 Sep 2002 19:44:47 +0100 Date: Wed, 11 Sep 2002 19:44:47 +0100 From: Christoph Hellwig To: Christian Guggenberger Cc: linux-kernel@vger.kernel.org, andrea@suse.de, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911194447.A7073@infradead.org> Mail-Followup-To: Christoph Hellwig , Christian Guggenberger , linux-kernel@vger.kernel.org, andrea@suse.de, linux-xfs@oss.sgi.com References: <20020911201602.A13655@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020911201602.A13655@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Wed, Sep 11, 2002 at 08:16:02PM +0200 X-archive-position: 345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Sep 11, 2002 at 08:16:02PM +0200, Christian Guggenberger wrote: > Hi! > > just tried out 2.4.20-pre5aa2 with xfs enabled as module. But I can't load > the xfs Module... > modprobe xfs just won't work. Via top on another console I see two modpobe > processes, each consuming 99.9% CPU time. Then, after a minute or so, the > machine reboots... > > System is a Dell Precision with 2 Intel Xeons@2.2GHz and 2GB RDRAM and > hyper-threading enabled, OS is Debian/GNU Linux 3.0 with: > > gcc-2.95.4 20011002 (Debian prerelease) > ld-2.12.90.0.1 20020307 Debian/GNU Linux > > > I tried to disable HT, but then it was even worse. Then my machine crashed > hard after starting "modprobe xfs". Could you please try the following patch from Andrea? --- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 2002 +++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 @@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( spin_unlock_irq(¤t->sigmask_lock); /* Migrate to the right CPU */ - current->cpus_allowed = 1UL << cpu; - while (smp_processor_id() != cpu) - schedule(); + set_cpus_allowed(current, 1UL << cpu); + if (cpu() != cpu) + BUG(); sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:41:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:41:17 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIfDtG029501 for ; Wed, 11 Sep 2002 11:41:14 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA14141; Wed, 11 Sep 2002 20:45:42 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pCU0-00046E-00; Wed, 11 Sep 2002 20:45:00 +0200 Date: Wed, 11 Sep 2002 20:45:00 +0200 From: Christian Guggenberger To: Austin Gonyou Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911204500.E13655@pc9391.uni-regensburg.de> References: <20020911202801.C13655@pc9391.uni-regensburg.de> <1031769317.24629.28.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1031769317.24629.28.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Mit, Sep 11, 2002 at 20:35:18 +0200 X-Mailer: Balsa 1.2.4 Lines: 18 X-archive-position: 346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Am 11 Sep 2002 20:35:18 schrieb(en) Austin Gonyou: > Ahh..I see now. So, before the machine reboots, what do you get in > dmesg? > > Anything, an oops maybe? maybe do dmesg > ~/somefile so you can keep > them around after the reboot? > > Have to correct my first statement. The Machine crashes in both cases, HT enabled or not... But I didn't find any Output in dmesg. I'll now try Andrea's patches... thank you :) Christian From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:47:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:47:31 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIlTtG030507 for ; Wed, 11 Sep 2002 11:47:29 -0700 Received: (qmail 25307 invoked by uid 500); 11 Sep 2002 18:51:35 -0000 Subject: Re: 2.4.20pre5aa2 From: Austin Gonyou To: Christian Guggenberger Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <20020911204500.E13655@pc9391.uni-regensburg.de> References: <20020911204500.E13655@pc9391.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031770294.24635.31.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 11 Sep 2002 13:51:35 -0500 X-archive-position: 347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs NP. Glad he was listening! As always!! :-D On Wed, 2002-09-11 at 13:45, Christian Guggenberger wrote: > Am 11 Sep 2002 20:35:18 schrieb(en) Austin Gonyou: > > Ahh..I see now. So, before the machine reboots, what do you get in > > dmesg? > > > > Anything, an oops maybe? maybe do dmesg > ~/somefile so you can keep > > them around after the reboot? > > > > > > Have to correct my first statement. The Machine crashes in both cases, > HT > enabled or not... > But I didn't find any Output in dmesg. > > I'll now try Andrea's patches... > > thank you :) > Christian -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:58:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:58:40 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIwctG031179 for ; Wed, 11 Sep 2002 11:58:38 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA68278; Wed, 11 Sep 2002 14:03:00 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA87429; Wed, 11 Sep 2002 14:03:00 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8BIwuh13580; Wed, 11 Sep 2002 13:58:56 -0500 Message-Id: <200209111858.g8BIwuh13580@stout.americas.sgi.com> Date: Wed, 11 Sep 2002 13:58:56 -0500 Subject: TAKE - add error checks to linvfs_direct_IO X-archive-position: 348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This one is from Mike Ovsiannikov : "Looks like that linvfs_direct_IO() doesn't always checks return status. Below is my attempt to fix that." (Mike pointed out a couple other things, still looking at that) add error checks to linvfs_direct_IO Date: Wed Sep 11 11:55:11 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127147a linux/fs/xfs/linux/xfs_aops.c - 1.4 From owner-linux-xfs@oss.sgi.com Wed Sep 11 12:07:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 12:07:21 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BJ7FtG031788 for ; Wed, 11 Sep 2002 12:07:16 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id VAA15690; Wed, 11 Sep 2002 21:11:48 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pCtG-0004Pj-00; Wed, 11 Sep 2002 21:11:06 +0200 Date: Wed, 11 Sep 2002 21:11:06 +0200 From: Christian Guggenberger To: Andrea Arcangeli Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, hch@infradead.org Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911211106.G13655@pc9391.uni-regensburg.de> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <20020911194447.A7073@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20020911194447.A7073@infradead.org>; from hch@infradead.org on Mit, Sep 11, 2002 at 20:44:47 +0200 X-Mailer: Balsa 1.2.4 Lines: 31 X-archive-position: 349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Am 11 Sep 2002 20:44:47 schrieb(en) Christoph Hellwig: > Could you please try the following patch from Andrea? > > --- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 > 05:17:46 2002 > +++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 > 2002 > @@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( > spin_unlock_irq(¤t->sigmask_lock); > > /* Migrate to the right CPU */ > - current->cpus_allowed = 1UL << cpu; > - while (smp_processor_id() != cpu) > - schedule(); > + set_cpus_allowed(current, 1UL << cpu); > + if (cpu() != cpu) > + BUG(); > > sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); > INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); > > andrea, I applied your patch to page_buf.c (but not the ext3/reiserfs stuff, because there's no need for me) and now everything seems to work fine! thank you! Christian ge From owner-linux-xfs@oss.sgi.com Wed Sep 11 12:33:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 12:33:33 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BJXStG000545 for ; Wed, 11 Sep 2002 12:33:28 -0700 Received: from erbenson.alaska.net (2-pm33.nwc.alaska.net [209.112.159.2]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8BJc1Bs030830 for ; Wed, 11 Sep 2002 11:38:01 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id E03433A0C for ; Wed, 11 Sep 2002 11:37:59 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id DBFB64104E2; Wed, 11 Sep 2002 11:37:59 -0800 (AKDT) Date: Wed, 11 Sep 2002 11:37:59 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020911193759.GJ714@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mFHiwr52TKrxpkjc" Content-Disposition: inline In-Reply-To: <20020911122332.GD17696@fruit.eu.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --mFHiwr52TKrxpkjc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2002 at 02:23:32PM +0200, Wessel Dankers wrote: > On 2002-09-10 23:18:24-0800, Ethan Benson wrote: > > On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > > > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > > > > mode =3D 0777 & ~current->fs->umask; >=20 > > why? symlink permissions are completly irrelevant. >=20 > They are not. Consider a sticky directory. what are you talking about? they are still irrelevant. > > i think if one were to set a standard uniform permission on symlinks > > it should be 444 or 555, symlinks by thier nature are readonly, the > > only way to alter them is unlink() and re symlink() so why pretend. >=20 > That's a change that needs to be at the VFS level. For now it would just > look bad for XFS to differ in behaviour. i don't believe so since the behavior is irrelevant. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --mFHiwr52TKrxpkjc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1/m5cACgkQJKx7GixEevzLEACggHhtq5hUEYMCFdp+tT+GgR0C j5QAn2GwxiFcj5OxN3F+jpDUC4DJueqw =oPk5 -----END PGP SIGNATURE----- --mFHiwr52TKrxpkjc-- From owner-linux-xfs@oss.sgi.com Wed Sep 11 12:54:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 12:54:43 -0700 (PDT) Received: from imf08bis.bellsouth.net (mail108.mail.bellsouth.net [205.152.58.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BJsctG001591 for ; Wed, 11 Sep 2002 12:54:39 -0700 Received: from TAZ2 ([66.156.3.51]) by imf08bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2>; Wed, 11 Sep 2002 16:00:46 -0400 Date: Wed, 11 Sep 2002 15:57:31 -0400 From: Greg Freemyer Subject: re: TAKE - add error checks to linvfs_direct_IO To: Eric Sandeen cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8BJsdtG001593 X-archive-position: 351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> This one is from Mike Ovsiannikov : Does that mean that Altavista.com (also av.com) is using xfs to host their search engine? I don't remember seeing that on your list of high profile users. Greg ===== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 11 13:09:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 13:09:05 -0700 (PDT) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BK92tG004851 for ; Wed, 11 Sep 2002 13:09:02 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA36424 for ; Wed, 11 Sep 2002 15:13:31 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 17pDre-0001bq-00 for ; Wed, 11 Sep 2002 15:13:30 -0500 Date: Wed, 11 Sep 2002 15:13:30 -0500 From: Nathan Straz To: xfs mailing list Subject: Re: TAKE - add error checks to linvfs_direct_IO Message-ID: <20020911201330.GC26927@sgi.com> Mail-Followup-To: xfs mailing list References: <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2> User-Agent: Mutt/1.4i X-archive-position: 352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Sep 11, 2002 at 03:57:31PM -0400, Greg Freemyer wrote: > >> This one is from Mike Ovsiannikov : > > Does that mean that Altavista.com (also av.com) is using xfs to host > their search engine? No it means that Mike, who as an email address at av.com, sent in a patch that we decided to apply. That's it. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:14:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:14:30 -0700 (PDT) Received: from homer.coredp.com (homer.coredp.com [216.94.116.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLENtG006795 for ; Wed, 11 Sep 2002 14:14:23 -0700 Received: from crepe.coredp.com (pop.coredp.com [216.94.116.214]) by homer.coredp.com (8.9.1/8.9.1) with ESMTP id RAA11211 for ; Wed, 11 Sep 2002 17:33:28 -0400 (EDT) Received: from coredp.com (localhost [127.0.0.1]) by crepe.coredp.com (SGI-8.9.3/8.9.3) with ESMTP id RAA80569 for ; Wed, 11 Sep 2002 17:33:28 -0400 (EDT) Message-ID: <3D7FB6A7.91B4A592@coredp.com> Date: Wed, 11 Sep 2002 17:33:27 -0400 From: Andrew Ho Organization: C.O.R.E. Digital Pictures Inc. X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: symbolic link Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrew@coredp.com Precedence: bulk X-list: linux-xfs Hello, In my system (redhat 7.2), if I boot the computer up to 2.4.9-13SGI_XFS_1.0.2smp kernel, even the directory is symbolic linked for 5 times from one mounted drive to another mounted drive, the files are visible in this symbolic linked directory. With the kernel which are 2.4.17, 2.4.18, the error message was "Too many levels of symbolic links". Even 2.4.19 with linux/fs/xfs/linux/xfs_iops.c - 1.173 update, I receive the same error message. The i-node number of this directory is 3003418. 2.4.9-13SGI_XFS_1.0.2smp : ls -i Test # Test is a symbolic linked directory 30038418 Test ls Test check.sh libglx.txt MP3 2.4.19-xfs : ls -i Test # Test is a symbolic linked directory 30038418 Test ls Test Test: Too many levels of symbolic links -- ..................................................................... Andrew Ho email: andrew@coredp.com c.o.r.e. digital pictures http://www.coredp.com ..................................................................... From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:23:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:23:30 -0700 (PDT) Received: from muriel.parsec.at (muriel.parsec.at [80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLNPtG007276 for ; Wed, 11 Sep 2002 14:23:26 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g8BLRt501965; Wed, 11 Sep 2002 23:27:55 +0200 Date: Wed, 11 Sep 2002 23:27:55 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Leo Qiu cc: , Subject: Re: [Acl-Devel] maximum ACL entries for getfacl In-Reply-To: <20020911194121.55934.qmail@web20903.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ag@bestbits.at Precedence: bulk X-list: linux-xfs On Wed, 11 Sep 2002, Leo Qiu wrote: > Hi, > > I am running libacl on Linux XFS. I found that I could > not have more than 16 ACL entries for one file. After > a little investigation, it seems to me that I can > actually set more than 16 ACL entries on a file, but I > can not get them. I am wondering why there is such a > limit for ACL. That was an XFS bug, and has been fixed a while ago. Your workaround is correct, though. The XFS guys will likely still recommend you to upgrade to a more recent version, because of other fixes. With XFS you will currently get no more than 25 ACL entries; with ext2/ext3 the limit is set to 32. This has so far been enough for everybody; if you seem to need bigger ACLs, please verify that you can't use groups instead. Regards, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:44:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:44:15 -0700 (PDT) Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLi9tG007868 for ; Wed, 11 Sep 2002 14:44:10 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8BLmeIs021985; Wed, 11 Sep 2002 23:48:40 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8BLmeg02219; Wed, 11 Sep 2002 23:48:40 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 11 Sep 2002 23:48:40 +0200 (CEST) From: Seth Mos To: Andrew Ho cc: linux-xfs@oss.sgi.com Subject: Re: symbolic link In-Reply-To: <3D7FB6A7.91B4A592@coredp.com> Message-ID: <20020911234620.W2111-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Wed, 11 Sep 2002, Andrew Ho wrote: > Hello, > > In my system (redhat 7.2), if I boot the computer up to > 2.4.9-13SGI_XFS_1.0.2smp kernel, even the directory is > symbolic linked for 5 times from one mounted drive to another > mounted drive, the files are visible in this symbolic linked > directory. > > With the kernel which are 2.4.17, 2.4.18, the error message > was "Too many levels of symbolic links". Even 2.4.19 with > linux/fs/xfs/linux/xfs_iops.c - 1.173 update, I receive the > same error message. AFAIK that behaviour was "fixed" in the mainline kernel and thus XFS automatically follows that behaviour. They originally created this to make sure you can not loop through symlinks endlessly. I think that searching for patches about this on lkml might show you how to change this limit. I do not know the current limit for recursive symlinks. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:48:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:48:54 -0700 (PDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLmntG008507 for ; Wed, 11 Sep 2002 14:48:49 -0700 Received: from user-11fa2a4.dsl.mindspring.com ([66.245.9.68] helo=[192.168.2.24]) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17pFQE-0001wh-00; Wed, 11 Sep 2002 17:53:18 -0400 Subject: Re: [Acl-Devel] maximum ACL entries for getfacl From: John M Trostel To: Andreas Gruenbacher Cc: Leo Qiu , Acl-List , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Sep 2002 17:52:08 -0400 Message-Id: <1031781129.2163.6.camel@jtsdell> Mime-Version: 1.0 X-archive-position: 356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: john.trostel@quantum.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-11 at 17:27, Andreas Gruenbacher wrote: > On Wed, 11 Sep 2002, Leo Qiu wrote: > > > Hi, > > > > I am running libacl on Linux XFS. I found that I could > > not have more than 16 ACL entries for one file. After > > a little investigation, it seems to me that I can > > actually set more than 16 ACL entries on a file, but I > > can not get them. I am wondering why there is such a > > limit for ACL. > > That was an XFS bug, and has been fixed a while ago. Your workaround is > correct, though. The XFS guys will likely still recommend you to upgrade > to a more recent version, because of other fixes. > > With XFS you will currently get no more than 25 ACL entries; with > ext2/ext3 the limit is set to 32. This has so far been enough for > everybody; if you seem to need bigger ACLs, please verify that you can't > use groups instead. > > > Regards, > Andreas. With the newer treatment of ACLs in XFS, the number can be increased beyond 25. I have a working setup using a 128 ACE limit. Let me know if you need that patch. (Although as Andreas says, people really ought to use groups instead at that point.) -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Thu Sep 12 02:21:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 02:21:56 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8C9LotG027933 for ; Thu, 12 Sep 2002 02:21:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA90563 for ; Thu, 12 Sep 2002 04:26:21 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA20550 for ; Thu, 12 Sep 2002 04:26:20 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CGfSq01525 for linux-xfs@oss.sgi.com; Thu, 12 Sep 2002 12:41:28 -0400 Resent-Message-Id: <200209121641.g8CGfSq01525@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA86126 for ; Thu, 12 Sep 2002 04:25:50 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CGews01515 for hch@sgi.com; Thu, 12 Sep 2002 12:40:58 -0400 Date: Thu, 12 Sep 2002 12:40:58 -0400 From: Christoph Hellwig Message-Id: <200209121640.g8CGews01515@dhcp212.munich.sgi.com> Subject: TAKE - Make generic_file_write changes more similar to 2.5 Resent-Date: Thu, 12 Sep 2002 12:41:28 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 12 02:24:18 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127219a linux/mm/filemap.c - 1.114 linux/kernel/ksyms.c - 1.136 linux/include/linux/fs.h - 1.158 - Backport the 2.5 version of generic_file_write_nolock and drop the XFS-specific do_generic_file_write. linux/fs/xfs/linux/xfs_lrw.c - 1.167 - Use generic_file_write_nolock instead of do_generic_file_write From owner-linux-xfs@oss.sgi.com Thu Sep 12 02:53:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 02:53:19 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8C9rFtG028600 for ; Thu, 12 Sep 2002 02:53:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA89019 for ; Thu, 12 Sep 2002 04:57:46 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA56237 for ; Thu, 12 Sep 2002 04:57:45 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CHCrw02817 for linux-xfs@oss.sgi.com; Thu, 12 Sep 2002 13:12:53 -0400 Resent-Message-Id: <200209121712.g8CHCrw02817@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA76212 for ; Thu, 12 Sep 2002 04:57:10 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CHCHk02807 for hch@sgi.com; Thu, 12 Sep 2002 13:12:17 -0400 Date: Thu, 12 Sep 2002 13:12:17 -0400 From: Christoph Hellwig Message-Id: <200209121712.g8CHCHk02807@dhcp212.munich.sgi.com> Subject: TAKE - Fix migration of pagebuf I/O completion threads with the O(1) scheduler Resent-Date: Thu, 12 Sep 2002 13:12:53 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Fix from Andrea Arcangeli to not lockup the machine when XFS is combined with the O(1) scheduler patch. I had to add some ugly #ifdef magic to detect that case. Date: Thu Sep 12 02:54:15 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127220a linux/fs/xfs/pagebuf/page_buf.c - 1.58 - Fix migration of pagebuf I/O completion threads with the O(1) scheduler From owner-linux-xfs@oss.sgi.com Thu Sep 12 08:22:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 08:22:45 -0700 (PDT) Received: from muriel.parsec.at (muriel.parsec.at [80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CFMbtG006784 for ; Thu, 12 Sep 2002 08:22:39 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g8CFQwt22014; Thu, 12 Sep 2002 17:26:59 +0200 Date: Thu, 12 Sep 2002 17:26:58 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: John M Trostel cc: Acl-List , Subject: Re: [Acl-Devel] maximum ACL entries for getfacl In-Reply-To: <1031781129.2163.6.camel@jtsdell> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ag@bestbits.at Precedence: bulk X-list: linux-xfs Hi, On 11 Sep 2002, John M Trostel wrote: > On Wed, 2002-09-11 at 17:27, Andreas Gruenbacher wrote: > > With XFS you will currently get no more than 25 ACL entries; with > > ext2/ext3 the limit is set to 32. This has so far been enough for > > everybody; if you seem to need bigger ACLs, please verify that you can't > > use groups instead. > > > > Regards, > > Andreas. > > With the newer treatment of ACLs in XFS, the number can be increased > beyond 25. I have a working setup using a 128 ACE limit. Let me know > if you need that patch. (Although as Andreas says, people really ought > to use groups instead at that point.) Did you also make sure this doesn't break Irix XFS filesystems? --Andreas. From owner-linux-xfs@oss.sgi.com Thu Sep 12 10:20:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 10:20:30 -0700 (PDT) Received: from homer.coredp.com (homer.coredp.com [216.94.116.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CHKRtG009964 for ; Thu, 12 Sep 2002 10:20:28 -0700 Received: from crepe.coredp.com (pop.coredp.com [216.94.116.214]) by homer.coredp.com (8.9.1/8.9.1) with ESMTP id NAA11697; Thu, 12 Sep 2002 13:39:54 -0400 (EDT) Received: from coredp.com (localhost [127.0.0.1]) by crepe.coredp.com (SGI-8.9.3/8.9.3) with ESMTP id NAA00376; Thu, 12 Sep 2002 13:39:54 -0400 (EDT) Message-ID: <3D80D16A.E3D8E63C@coredp.com> Date: Thu, 12 Sep 2002 13:39:54 -0400 From: Andrew Ho Organization: C.O.R.E. Digital Pictures Inc. X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: symbolic link References: <20020911234620.W2111-100000@xs1.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrew@coredp.com Precedence: bulk X-list: linux-xfs Seth Mos wrote: > > On Wed, 11 Sep 2002, Andrew Ho wrote: > > > Hello, > > > > In my system (redhat 7.2), if I boot the computer up to > > 2.4.9-13SGI_XFS_1.0.2smp kernel, even the directory is > > symbolic linked for 5 times from one mounted drive to another > > mounted drive, the files are visible in this symbolic linked > > directory. > > > > With the kernel which are 2.4.17, 2.4.18, the error message > > was "Too many levels of symbolic links". Even 2.4.19 with > > linux/fs/xfs/linux/xfs_iops.c - 1.173 update, I receive the > > same error message. > > AFAIK that behaviour was "fixed" in the mainline kernel and thus XFS > automatically follows that behaviour. They originally created this to make > sure you can not loop through symlinks endlessly. > > I think that searching for patches about this on lkml might show you how > to change this limit. I do not know the current limit for recursive > symlinks. > It is not the problem of the limit. I use the same machine with different kernel as I mentioned. I believe that it is the problem of the kernel codes. Will it be the VFS, hard link problems, etc ... Thanks, -- ..................................................................... Andrew Ho email: andrew@coredp.com c.o.r.e. digital pictures http://www.coredp.com ..................................................................... From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:08:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:09:02 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CN8utG022354 for ; Thu, 12 Sep 2002 16:08:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 QAA08021 for ; Thu, 12 Sep 2002 16:13:31 -0700 (PDT) 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 JAA12509; Fri, 13 Sep 2002 09:12:13 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA33148; Fri, 13 Sep 2002 09:12:12 +1000 (AEDT) Date: Fri, 13 Sep 2002 09:12:11 +1000 From: Nathan Scott To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020913091211.B133147@wobbly.melbourne.sgi.com> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.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: <1031753707.9726.1.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Sep 11, 2002 at 09:15:06AM -0500 X-archive-position: 361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Sep 11, 2002 at 09:15:06AM -0500, Eric Sandeen wrote: > Ok, it sounds like there's enough going on here that I'll revert the mod > for now, until I'm sure there are no other implications. > > (Nathan had some concerns about acls as well...) Extended attributes, not ACLs. We may want to switch this behavior via a mount flag or something, to give either the IRIX or the Linux semantics (like we did for SGID) - we'll talk. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:23:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:23:11 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CNN1tG023500 for ; Thu, 12 Sep 2002 16:23:02 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8CNRYW25000; Thu, 12 Sep 2002 19:27:34 -0400 Message-ID: <3D81235B.6080809@rackable.com> Date: Thu, 12 Sep 2002 16:29:31 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Austin Gonyou , Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> Content-Type: multipart/mixed; boundary="------------030500010508020204010905" X-archive-position: 362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------030500010508020204010905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Your patch seem to solve only some of the xfs issues for me. Before the patch my system hung when booting. This only occured I had xfs compiled into the kernel. After patching things seemed fine, but durning "dbench 32" the system locked. Upon rebooting and attempting to mount the filesystem I got this: XFS mounting filesystem md(9,2) Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) kernel BUG at page_buf.c:578! PS- The results of ksymoops are attached. Andrea Arcangeli wrote: >was a collision between new xfs and new scheduler, you can use this fix >in the meantime: > >--- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 2002 >+++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 >@@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( > spin_unlock_irq(¤t->sigmask_lock); > > /* Migrate to the right CPU */ >- current->cpus_allowed = 1UL << cpu; >- while (smp_processor_id() != cpu) >- schedule(); >+ set_cpus_allowed(current, 1UL << cpu); >+ if (cpu() != cpu) >+ BUG(); > > sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); > INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); > >also remeber to apply the O_DIRECT fixes for reiserfs and ext3 (that >were left over after merging the new nfs stuff). all will be fixed in >next -aa of course. > >--- 2.4.19pre3aa1/fs/reiserfs/inode.c.~1~ Tue Mar 12 00:07:18 2002 >+++ 2.4.19pre3aa1/fs/reiserfs/inode.c Tue Mar 12 01:24:21 2002 >@@ -2161,10 +2161,11 @@ > } > } > >-static int reiserfs_direct_io(int rw, struct inode *inode, >+static int reiserfs_direct_io(int rw, struct file * filp, > struct kiobuf *iobuf, unsigned long blocknr, > int blocksize) > { >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > return generic_direct_IO(rw, inode, iobuf, blocknr, blocksize, > reiserfs_get_block_direct_io) ; > } >--- 2.4.20pre5aa2/fs/ext3/inode.c.~1~ Mon Sep 9 02:38:08 2002 >+++ 2.4.20pre5aa2/fs/ext3/inode.c Tue Sep 10 05:22:18 2002 >@@ -1385,9 +1385,10 @@ static int ext3_releasepage(struct page > } > > static int >-ext3_direct_IO(int rw, struct inode *inode, struct kiobuf *iobuf, >+ext3_direct_IO(int rw, struct file * filp, struct kiobuf *iobuf, > unsigned long blocknr, int blocksize) > { >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > struct ext3_inode_info *ei = EXT3_I(inode); > handle_t *handle = NULL; > int ret; > >Andrea >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > > --------------030500010508020204010905 Content-Type: text/plain; name="xfs.opps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs.opps" ksymoops 2.4.5 on i686 2.4.20-pre5aa2-fixed-xfs. Options used -V (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-pre5aa2-fixed-xfs/ (default) -m /boot/System.map-2.4.20-pre5aa2-fixed-xfs (default) kernel BUG at page_buf.c:578! invalid operand: 0000 2.4.20-pre5aa2-fixed-xfs #4 SMP Thu Sep 12 11:51:40 PDT 2002 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000001 ecx: 00000001 edx: 00000000 esi: c5e15a04 edi: c5e15980 ebp: 00000002 esp: c5c19a58 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 805, stackpage=c5c19000) Stack: c5c18000 00001000 00000000 00000001 00000000 00000005 000001f0 00000002 c5e15980 c5e15980 00002205 c5e20540 c02089c8 c5e15980 c5c117b4 00002205 13005f90 00000000 c5912d40 13005f90 00000000 c01f4d2d c5912d40 13005f90 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 42 02 95 ab 35 c0 0f b7 47 7c 81 4f 08 04 00 00 01 8d >>EIP; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== >>esi; c5e15a04 >>edi; c5e15980 >>esp; c5c19a58 <[ip_tables].data.end+116159/294761> Trace; c02089c8 Trace; c01f4d2d Trace; c01f45e1 Trace; c01f463a Trace; c01f58b2 Trace; c01f59f6 Trace; c01f5b5a Trace; c01f6744 Trace; c01f6c74 Trace; c01f6cc4 Trace; c01f6e45 Trace; c01efde7 Trace; c01f861c Trace; c01f776b Trace; c01f77b0 Trace; c01ff894 Trace; c01ff97b Trace; c0212ce6 Trace; c0148c81 Trace; c0148e9c Trace; c014dfb8 Trace; c015c145 Trace; c015c43b Trace; c015c29c Trace; c015c904 Trace; c0108d9b Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> 00000000 <_EIP>: Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== 0: 0f 0b ud2a <===== Code; c0208594 <_pagebuf_lookup_pages+2a4/2f0> 2: 42 inc %edx Code; c0208595 <_pagebuf_lookup_pages+2a5/2f0> 3: 02 95 ab 35 c0 0f add 0xfc035ab(%ebp),%dl Code; c020859b <_pagebuf_lookup_pages+2ab/2f0> 9: b7 47 mov $0x47,%bh Code; c020859d <_pagebuf_lookup_pages+2ad/2f0> b: 7c 81 jl ffffff8e <_EIP+0xffffff8e> Code; c020859f <_pagebuf_lookup_pages+2af/2f0> d: 4f dec %edi Code; c02085a0 <_pagebuf_lookup_pages+2b0/2f0> e: 08 04 00 or %al,(%eax,%eax,1) Code; c02085a3 <_pagebuf_lookup_pages+2b3/2f0> 11: 00 01 add %al,(%ecx) Code; c02085a5 <_pagebuf_lookup_pages+2b5/2f0> 13: 8d 00 lea (%eax),%eax --------------030500010508020204010905-- From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:41:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:41:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CNf1tG024427 for ; Thu, 12 Sep 2002 16:41:01 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA01069; Thu, 12 Sep 2002 18:45:31 -0500 (CDT) Received: from [192.168.1.101] (IDENT:1r2AFiycYRCll7S+TpGuaoKQJScZVz+P@cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id SAA24402; Thu, 12 Sep 2002 18:45:30 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Samuel Flory Cc: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com In-Reply-To: <3D81235B.6080809@rackable.com> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 12 Sep 2002 18:45:28 -0500 Message-Id: <1031874330.1236.3.camel@snafu> Mime-Version: 1.0 X-archive-position: 363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-12 at 18:29, Samuel Flory wrote: > Your patch seem to solve only some of the xfs issues for me. Before > the patch my system hung when booting. This only occured I had xfs > compiled into the kernel. After patching things seemed fine, but > durning "dbench 32" the system locked. Upon rebooting and attempting to > mount the filesystem I got this: > XFS mounting filesystem md(9,2) > Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) > kernel BUG at page_buf.c:578! > > Line numbers in no way line up with the code I have in front of me, However, this appears to equate to a failure in the address space remapping code. This is not a failure I have ever seen in our code base. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:59:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:59:39 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CNxZtG025408 for ; Thu, 12 Sep 2002 16:59:35 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D046W26677; Thu, 12 Sep 2002 20:04:06 -0400 Message-ID: <3D812BEB.3040903@rackable.com> Date: Thu, 12 Sep 2002 17:06:03 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <1031874330.1236.3.camel@snafu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Line 578 is BUG(); below: mapit: pb->pb_flags |= _PBF_MEM_ALLOCATED; if (all_mapped) { pb->pb_flags |= _PBF_ALL_PAGES_MAPPED; /* A single page buffer is always mappable */ if (page_count == 1) { pb->pb_addr = (caddr_t) page_address(pb->pb_pages[0]) + pb->pb_offset; pb->pb_flags |= PBF_MAPPED; } else if (flags & PBF_MAPPED) { if (as_list_len > 64) purge_addresses(); pb->pb_addr = vmap(pb->pb_pages, page_count); if (!pb->pb_addr) BUG(); pb->pb_addr += pb->pb_offset; pb->pb_flags |= PBF_MAPPED | _PBF_ADDR_ALLOCATED; } } /* If some pages were found with data in them * we are not in PBF_NONE state. */ if (good_pages != 0) { pb->pb_flags &= ~(PBF_NONE); if (good_pages != page_count) { pb->pb_flags |= PBF_PARTIAL; } } PB_TRACE(pb, PB_TRACE_REC(look_pg), good_pages); return rval; } Stephen Lord wrote: >On Thu, 2002-09-12 at 18:29, Samuel Flory wrote: > > >> Your patch seem to solve only some of the xfs issues for me. Before >>the patch my system hung when booting. This only occured I had xfs >>compiled into the kernel. After patching things seemed fine, but >>durning "dbench 32" the system locked. Upon rebooting and attempting to >>mount the filesystem I got this: >>XFS mounting filesystem md(9,2) >>Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) >>kernel BUG at page_buf.c:578! >> >> >> >> > >Line numbers in no way line up with the code I have in front of me, >However, this appears to equate to a failure in the address space >remapping code. This is not a failure I have ever seen in our code >base. > >Steve > > > > From owner-linux-xfs@oss.sgi.com Thu Sep 12 17:18:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 17:18:17 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D0I9tG026048 for ; Thu, 12 Sep 2002 17:18:10 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id CAA13424; Fri, 13 Sep 2002 02:55:04 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8D0Nhoq024281; Fri, 13 Sep 2002 02:23:43 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8D0NI8Q021453; Fri, 13 Sep 2002 02:23:18 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8D0NGr5021452; Fri, 13 Sep 2002 02:23:16 +0200 Date: Fri, 13 Sep 2002 02:23:16 +0200 From: Andrea Arcangeli To: Samuel Flory Cc: Austin Gonyou , Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913002316.GG11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D81235B.6080809@rackable.com> User-Agent: Mutt/1.3.27i X-archive-position: 365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 12, 2002 at 04:29:31PM -0700, Samuel Flory wrote: > Your patch seem to solve only some of the xfs issues for me. Before > the patch my system hung when booting. This only occured I had xfs > compiled into the kernel. After patching things seemed fine, but > durning "dbench 32" the system locked. Upon rebooting and attempting to > mount the filesystem I got this: > XFS mounting filesystem md(9,2) > Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) > kernel BUG at page_buf.c:578! > > > PS- The results of ksymoops are attached. that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it must return -ENOMEM to userspace instead, or it can try to recollect and release some of the other vmalloced entries. Most probably you run into an address space shortage, not a real ram shortage, so to workaround it you can recompile with CONFIG_2G and it'll probably work, also dropping the gap page in vmalloc may help workaround it (there's no config option for it though). It could be also a vmap leak, maybe a missing vfree, just some idea. > > Andrea Arcangeli wrote: > > >was a collision between new xfs and new scheduler, you can use this fix > >in the meantime: > > > >--- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 > >2002 > >+++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 > >@@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( > > spin_unlock_irq(¤t->sigmask_lock); > > > > /* Migrate to the right CPU */ > >- current->cpus_allowed = 1UL << cpu; > >- while (smp_processor_id() != cpu) > >- schedule(); > >+ set_cpus_allowed(current, 1UL << cpu); > >+ if (cpu() != cpu) > >+ BUG(); > > > > sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); > > INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); > > > >also remeber to apply the O_DIRECT fixes for reiserfs and ext3 (that > >were left over after merging the new nfs stuff). all will be fixed in > >next -aa of course. > > > >--- 2.4.19pre3aa1/fs/reiserfs/inode.c.~1~ Tue Mar 12 00:07:18 2002 > >+++ 2.4.19pre3aa1/fs/reiserfs/inode.c Tue Mar 12 01:24:21 2002 > >@@ -2161,10 +2161,11 @@ > > } > >} > > > >-static int reiserfs_direct_io(int rw, struct inode *inode, > >+static int reiserfs_direct_io(int rw, struct file * filp, > > struct kiobuf *iobuf, unsigned long blocknr, > > int blocksize) > >{ > >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > > return generic_direct_IO(rw, inode, iobuf, blocknr, blocksize, > > reiserfs_get_block_direct_io) ; > >} > >--- 2.4.20pre5aa2/fs/ext3/inode.c.~1~ Mon Sep 9 02:38:08 2002 > >+++ 2.4.20pre5aa2/fs/ext3/inode.c Tue Sep 10 05:22:18 2002 > >@@ -1385,9 +1385,10 @@ static int ext3_releasepage(struct page > >} > > > >static int > >-ext3_direct_IO(int rw, struct inode *inode, struct kiobuf *iobuf, > >+ext3_direct_IO(int rw, struct file * filp, struct kiobuf *iobuf, > > unsigned long blocknr, int blocksize) > >{ > >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > > struct ext3_inode_info *ei = EXT3_I(inode); > > handle_t *handle = NULL; > > int ret; > > > >Andrea > >- > >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >the body of a message to majordomo@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > >Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > > > > ksymoops 2.4.5 on i686 2.4.20-pre5aa2-fixed-xfs. Options used > -V (specified) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.20-pre5aa2-fixed-xfs/ (default) > -m /boot/System.map-2.4.20-pre5aa2-fixed-xfs (default) > > kernel BUG at page_buf.c:578! > invalid operand: 0000 2.4.20-pre5aa2-fixed-xfs #4 SMP Thu Sep 12 11:51:40 PDT 2002 > CPU: 1 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: 00000000 ebx: 00000001 ecx: 00000001 edx: 00000000 > esi: c5e15a04 edi: c5e15980 ebp: 00000002 esp: c5c19a58 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 805, stackpage=c5c19000) > Stack: c5c18000 00001000 00000000 00000001 00000000 00000005 000001f0 00000002 > c5e15980 c5e15980 00002205 c5e20540 c02089c8 c5e15980 c5c117b4 00002205 > 13005f90 00000000 c5912d40 13005f90 00000000 c01f4d2d c5912d40 13005f90 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] > Code: 0f 0b 42 02 95 ab 35 c0 0f b7 47 7c 81 4f 08 04 00 00 01 8d > > > >>EIP; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== > > >>esi; c5e15a04 > >>edi; c5e15980 > >>esp; c5c19a58 <[ip_tables].data.end+116159/294761> > > Trace; c02089c8 > Trace; c01f4d2d > Trace; c01f45e1 > Trace; c01f463a > Trace; c01f58b2 > Trace; c01f59f6 > Trace; c01f5b5a > Trace; c01f6744 > Trace; c01f6c74 > Trace; c01f6cc4 > Trace; c01f6e45 > Trace; c01efde7 > Trace; c01f861c > Trace; c01f776b > Trace; c01f77b0 > Trace; c01ff894 > Trace; c01ff97b > Trace; c0212ce6 > Trace; c0148c81 > Trace; c0148e9c > Trace; c014dfb8 > Trace; c015c145 > Trace; c015c43b > Trace; c015c29c > Trace; c015c904 > Trace; c0108d9b > > Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> > 00000000 <_EIP>: > Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== > 0: 0f 0b ud2a <===== > Code; c0208594 <_pagebuf_lookup_pages+2a4/2f0> > 2: 42 inc %edx > Code; c0208595 <_pagebuf_lookup_pages+2a5/2f0> > 3: 02 95 ab 35 c0 0f add 0xfc035ab(%ebp),%dl > Code; c020859b <_pagebuf_lookup_pages+2ab/2f0> > 9: b7 47 mov $0x47,%bh > Code; c020859d <_pagebuf_lookup_pages+2ad/2f0> > b: 7c 81 jl ffffff8e <_EIP+0xffffff8e> > Code; c020859f <_pagebuf_lookup_pages+2af/2f0> > d: 4f dec %edi > Code; c02085a0 <_pagebuf_lookup_pages+2b0/2f0> > e: 08 04 00 or %al,(%eax,%eax,1) > Code; c02085a3 <_pagebuf_lookup_pages+2b3/2f0> > 11: 00 01 add %al,(%ecx) > Code; c02085a5 <_pagebuf_lookup_pages+2b5/2f0> > 13: 8d 00 lea (%eax),%eax > Andrea From owner-linux-xfs@oss.sgi.com Thu Sep 12 17:43:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 17:43:24 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D0hItG026676 for ; Thu, 12 Sep 2002 17:43:18 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA02449; Thu, 12 Sep 2002 19:47:52 -0500 (CDT) Received: from [192.168.1.101] (IDENT:vbS4jLV5dwrL4SsD07YZ/BkWBnnHf/oy@cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id TAA50065; Thu, 12 Sep 2002 19:47:50 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Andrea Arcangeli Cc: Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com In-Reply-To: <20020913002316.GG11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 12 Sep 2002 19:47:48 -0500 Message-Id: <1031878070.1236.29.camel@snafu> Mime-Version: 1.0 X-archive-position: 366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-12 at 19:23, Andrea Arcangeli wrote: > > that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it > must return -ENOMEM to userspace instead, or it can try to recollect and > release some of the other vmalloced entries. Most probably you run into > an address space shortage, not a real ram shortage, so to workaround it > you can recompile with CONFIG_2G and it'll probably work, also dropping > the gap page in vmalloc may help workaround it (there's no config option > for it though). It could be also a vmap leak, maybe a missing vfree, > just some idea. > We hold vmalloced space for very short periods of time, in fact filesystem recovery and large extended attributes are the only cases. In this case we should be attempting to remap 2 pages together. The only way out of this would be to fail the whole mount at this point. I suspect a leak elsewhere. Samuel, when you mounted xfs and it oopsed, was it shortly after bootup? Also, how far did your dbench run get before it hung? I tried the kernel, but I paniced during startup - then I realized I did not apply the patch to fix the xfs/scheduler interactions first. How much memory is in the machine by the way? And Andrea, is the vmalloc space size reduced in the 3G user space configuration? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 12 17:49:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 17:49:35 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D0nWtG027161 for ; Thu, 12 Sep 2002 17:49:32 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id DAA13793; Fri, 13 Sep 2002 03:26:29 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8D0t5oq024336; Fri, 13 Sep 2002 02:55:05 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8D0se8Q022919; Fri, 13 Sep 2002 02:54:40 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8D0seG8022918; Fri, 13 Sep 2002 02:54:40 +0200 Date: Fri, 13 Sep 2002 02:54:40 +0200 From: Andrea Arcangeli To: Stephen Lord Cc: Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913005440.GJ11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031878070.1236.29.camel@snafu> User-Agent: Mutt/1.3.27i X-archive-position: 367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: > How much memory is in the machine by the way? And Andrea, is the > vmalloc space size reduced in the 3G user space configuration? it's not reduced, it's the usual 128m. BTW, I forgot to say that to really take advantage of CONFIG_2G one should increase __VMALLOC_RESERVE too, it's not directly in function of the CONFIG_2G. Andrea From owner-linux-xfs@oss.sgi.com Thu Sep 12 18:12:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 18:12:25 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D1CItG032362 for ; Thu, 12 Sep 2002 18:12:19 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D1GrW30034; Thu, 12 Sep 2002 21:16:53 -0400 Message-ID: <3D813CFB.7050200@rackable.com> Date: Thu, 12 Sep 2002 18:18:51 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Austin Gonyou , Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Andrea Arcangeli wrote: >On Thu, Sep 12, 2002 at 04:29:31PM -0700, Samuel Flory wrote: > > >> Your patch seem to solve only some of the xfs issues for me. Before >>the patch my system hung when booting. This only occured I had xfs >>compiled into the kernel. After patching things seemed fine, but >>durning "dbench 32" the system locked. Upon rebooting and attempting to >>mount the filesystem I got this: >>XFS mounting filesystem md(9,2) >>Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) >>kernel BUG at page_buf.c:578! >> >> >>PS- The results of ksymoops are attached. >> >> > >that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it >must return -ENOMEM to userspace instead, or it can try to recollect and >release some of the other vmalloced entries. Most probably you run into >an address space shortage, not a real ram shortage, so to workaround it >you can recompile with CONFIG_2G and it'll probably work, also dropping >the gap page in vmalloc may help workaround it (there's no config option >for it though). It could be also a vmap leak, maybe a missing vfree, >just some idea. > > > The system has 4G of ram, and 4G of swap. So real memory is not an issue. The system is a intended to be an nfs server. As a result nfs performance is my only real concern. I should really use CONFIG_3GB as I'm not doing much in user space other a tftp, and dhcp server. In any case the system isn't in production so I can leave it as is till monday. From owner-linux-xfs@oss.sgi.com Thu Sep 12 18:20:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 18:20:35 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D1KWtG008271 for ; Thu, 12 Sep 2002 18:20:32 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D1P6W30381; Thu, 12 Sep 2002 21:25:06 -0400 Message-ID: <3D813EE8.6090700@rackable.com> Date: Thu, 12 Sep 2002 18:27:04 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Stephen Lord wrote: >On Thu, 2002-09-12 at 19:23, Andrea Arcangeli wrote: > > >>that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it >>must return -ENOMEM to userspace instead, or it can try to recollect and >>release some of the other vmalloced entries. Most probably you run into >>an address space shortage, not a real ram shortage, so to workaround it >>you can recompile with CONFIG_2G and it'll probably work, also dropping >>the gap page in vmalloc may help workaround it (there's no config option >>for it though). It could be also a vmap leak, maybe a missing vfree, >>just some idea. >> >> >> > >We hold vmalloced space for very short periods of time, in fact >filesystem recovery and large extended attributes are the only >cases. In this case we should be attempting to remap 2 pages >together. The only way out of this would be to fail the whole >mount at this point. I suspect a leak elsewhere. > >Samuel, when you mounted xfs and it oopsed, was it shortly after bootup? > Yes I'd just logged in and manually mounted it. >Also, how far did your dbench run get before it hung? I tried the >kernel, but I paniced during startup - then I realized I did not >apply the patch to fix the xfs/scheduler interactions first. > > It looked around 1/4 to 1/2 done with dbench 32. I'm not sure if it was the 1st or second run. I run dbench from a script: sync sync ./dbench 2 sync sync ./dbench 4 sync sync ./dbench 8 sync sync ./dbench 16 sync sync ./dbench 32 sync sync ./dbench 64 sync sync I generally use this script narrow down which configurations seem to be most promising. >How much memory is in the machine by the way? > 4G ram, and 4G swap. From owner-linux-xfs@oss.sgi.com Thu Sep 12 19:07:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 19:07:51 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D27ktG024642 for ; Thu, 12 Sep 2002 19:07:46 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D2CGW32418; Thu, 12 Sep 2002 22:12:16 -0400 Message-ID: <3D8149F6.9060702@rackable.com> Date: Thu, 12 Sep 2002 19:14:14 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) Andrea Arcangeli wrote: >On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: > > >>How much memory is in the machine by the way? And Andrea, is the >>vmalloc space size reduced in the 3G user space configuration? >> >> > >it's not reduced, it's the usual 128m. > >BTW, I forgot to say that to really take advantage of CONFIG_2G one >should increase __VMALLOC_RESERVE too, it's not directly in function of >the CONFIG_2G. > So how much do you recommend increasing it? Currently it's: include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) From owner-linux-xfs@oss.sgi.com Thu Sep 12 19:07:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 19:07:51 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D27htG024631 for ; Thu, 12 Sep 2002 19:07:44 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D2CBW32414; Thu, 12 Sep 2002 22:12:11 -0400 Message-ID: <3D8149F1.4010008@rackable.com> Date: Thu, 12 Sep 2002 19:14:09 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <3D813EE8.6090700@rackable.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Stephen is there any reason to leave the system in it's current state? (IE You guys want the output of some tool.) Or shall I give it a go at a kernel with CONFIG_3GB, and maybe play with vmalloc settings? Samuel Flory wrote: > Stephen Lord wrote: > >> On Thu, 2002-09-12 at 19:23, Andrea Arcangeli wrote: >> >> >>> that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it >>> must return -ENOMEM to userspace instead, or it can try to recollect >>> and >>> release some of the other vmalloced entries. Most probably you run into >>> an address space shortage, not a real ram shortage, so to workaround it >>> you can recompile with CONFIG_2G and it'll probably work, also dropping >>> the gap page in vmalloc may help workaround it (there's no config >>> option >>> for it though). It could be also a vmap leak, maybe a missing vfree, >>> just some idea. >>> >>> >> >> >> We hold vmalloced space for very short periods of time, in fact >> filesystem recovery and large extended attributes are the only >> cases. In this case we should be attempting to remap 2 pages >> together. The only way out of this would be to fail the whole >> mount at this point. I suspect a leak elsewhere. >> >> Samuel, when you mounted xfs and it oopsed, was it shortly after bootup? >> > > Yes I'd just logged in and manually mounted it. > >> Also, how far did your dbench run get before it hung? I tried the >> kernel, but I paniced during startup - then I realized I did not >> apply the patch to fix the xfs/scheduler interactions first. >> >> > It looked around 1/4 to 1/2 done with dbench 32. I'm not sure if it > was the 1st or second run. I run dbench from a script: > sync > sync > ./dbench 2 > sync > sync > ./dbench 4 > sync > sync > ./dbench 8 > sync > sync > ./dbench 16 > sync > sync > ./dbench 32 > sync > sync > ./dbench 64 > sync > sync > > > I generally use this script narrow down which configurations seem to > be most promising. > >> How much memory is in the machine by the way? > > 4G ram, and 4G swap. > > > > From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:10:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:10:41 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8AZtG002973 for ; Fri, 13 Sep 2002 01:10:36 -0700 Received: from attbi.com ([24.60.116.36]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020913060250.CYEU16614.sccrmhc03.attbi.com@attbi.com> for ; Fri, 13 Sep 2002 06:02:50 +0000 Message-ID: <3D817F8A.6020205@attbi.com> Date: Fri, 13 Sep 2002 02:02:50 -0400 From: Clem Taylor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020908 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: ls segfaults, kernel does NULL pointer dereference... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clemtaylor@attbi.com Precedence: bulk X-list: linux-xfs I came home to find my 1.1TB disk array in a sick state, a drive is failing... When I do an ls on the volume, ls segfaults and the log shows that the kernel tried to dereference a NULL pointer. I'm running 2.4.19-rc1-xfs on a dual Athlon with a 3ware 7xxx controller and 6 160G Maxtor drives. I repaired the drive (and ordered a new one) and after reboot everything seems to be okay. It does seem a little strange that XFS would fail this way.... Here's what ksymoops says... Any ideas? --Clem <1>Unable to handle kernel NULL pointer dereference at virtual address 0000010e c01f2130 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Tainted: PF EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: c03c9440 edx: 00000000 esi: d8311ae4 edi: f7dae000 ebp: d0aabe48 esp: d0aabe08 ds: 0018 es: 0018 ss: 0018 Process ls (pid: 2695, stackpage=d0aab000) Stack: d8311af8 c03c9440 000001f0 00000000 f7d56240 00000012 f7dae000 00000004 00000000 00000000 00000000 01000100 00000000 00000000 d0aabebc f4f15e50 d0aabe98 c020b495 f7dae000 00000000 01000100 00000000 00000000 d0aabebc Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 26 01 00 00 00 74 27 89 34 24 c7 44 24 04 84 00 00 >>EIP; c01f2130 <===== Trace; c020b495 Trace; c01f2716 Trace; c02105f3 Trace; c021d5b3 Trace; c014a0a2 Trace; c014a83d Trace; c014ae91 <__user_walk+61/70> Trace; c014728e Trace; c01177e0 Trace; c01092ab Code; c01f2130 00000000 <_EIP>: Code; c01f2130 <===== 0: 66 83 bb 26 01 00 00 cmpw $0x0,0x126(%ebx) <===== Code; c01f2137 7: 00 Code; c01f2138 8: 74 27 je 31 <_EIP+0x31> Code; c01f213a a: 89 34 24 mov %esi,(%esp,1) Code; c01f213d d: c7 44 24 04 84 00 00 movl $0x84,0x4(%esp,1) Code; c01f2144 14: 00 From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:20:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:20:59 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8KutG003483 for ; Fri, 13 Sep 2002 01:20:57 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8D8PYsW078945; Fri, 13 Sep 2002 10:25:34 +0200 (CEST) Message-Id: <4.3.2.7.2.20020913102232.03d193f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Sep 2002 10:24:22 +0200 To: Clem Taylor , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: ls segfaults, kernel does NULL pointer dereference... In-Reply-To: <3D817F8A.6020205@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 02:02 13-9-2002 -0400, Clem Taylor wrote: >I came home to find my 1.1TB disk array in a sick state, a drive is >failing... When I do an ls on the volume, ls segfaults and the log shows >that the kernel tried to dereference a NULL pointer. > >I'm running 2.4.19-rc1-xfs on a dual Athlon with a 3ware 7xxx controller >and 6 160G Maxtor drives. I repaired the drive (and ordered a new one) and >after reboot everything seems to be okay. It does seem a little strange >that XFS would fail this way.... Normally XFS would detect corruption and shutdown the fs. Did you see anything about this in the logs? What extra modules/patches do you have loaded? Is the 3ware controller loaded with the latest firmware and drivers? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:24:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:24:21 -0700 (PDT) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8ODtG004006 for ; Fri, 13 Sep 2002 01:24:14 -0700 Received: (qmail 24487 invoked from network); 13 Sep 2002 09:28:51 +0100 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 13 Sep 2002 09:28:51 +0100 Subject: Re: ls segfaults, kernel does NULL pointer dereference... From: Tony Gale To: Clem Taylor Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D817F8A.6020205@dstl.gov.uk> References: <3D817F8A.6020205@dstl.gov.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4NWM+GuKK7bv1cGRuh8g" X-Mailer: Ximian Evolution 1.0.8.99 Date: 13 Sep 2002 09:28:52 +0100 Message-Id: <1031905732.316.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-archive-position: 373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs --=-4NWM+GuKK7bv1cGRuh8g Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-09-13 at 07:02, Clem Taylor wrote: > EIP: 0010:[] Tainted: PF What has the kernel been tainted by? -tony --=-4NWM+GuKK7bv1cGRuh8g Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUAPYGhxB/0GZs/Z0FlAQKe5wP/RXU//1vJcJ6ckvl9EmEZNbOrN+Pw4xsG KCB6WPGD3VzC3vRZ4T+1I5w8GM8VO9VdDFwwxqGwVgVeIEw9v5VJsizKykEDMPvq vfODV2Wx5igsbSskU9LVqixFgh213ACimJlT4hlnQTB7fa/GGM1TXDstCDn8iKeB bhoDT7Lna/s= =iBzZ -----END PGP SIGNATURE----- --=-4NWM+GuKK7bv1cGRuh8g-- From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:50:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:50:51 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8ojtG004789 for ; Fri, 13 Sep 2002 01:50:45 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 4ED9E1438D; Fri, 13 Sep 2002 10:55:20 +0200 (MEST) Date: Fri, 13 Sep 2002 10:55:19 +0200 From: Andi Kleen To: Clem Taylor Cc: linux-xfs@oss.sgi.com Subject: Re: ls segfaults, kernel does NULL pointer dereference... Message-ID: <20020913105519.A21554@wotan.suse.de> References: <3D817F8A.6020205@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D817F8A.6020205@attbi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 02:02:50AM -0400, Clem Taylor wrote: > I came home to find my 1.1TB disk array in a sick state, a drive is > failing... When I do an ls on the volume, ls segfaults and the log shows > that the kernel tried to dereference a NULL pointer. > > I'm running 2.4.19-rc1-xfs on a dual Athlon with a 3ware 7xxx controller > and 6 160G Maxtor drives. I repaired the drive (and ordered a new one) and > after reboot everything seems to be okay. It does seem a little strange > that XFS would fail this way.... > Looks like a bug in xfs_iget's error handling. When a read error occurs during getting the inode xfs_iget_core doesn't insert a vnode behaviour and later code which assumes that the behaviour is there fails. This patch should fix it at least for this case. It may be safer to always insert a behaviour even in the error case, but one would hope that all callers of xfs_iget handle errors properly. --- linux/fs/xfs/xfs_iget.c-o Tue Aug 27 21:00:43 2002 +++ linux/fs/xfs/xfs_iget.c Fri Sep 13 10:53:58 2002 @@ -493,6 +493,10 @@ goto retry; } + if (is_bad_inode(inode)) { + iput(inode); + return EIO; + } bdp = vn_bhv_lookup(VN_BHV_HEAD(vp), &xfs_vnodeops); ip = XFS_BHVTOI(bdp); if (lock_flags != 0) { -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 13 06:04:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 06:04:20 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DD4EtG009595 for ; Fri, 13 Sep 2002 06:04:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA21783 for ; Fri, 13 Sep 2002 08:08:51 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA16185 for ; Fri, 13 Sep 2002 08:08:49 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKNvP26542 for linux-xfs@oss.sgi.com; Fri, 13 Sep 2002 16:23:57 -0400 Resent-Message-Id: <200209132023.g8DKNvP26542@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA61047 for ; Fri, 13 Sep 2002 07:57:46 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKCrE25712 for hch@sgi.com; Fri, 13 Sep 2002 16:12:53 -0400 Date: Fri, 13 Sep 2002 16:12:53 -0400 From: Christoph Hellwig Message-Id: <200209132012.g8DKCrE25712@dhcp212.munich.sgi.com> Subject: TAKE - Fix up comments: Pagebuf is only used for metadata nowdays Resent-Date: Fri, 13 Sep 2002 16:23:56 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Sep 13 05:57:01 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127345a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.29 linux/fs/xfs/pagebuf/page_buf.c - 1.59 - Fix up comments: Pagebuf is only used for metadata nowdays From owner-linux-xfs@oss.sgi.com Fri Sep 13 06:32:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 06:32:28 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DDWQtG010319 for ; Fri, 13 Sep 2002 06:32:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA21640 for ; Fri, 13 Sep 2002 08:37:02 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA99866 for ; Fri, 13 Sep 2002 08:37:01 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKq8929852 for linux-xfs@oss.sgi.com; Fri, 13 Sep 2002 16:52:08 -0400 Resent-Message-Id: <200209132052.g8DKq8929852@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA90126 for ; Fri, 13 Sep 2002 08:36:29 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKpaM29843 for hch@sgi.com; Fri, 13 Sep 2002 16:51:36 -0400 Date: Fri, 13 Sep 2002 16:51:36 -0400 From: Christoph Hellwig Message-Id: <200209132051.g8DKpaM29843@dhcp212.munich.sgi.com> Subject: TAKE - Fix the scheduler fix Resent-Date: Fri, 13 Sep 2002 16:52:08 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs I fixed it for the O(1) scheduler but broke it for the stock one, duh. Found by Nathan Scott. Date: Fri Sep 13 06:34:53 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127348a linux/fs/xfs/pagebuf/page_buf.c - 1.60 - Add back missing current->cpus_allowed = 1UL << cpu; in the pagebuf initialization for the old scheduler. Tidy up check for new scheduler a little and comment it properly. From owner-linux-xfs@oss.sgi.com Fri Sep 13 06:58:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 06:58:19 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DDwDtG010969 for ; Fri, 13 Sep 2002 06:58:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA21159 for ; Fri, 13 Sep 2002 09:02:50 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA96045 for ; Fri, 13 Sep 2002 09:02:48 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DLHui31155 for linux-xfs@oss.sgi.com; Fri, 13 Sep 2002 17:17:56 -0400 Date: Fri, 13 Sep 2002 17:17:56 -0400 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: TAKE - Return -ENOMEM on vmap failure in _pagebuf_lookup_pages] Message-ID: <20020913171756.A31081@dhcp212.munich.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs This handles the problem Samuel saw more gracefully, but the cause of the vmap failure is still not solved. (Which is like to be outside XFS) Date: Fri Sep 13 06:58:21 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127349a linux/fs/xfs/pagebuf/page_buf.c - 1.61 - Return -ENOMEM on vmap failure in _pagebuf_lookup_pages From owner-linux-xfs@oss.sgi.com Fri Sep 13 09:32:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 09:32:35 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DGWQtG014861 for ; Fri, 13 Sep 2002 09:32:27 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id PAA30903; Fri, 13 Sep 2002 15:25:39 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8DCsGoq025550; Fri, 13 Sep 2002 14:54:16 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8DCro8Q022902; Fri, 13 Sep 2002 14:53:50 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8DCrjEn022901; Fri, 13 Sep 2002 14:53:45 +0200 Date: Fri, 13 Sep 2002 14:53:45 +0200 From: Andrea Arcangeli To: Samuel Flory Cc: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913125345.GO11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8149F6.9060702@rackable.com> User-Agent: Mutt/1.3.27i X-archive-position: 378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 12, 2002 at 07:14:14PM -0700, Samuel Flory wrote: > include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) > include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) > > > Andrea Arcangeli wrote: > > >On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: > > > > > >>How much memory is in the machine by the way? And Andrea, is the > >>vmalloc space size reduced in the 3G user space configuration? > >> > >> > > > >it's not reduced, it's the usual 128m. > > > >BTW, I forgot to say that to really take advantage of CONFIG_2G one > >should increase __VMALLOC_RESERVE too, it's not directly in function of > >the CONFIG_2G. > > > > So how much do you recommend increasing it? Currently it's: > include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) > include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to (512 << 20) and see if it helps. If it only happens a bit later then it's most probably an address space leak, should be easy to track down some debugging instrumentation. Andrea From owner-linux-xfs@oss.sgi.com Fri Sep 13 11:21:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 11:22:01 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DILttG016747 for ; Fri, 13 Sep 2002 11:21:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA24433 for ; Fri, 13 Sep 2002 13:26:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA15955 for ; Fri, 13 Sep 2002 13:26:32 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8DINgZ25682; Fri, 13 Sep 2002 13:23:42 -0500 Message-Id: <200209131823.g8DINgZ25682@jen.americas.sgi.com> Date: Fri, 13 Sep 2002 13:23:42 -0500 Subject: TAKE - remove dead code paths from create/mkdir/link/symlink To: linux-xfs@oss.sgi.com X-archive-position: 379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The vfs layer locking in linux means that there were several code paths in the new inode creation paths which could never happen. We only get into the filesystem's create paths if there is nothing there, these paths were checking for an existing name. Date: Fri Sep 13 11:24:43 PDT 2002 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:127368a linux/fs/xfs/xfs_vnodeops.c - 1.563 From owner-linux-xfs@oss.sgi.com Fri Sep 13 12:13:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 12:13:18 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DJDCtG021788 for ; Fri, 13 Sep 2002 12:13:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA25145; Fri, 13 Sep 2002 14:17:49 -0500 (CDT) Received: from [192.168.1.101] (IDENT:5UD84r2pYEHcoZJLaoAv2VpZkYC2TAYM@mtv-vpn-sw-corp-0-43.corp.sgi.com [134.15.0.43]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA43110; Fri, 13 Sep 2002 14:17:42 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Samuel Flory Cc: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com In-Reply-To: <3D813CFB.7050200@rackable.com> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <3D813CFB.7050200@rackable.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 13 Sep 2002 14:17:42 -0500 Message-Id: <1031944671.1534.34.camel@snafu> Mime-Version: 1.0 X-archive-position: 380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-12 at 20:18, Samuel Flory wrote: > > The system has 4G of ram, and 4G of swap. So real memory is not an > issue. The system is a intended to be an nfs server. As a result nfs > performance is my only real concern. I should really use CONFIG_3GB as > I'm not doing much in user space other a tftp, and dhcp server. > > In any case the system isn't in production so I can leave it as is > till monday. > So, after backing out 00_net-softirq (this was killing my networking and NFS setup for some reason) and applying the new scheduler related fix in xfs, I have had this kernel up a few hours running dbench and a bunch of other things, it has not hung once or exhibited any other problems. Having said that, my environment is different, I do not have 4G of memory, I have 128M, and I also do not have md - not enough disks right now to do that. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Sep 13 12:59:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 12:59:35 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DJxWtG022973 for ; Fri, 13 Sep 2002 12:59:32 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 34BE41D7219; Fri, 13 Sep 2002 13:04:15 -0700 (PDT) Date: Fri, 13 Sep 2002 13:04:15 -0700 From: Chris Wedgwood To: Nathan Scott Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020913200415.GA19984@tapu.f00f.org> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> <20020913091211.B133147@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020913091211.B133147@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 09:12:11AM +1000, Nathan Scott wrote: > Extended attributes, not ACLs. We may want to switch this behavior > via a mount flag or something, to give either the IRIX or the Linux > semantics (like we did for SGID) - we'll talk. What differences exist right now? --cw From owner-linux-xfs@oss.sgi.com Fri Sep 13 13:46:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 13:46:35 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DKkTtG023934 for ; Fri, 13 Sep 2002 13:46:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA26815 for ; Fri, 13 Sep 2002 15:51:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA84033 for ; Fri, 13 Sep 2002 15:51:06 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8DKkhV22107; Fri, 13 Sep 2002 15:46:43 -0500 Message-Id: <200209132046.g8DKkhV22107@stout.americas.sgi.com> Date: Fri, 13 Sep 2002 15:46:43 -0500 Subject: TAKE - Fix xfs_iget error handling X-archive-position: 382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs (from Andi Kleen) xfs_iget error handling Date: Fri Sep 13 13:50:44 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127385a linux/fs/xfs/xfs_iget.c - 1.171 From owner-linux-xfs@oss.sgi.com Fri Sep 13 13:47:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 13:47:14 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DKlAtG024169 for ; Fri, 13 Sep 2002 13:47:11 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA25434; Fri, 13 Sep 2002 15:51:48 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA32477; Fri, 13 Sep 2002 15:51:47 -0500 (CDT) Subject: Re: TAKE - change symlink perms to 777 From: Eric Sandeen To: Chris Wedgwood Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020913200415.GA19984@tapu.f00f.org> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> <20020913091211.B133147@wobbly.melbourne.sgi.com> <20020913200415.GA19984@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 13 Sep 2002 15:47:24 -0500 Message-Id: <1031950045.14984.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Irix/XFS symlinks have the umask applied, other linux filesystems just make them 777. -Eric On Fri, 2002-09-13 at 15:04, Chris Wedgwood wrote: > On Fri, Sep 13, 2002 at 09:12:11AM +1000, Nathan Scott wrote: > > > Extended attributes, not ACLs. We may want to switch this behavior > > via a mount flag or something, to give either the IRIX or the Linux > > semantics (like we did for SGID) - we'll talk. > > What differences exist right now? > > > --cw -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Sep 13 13:53:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 13:53:57 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DKrotG025078 for ; Fri, 13 Sep 2002 13:53:50 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 NAA04916 for ; Fri, 13 Sep 2002 13:58:28 -0700 (PDT) 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 GAA21411; Sat, 14 Sep 2002 06:57:11 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id GAA36856; Sat, 14 Sep 2002 06:57:10 +1000 (AEDT) Date: Sat, 14 Sep 2002 06:57:10 +1000 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020914065710.A90915@wobbly.melbourne.sgi.com> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> <20020913091211.B133147@wobbly.melbourne.sgi.com> <20020913200415.GA19984@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020913200415.GA19984@tapu.f00f.org>; from cw@f00f.org.com on Fri, Sep 13, 2002 at 01:04:15PM -0700 X-archive-position: 384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 01:04:15PM -0700, Chris Wedgwood wrote: > On Fri, Sep 13, 2002 at 09:12:11AM +1000, Nathan Scott wrote: > > > Extended attributes, not ACLs. We may want to switch this behavior > > via a mount flag or something, to give either the IRIX or the Linux > > semantics (like we did for SGID) - we'll talk. > > What differences exist right now? > No differences exist right now because Eric has backed out the change. See the cvs log for Eric's change (its a one-liner), cheers. btw, I think some mail relay (possibly inside sgi) is botching sending mail to you from me - I've tried to send you a reply on some other (unrelated) mail before and it always seems to bounce. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Sep 13 14:03:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 14:03:13 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DL3BtG025987 for ; Fri, 13 Sep 2002 14:03:11 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8DL7jv05699; Fri, 13 Sep 2002 17:07:45 -0400 Message-ID: <3D825422.8000007@rackable.com> Date: Fri, 13 Sep 2002 14:09:54 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Andrea Arcangeli wrote: > > >you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to >(512 << 20) and see if it helps. If it only happens a bit later then >it's most probably an address space leak, should be easy to track down >some debugging instrumentation. > > It seems to be working for me now. I'm getting about 200 on dbench 4, and 90 on dbench 64. (Note you need to increase your log size to get these kinda of numbers.) Now I get to see how fast I can read files via nfs. From owner-linux-xfs@oss.sgi.com Fri Sep 13 14:13:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 14:13:44 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DLDdtG026620 for ; Fri, 13 Sep 2002 14:13:40 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id XAA08338; Fri, 13 Sep 2002 23:50:44 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8DLJIoq026487; Fri, 13 Sep 2002 23:19:18 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8DLIq8Q017605; Fri, 13 Sep 2002 23:18:52 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8DLIiS7017602; Fri, 13 Sep 2002 23:18:44 +0200 Date: Fri, 13 Sep 2002 23:18:44 +0200 From: Andrea Arcangeli To: Samuel Flory Cc: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913211844.GP11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D825422.8000007@rackable.com> User-Agent: Mutt/1.3.27i X-archive-position: 386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 02:09:54PM -0700, Samuel Flory wrote: > Andrea Arcangeli wrote: > > > > > > >you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to > >(512 << 20) and see if it helps. If it only happens a bit later then > >it's most probably an address space leak, should be easy to track down > >some debugging instrumentation. > > > > > > > It seems to be working for me now. I'm getting about 200 on dbench 4, > and 90 on dbench 64. (Note you need to increase your log size to get > these kinda of numbers.) Now I get to see how fast I can read files via > nfs. btw, if you run into troubles with networking with aa2 try to backout the last net-softirq patch, not sure why yet but the last modification I did malfunctions with some nic. Couldn't reproduce it here, but I'll look into that next week and I'll fix it too for the next -aa. So, returning to xfs, it is possible dbench really generates lots of simultaneous vmaps because of its concurrency, so I would suggest to add an atomic counter increased at every vmap/vmalloc and decreased at every vfree and to check it after every increase storing the max value in a sysctl, to see what's the max concurrency you reach with the vmaps. (you can also export the counter via the sysctl, to verify for no memleaks after unmounting xfs) Andrea From owner-linux-xfs@oss.sgi.com Fri Sep 13 22:04:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 22:04:20 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8E54HtG031711 for ; Fri, 13 Sep 2002 22:04:17 -0700 Received: (qmail 5548 invoked by uid 1010); 10 Sep 2002 19:32:56 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.156.135]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 19:32:56 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id 3F2A96D08; Tue, 10 Sep 2002 21:32:54 +0200 (CEST) Date: Tue, 10 Sep 2002 21:32:51 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <1019359078.20020910213251@huno.net> To: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error In-Reply-To: <20020910192023.GA5470@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> <20020910192023.GA5470@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs >> nope / is reiserfs. > and this is /dev/md0 for you? or something else? sorry, i guess i wasn't clear enough in my first post :) situation is like this: +[~]: df -Th Filesystem Type Size Used Avail Use% Mounted on /dev/hda1 reiserfs 2.2G 430M 1.8G 20% / /dev/hdc1 reiserfs 2.2G 1.6G 634M 72% /var /dev/md0 xfs 75G 69G 5.9G 93% /data +[~]: cat /proc/mdstat Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 hdc5[0] hda5[1] 78123904 blocks [2/2] [UU] all the stuff that i thought might be also responsible for this (sysvinit, mount, raidttols, ...) is already upgraded to latest version. now if there is a chance that cvs *might* help here i'm on my way to grab it. can i patch cvs with 2.4.19 or do i have to get 2.4.20-pre5? thomas From owner-linux-xfs@oss.sgi.com Sat Sep 14 07:36:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Sep 2002 07:36:21 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8EEaFtG005364 for ; Sat, 14 Sep 2002 07:36:15 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA31253; Sat, 14 Sep 2002 09:40:54 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-39.corp.sgi.com [134.15.64.39]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA22754; Sat, 14 Sep 2002 09:40:52 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Andrea Arcangeli Cc: Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel Mailing List , linux-xfs@oss.sgi.com In-Reply-To: <20020913211844.GP11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> <20020913211844.GP11605@dualathlon.random> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Sep 2002 09:39:24 -0500 Message-Id: <1032014367.1050.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote: > So, returning to xfs, it is possible dbench really generates lots of > simultaneous vmaps because of its concurrency, so I would suggest to add > an atomic counter increased at every vmap/vmalloc and decreased at every > vfree and to check it after every increase storing the max value in a > sysctl, to see what's the max concurrency you reach with the vmaps. (you > can also export the counter via the sysctl, to verify for no memleaks > after unmounting xfs) > > Andrea There are no vmaps during normal operation on xfs unless you are setting extended attributes of more than 4K in size, or you used some more obscure mkfs options. Only filesystem recovery will use it otherwise. Steve From owner-linux-xfs@oss.sgi.com Sat Sep 14 07:53:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Sep 2002 07:54:02 -0700 (PDT) Received: from mailcity.com (fes3-mail.whowhere.com [209.202.220.160] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8EErxtG005916 for ; Sat, 14 Sep 2002 07:53:59 -0700 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sat, 14 Sep 2002 14:58:32 -0000 To: jackie50002@lycos.com Date: Sat, 14 Sep 2002 10:58:32 -0400 From: "JACKIE SIDEBE MODISE" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: jackie50002@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 Subject: FUND MANAGEMENT X-Sender-Ip: 216.139.164.204 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit X-archive-position: 389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jackie50002@lycos.com Precedence: bulk X-list: linux-xfs From ; Jackie Sidebe Modise FUND MANAGEMENT Eventually I have made up my mind to contact you with humility for your assistance in matter of urgent important. I am Jackie Sidebe Modise, legal wife of Comrade Joe Modise,late leader of Umkhonto we Sizwe (MK),renowed freedom fighters, first minister of defence during Nelson Mandela Government of National Unity 1994 and owner of conglomorate of business. Our family made name in Gold Industry of South Africa. Unfortunately, my husband died after retiring from office and his death though linked to cancer but has traces of severe pressures from the new Government who wanted to probe his activities. Anyway nothing really got on the way about the probe proir his death but Government succeeded in frozening the family bank account and business assets while the immediate/larger family wallow! in porverty. However as the last,closest and legimate wife before he died I was opportuned to be in pocession of valuables including valued sum of US$42 million which I personally moved out during controversies with Government just after his death. This fortune I carefully deposited with a Security Company as PERSONAL EFFECT and I now want a trusted foreigner to represent me reclaim the funds for investment overseas. For obvious security reasons, I do not want to place this fund with established financial institution with the family name. It is my desire that this is handled as quietly as possible without possibility of any leakage to the public, government or even other family members hence I must be out of the scene while the transaction lasts. I have a lawyer to handle the matter and I have briefed him with full powers and confidence to lead and guide the transaction to a success. All evidence of the deposits is with! him too therefore I request you stand to receive the deposits and keep under your custody the funds for good management. MY LAWYER IS: STEPHEN AKIM ANCIENT CHAMBERS TEL.873-762-135441 Or Fax: 873-762-135442 Email. ancientchambers@ureach.com If you agree to act as my fund manager, the funds is safe with a private security company coded and lodged in with a fictitious name. Upon a favorable response from you, you will be adviced with the steps involve. No risk is on this because it has no record but you must respect my position.Your commission shall be 15% of the total sum as first payment plus annual 10% of the after tax returns on investment for the first 5 years but this is negotiable. If you are capable and willing to participate in this transaction quickly contact my email lawyer asap and if for any reason you are not disposed let me know still so I make alternative arrangement. I look forward to your earliest reply and do not forget the principles of secrecy and confidentiality. In any case, keep these Best regards Mrs Jackie Sidebe Modise _____________________________________________________________ Play the Elvis® Scratch & Win for your chance to instantly win $10,000 Cash - a 2003 Harley Davidson® Sportster® - 1 of 25,000 CD's - and more! http://r.lycos.com/r/sagel_mail_scratch_tl/http://win.ipromotions.com/lycos_020801/index.asp?tc=7087 From owner-linux-xfs@oss.sgi.com Sun Sep 15 03:55:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 03:55:49 -0700 (PDT) Received: from fruit.eu.org (qmailr@d5111f5b.cable.wanadoo.nl [213.17.31.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FAthtG020267 for ; Sun, 15 Sep 2002 03:55:44 -0700 Received: (qmail 15373 invoked by uid 500); 15 Sep 2002 11:00:30 -0000 Date: Sun, 15 Sep 2002 13:00:30 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020915110030.GH17696@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> <20020911193759.GJ714@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020911193759.GJ714@plato.local.lan> User-Agent: Mutt/1.4i X-oi: oi X-archive-position: 390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-11 11:37:59-0800, Ethan Benson wrote: > > They are not. Consider a sticky directory. > what are you talking about? they are still irrelevant. Usually, sticky directories check unlink() authorisation by looking at the access bits of the file itself. It seems that Linux currently always returns EPERM when you try to delete a symlink that is not owned by you if it's in a sticky directory. It wasn't like that the last time I tested it, so I was basing my statement on outdated assumptions. Sorry. You are right, symlink permissions are completly irrelevant. Even readlink() isn't thwarted by them. -- wsl@fruit.eu.org From owner-linux-xfs@oss.sgi.com Sun Sep 15 04:08:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 04:08:50 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FB8itG021220 for ; Sun, 15 Sep 2002 04:08:44 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id B988314732; Sun, 15 Sep 2002 13:13:27 +0200 (MEST) Date: Sun, 15 Sep 2002 13:13:24 +0200 From: Andi Kleen To: Stephen Lord Cc: Andrea Arcangeli , Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020915131324.A13516@wotan.suse.de> References: <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> <20020913211844.GP11605@dualathlon.random> <1032014367.1050.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032014367.1050.2.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Sat, Sep 14, 2002 at 09:39:24AM -0500, Steve Lord wrote: > On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote: > > > So, returning to xfs, it is possible dbench really generates lots of > > simultaneous vmaps because of its concurrency, so I would suggest to add > > an atomic counter increased at every vmap/vmalloc and decreased at every > > vfree and to check it after every increase storing the max value in a > > sysctl, to see what's the max concurrency you reach with the vmaps. (you > > can also export the counter via the sysctl, to verify for no memleaks > > after unmounting xfs) > > > > Andrea > > There are no vmaps during normal operation on xfs unless you are > setting extended attributes of more than 4K in size, or you > used some more obscure mkfs options. Only filesystem recovery will > use it otherwise. Perhaps the original poster used those obscure mkfs options? What option will trigger huge allocations ? -Andi From owner-linux-xfs@oss.sgi.com Sun Sep 15 05:07:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 05:07:43 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FC7btG027403 for ; Sun, 15 Sep 2002 05:07:37 -0700 Received: from erbenson.alaska.net (104-pm18.nwc.alaska.net [209.112.142.104]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8FCCPBs072604 for ; Sun, 15 Sep 2002 04:12:26 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id EC14F3A0A for ; Sun, 15 Sep 2002 04:12:24 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 52E974104E2; Sun, 15 Sep 2002 04:12:24 -0800 (AKDT) Date: Sun, 15 Sep 2002 04:12:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020915121224.GA1746@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> <20020911193759.GJ714@plato.local.lan> <20020915110030.GH17696@fruit.eu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20020915110030.GH17696@fruit.eu.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2002 at 01:00:30PM +0200, Wessel Dankers wrote: > On 2002-09-11 11:37:59-0800, Ethan Benson wrote: > > > They are not. Consider a sticky directory. > > what are you talking about? they are still irrelevant. >=20 > Usually, sticky directories check unlink() authorisation by looking at the > access bits of the file itself. you are wrong, sticky directories check the ownership of the file and only allow unlink() if the file owner matches the uid of the user attempting unlink(), or if the user owns the sticky directory, or the user is root. the file's permissions have absolutly nothing to do with it.=20=20 and if they did forcing symlinks to mode 777 would be a security hole since it would allow any user to always delete them in sticky dirs. > It seems that Linux currently always returns EPERM when you try to delete= a > symlink that is not owned by you if it's in a sticky directory. It wasn't > like that the last time I tested it, so I was basing my statement on > outdated assumptions. Sorry. i have never heard of symlinks being treated special in this manner, they are just files like anything else. > You are right, symlink permissions are completly irrelevant. Even > readlink() isn't thwarted by them. from chmod(1) chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2EeSgACgkQJKx7GixEevzLGQCbBIx3vQCtyASzyaHb0m4OyFuW DQsAnAyuiQsDYGqbGbhUHgIJM1X7u+RN =UH+l -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-linux-xfs@oss.sgi.com Sun Sep 15 08:30:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 08:30:29 -0700 (PDT) Received: from fruit.eu.org (qmailr@d5111f5b.cable.wanadoo.nl [213.17.31.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FFUDtG028933 for ; Sun, 15 Sep 2002 08:30:13 -0700 Received: (qmail 16326 invoked by uid 500); 15 Sep 2002 15:35:02 -0000 Date: Sun, 15 Sep 2002 17:35:02 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Cc: Ethan Benson Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020915153502.GI17696@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com, Ethan Benson References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> <20020911193759.GJ714@plato.local.lan> <20020915110030.GH17696@fruit.eu.org> <20020915121224.GA1746@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020915121224.GA1746@plato.local.lan> User-Agent: Mutt/1.4i X-oi: oi X-archive-position: 393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-15 04:12:24-0800, Ethan Benson wrote: > you are wrong, sticky directories check the ownership of the file and > only allow unlink() if the file owner matches the uid of the user > attempting unlink(), or if the user owns the sticky directory, or the > user is root. the file's permissions have absolutly nothing to do > with it. Apparently Linux differs from Solaris in this respect (which seems to be where I remembered the semantics from): merry:/tmp% uname -a SunOS merry 5.8 Generic sun4m sparc merry:/tmp% id uid=100(wsl) gid=1(other) groups=1(other) merry:/tmp% ls -l foo -rw-rw-rw- 1 nobody nobody 4 Sep 15 17:12 foo merry:/tmp% rm foo merry:/tmp% ls -l foo foo: No such file or directory Solaris disallows unlinking other people's symlinks though. Again, I apologize for the noise. > from chmod(1) > > [snip] from shred(1) CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective: * log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) ^^^ Manpages aren't always 100% reliable (although your excerpt was certainly correct). Regards, -- wsl@fruit.eu.org From owner-linux-xfs@oss.sgi.com Sun Sep 15 12:32:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 12:32:12 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FJW4tG031866 for ; Sun, 15 Sep 2002 12:32:05 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8FJagv20311; Sun, 15 Sep 2002 15:36:43 -0400 Message-ID: <3D84E1E8.1070408@rackable.com> Date: Sun, 15 Sep 2002 12:39:20 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Stephen Lord , Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> <20020913211844.GP11605@dualathlon.random> <1032014367.1050.2.camel@laptop.americas.sgi.com> <20020915131324.A13516@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Andi Kleen wrote: >On Sat, Sep 14, 2002 at 09:39:24AM -0500, Steve Lord wrote: > > >>On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote: >> >> >> >>>So, returning to xfs, it is possible dbench really generates lots of >>>simultaneous vmaps because of its concurrency, so I would suggest to add >>>an atomic counter increased at every vmap/vmalloc and decreased at every >>>vfree and to check it after every increase storing the max value in a >>>sysctl, to see what's the max concurrency you reach with the vmaps. (you >>>can also export the counter via the sysctl, to verify for no memleaks >>>after unmounting xfs) >>> >>>Andrea >>> >>> >>There are no vmaps during normal operation on xfs unless you are >>setting extended attributes of more than 4K in size, or you >>used some more obscure mkfs options. Only filesystem recovery will >>use it otherwise. >> >> > >Perhaps the original poster used those obscure mkfs options? What option >will trigger huge allocations ? > I did not use any special options on the filesystem that had the issue. From owner-linux-xfs@oss.sgi.com Mon Sep 16 01:39:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 01:39:32 -0700 (PDT) Received: from [173.161.112.145] (adsl-nk-A2434.hitron.net [203.79.163.148]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8G8dPtG011930 for ; Mon, 16 Sep 2002 01:39:26 -0700 Received: from [173.161.162.145] by [173.161.26.145] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 18 Feb 2000 09:36:51 +0800 From: mlpi_uy_rff03dw@amazon.com To: linux-xfs@oss.sgi.com Subject: =?ISO-8859-1?Q?=B1=A1=BD=EC=A5=CE=AB~?= =?ISO-8859-1?Q?=BA=F4=B8=F4=C1=CA=AA=AB=B0=D3=AB=B0?= Reply-To: n3qv_coe_e3cbiy@bloomberg.com Date: 14 Sep 2002 21:39:16 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; ¬P´Á¥| 22 ¤K¤ë 2002 06:16:37 -0700 (EDT) Reply-To: receive_adm@topservice.net X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com X-Return-Path: mlpi_uy_rff03dw@amazon.com X-archive-position: 395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mlpi_uy_rff03dw@amazon.com Precedence: bulk X-list: linux-xfs µL¼ÐÃD¤å¥ó

±¡½ì¥Î«~ºô¸ôÁʪ«°Ó«°

¦pªG±z¨S¿³½ì©Î¬O¥¼¦¨¦~¡A½Ð¤Å¶i¤J.

§Ú­Ì¾Ö¦³³Ì·s©_©M³Ì¦hºØÃþªº±¡½ì¥Î«~

¥¿¬£¸gÀç¡A¸Û¼°Áܽбz¨Ó°ÑÆ[

¶i¤J

 

From owner-linux-xfs@oss.sgi.com Mon Sep 16 04:38:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 04:38:17 -0700 (PDT) Received: from rtsoft.rtsoft.msk.ru (Rtsoft-MTUInform-GW.mtu.ru [195.34.37.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GBbxtG025272 for ; Mon, 16 Sep 2002 04:38:10 -0700 Received: from mail by rtsoft.rtsoft.msk.ru with local (Exim 3.12 #1 (Debian)) id 17quHC-00050B-00; Mon, 16 Sep 2002 15:42:50 +0400 Received: from [192.168.100.40] (helo=develop.dev.rtsoft.msk.ru) by rtsoft.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17quHC-000502-00 for ; Mon, 16 Sep 2002 15:42:50 +0400 Received: from becha.dev.rtsoft.msk.ru ([192.168.100.169] helo=rtsoft.msk.ru) by develop.dev.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17quH6-0002Rh-00 for ; Mon, 16 Sep 2002 15:42:44 +0400 Message-ID: <3D85C8D5.6030901@rtsoft.msk.ru> Date: Mon, 16 Sep 2002 16:04:37 +0400 From: Frasenyak Dmitrij User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011031 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Need information about XFS tests Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-KAV: KavKeeper passed X-archive-position: 396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sed@rtsoft.msk.ru Precedence: bulk X-list: linux-xfs Hello I'm looking for any documentation about XFS tests included in CVS tree. I've searched over sgi site and Internet but found only small remarks in the headers of scripts. Thank you. From owner-linux-xfs@oss.sgi.com Mon Sep 16 05:50:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 05:50:56 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GCortG026789 for ; Mon, 16 Sep 2002 05:50:54 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA28196; Mon, 16 Sep 2002 07:55:42 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA44586; Mon, 16 Sep 2002 07:55:41 -0500 (CDT) Date: Mon, 16 Sep 2002 07:50:53 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Frasenyak Dmitrij cc: linux-xfs@oss.sgi.com Subject: Re: Need information about XFS tests In-Reply-To: <3D85C8D5.6030901@rtsoft.msk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs There is no comprehensive documentation, I'm afraid. Do you have a specific question? -Eric On Mon, 16 Sep 2002, Frasenyak Dmitrij wrote: > Hello > I'm looking for any documentation about XFS tests included in CVS tree. > I've searched over sgi site and Internet but found only small remarks > in the headers of scripts. > > Thank you. > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 16 07:41:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 07:41:58 -0700 (PDT) Received: from rtsoft.rtsoft.msk.ru (Rtsoft-MTUInform-GW.mtu.ru [195.34.37.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GEfotG032634 for ; Mon, 16 Sep 2002 07:41:51 -0700 Received: from mail by rtsoft.rtsoft.msk.ru with local (Exim 3.12 #1 (Debian)) id 17qx9A-0005bA-00; Mon, 16 Sep 2002 18:46:44 +0400 Received: from [192.168.100.40] (helo=develop.dev.rtsoft.msk.ru) by rtsoft.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17qx99-0005b1-00 for ; Mon, 16 Sep 2002 18:46:43 +0400 Received: from becha.dev.rtsoft.msk.ru ([192.168.100.169] helo=rtsoft.msk.ru) by develop.dev.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17qx97-0002kY-00 for ; Mon, 16 Sep 2002 18:46:41 +0400 Message-ID: <3D85F3F2.7060407@rtsoft.msk.ru> Date: Mon, 16 Sep 2002 19:08:34 +0400 From: Frasenyak Dmitrij User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011031 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re[2]: Need information about XFS tests References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-KAV: KavKeeper passed X-archive-position: 398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sed@rtsoft.msk.ru Precedence: bulk X-list: linux-xfs Yes 1 Do tests (placed in CVS tree) check all XFS/Linux functionality ? 2 Do i need SMP to build test environment ? 3 How can i obtain read access to bug-track system ? For example: i want to know what do the test N003 do but the only information available ( from xfscvs/linux-2.4-xfs/cmd/xfstests/003 ): ... # XFS QA Test No. 003 # $Id: 1.1 $ # # exercise xfs_db bug #784078 ... Thank you. Dmitrij. Eric Sandeen wrote: > There is no comprehensive documentation, I'm afraid. Do you have a specific > question? > > -Eric > > On Mon, 16 Sep 2002, Frasenyak Dmitrij wrote: > > >>Hello >>I'm looking for any documentation about XFS tests included in CVS tree. >>I've searched over sgi site and Internet but found only small remarks >>in the headers of scripts. >> >> Thank you. >> >> >> >> >> >> > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 16 07:50:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 07:50:07 -0700 (PDT) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GEo3tG000710 for ; Mon, 16 Sep 2002 07:50:03 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA04927; Mon, 16 Sep 2002 09:54:52 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 17qxH2-0004fk-00; Mon, 16 Sep 2002 09:54:52 -0500 Date: Mon, 16 Sep 2002 09:54:52 -0500 From: Nathan Straz To: Frasenyak Dmitrij Cc: linux-xfs@oss.sgi.com Subject: Re: Need information about XFS tests Message-ID: <20020916145452.GA16333@sgi.com> Mail-Followup-To: Frasenyak Dmitrij , linux-xfs@oss.sgi.com References: <3D85F3F2.7060407@rtsoft.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D85F3F2.7060407@rtsoft.msk.ru> User-Agent: Mutt/1.4i X-archive-position: 399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 07:08:34PM +0400, Frasenyak Dmitrij wrote: > Yes > 1 Do tests (placed in CVS tree) check all XFS/Linux functionality ? No, they target a subset of XFS specific functionality. > 2 Do i need SMP to build test environment ? No. > 3 How can i obtain read access to bug-track system ? > For example: i want to know what do the test N003 do but the > only information available ( from > xfscvs/linux-2.4-xfs/cmd/xfstests/003 ): > > ... > # XFS QA Test No. 003 > # $Id: 1.1 $ > # > # exercise xfs_db bug #784078 > ... I don't think that's likely. 784078 was a bug in relation to xfs_db core dumping with certain combinations of commands. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Sep 16 08:03:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 08:03:50 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GF3ktG001339 for ; Mon, 16 Sep 2002 08:03:46 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8GF8eq18539 for ; Mon, 16 Sep 2002 11:08:40 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8GF8eH18533 for ; Mon, 16 Sep 2002 11:08:40 -0400 Date: Mon, 16 Sep 2002 11:08:40 -0400 (EDT) From: Benito Venegas To: Subject: kernel src to compile In-Reply-To: <200209131823.g8DINgZ25682@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Good morning team: (bad morning for me, but I hope you have better than mine) I have a problem in one of my servers. Kernel Panic, only I have latest line, due Kernel Panic debug message was too big for my console (nfs_ related problem I think) grrrrrr..I ate don;t have good logs.... Does any of you guys have a kernel-2.4.18 or higher version in format src.rpm ready to compile? or at least > 2.4.9-31 that I am using today. Usually I do by myself, but I have to fix other issues in other server. I would appreciate your help team. Thanks Notes: Pe2450 1 CPU; current kernel 2.4.9-31SGI_XFS;nfs client only; a lot of I/O through NFS. Perc card (aacraid.o), Intel pro 1000 (e1000.o). Other servers don't have this problem :/ Seth, Jason?? Thanks again Vene.- From owner-linux-xfs@oss.sgi.com Mon Sep 16 08:32:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 08:32:36 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GFWVtG002776 for ; Mon, 16 Sep 2002 08:32:32 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA45259; Mon, 16 Sep 2002 10:37:21 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-13.corp.sgi.com [134.15.64.13]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA35373; Mon, 16 Sep 2002 10:37:20 -0500 (CDT) Subject: RE: Re-occurance of NFS server panics From: Stephen Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 10:35:43 -0500 Message-Id: <1032190545.1051.80.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-16 at 09:52, Ian D. Hardy wrote: > Steve +, > > Sorry to bother you again. You may remember that we've corresponded > several times over the past ~9months with regards to kernel memory > allocation problems and fragmented files (see bellow). > > We had a period of relative stability, however the last few weeks we > have gone back to a situation of having one or more crashes/hangs every > week and are now having to again review our continued use of XFS. > Therefore any update on progress towards a fix for these problems would > be very useful (I'd hate to go though the pain of converting our ~1Tbyte > filesystem to Reiser of ext3 if there are fixes immanent). > > We have been running a 2.4.18 XFS CVS kernel from Mid May for some time > now, I'm just in the process of compiling and testing the current 2.4.19 > XFS CVS, is this likely to help? (looking through the list archive I > can't find anything of direct relevance but may have missed something). > > We appear to be running at a lower overall system fragmentation level > now (currently 13% in the past it has been 28% or more), though I guess > it is possible for only a couple of large very fragmented files to > result in kernel memory allocation problems and still have reasonably > low overall FS fragmentation levels? > > Unfortunately the NFS load on our server is such that it is > difficult/impossible to predict times of light NFS load in which to run > fsr and as reported before we've had several incidents of filesystem > corruption and the kernel taking the FS offline running fsr under a NFS > load. > > Thanks for your time (BTW: We've persevered with XFS for so long as it > seems to give better performance for our workload than ext3 or ReiserFS, > however, stability is again becoming a problem). > Nothing immediately rings a bell, there have been some recent changes which fixed some hangs HP was having in doing large scale NFS benchmarking. These might be beneficial to you. The last oops output I have from you looked like this: >>EIP; c012ff76 <===== Trace; c01fd146 Trace; c01fd1a4 Trace; c01d04f0 Trace; c01a6996 Trace; c01a5f12 Trace; c01d6474 Trace; c01fd2e0 Trace; c01aac14 Trace; c01cf962 Trace; c01e6e22 Trace; c01e6340 Trace; c026cf44 Trace; c01f696e Trace; c01e6340 Trace; c014f45c Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> Trace; f8d2b348 <[nfsd]nfsd+1b8/370> Trace; c01057ea Code; c012ff76 00000000 <_EIP>: Code; c012ff76 <===== 0: 0f 0b ud2a <===== Code; c012ff78 2: 83 c4 08 add $0x8,%esp Code; c012ff7a 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx Code; c012ff80 b: 8b 2c 1a mov (%edx,%ebx,1),%ebp Code; c012ff84 e: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c012ff88 12: b8 00 00 00 00 mov $0x0,%eax Is this still what you see? This one does bear the symptoms of a problem which was fixed a while ago - memory was freed into the wrong pool. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 16 08:59:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 08:59:28 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GFxLtG003687 for ; Mon, 16 Sep 2002 08:59:21 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8GG44jv058354; Mon, 16 Sep 2002 12:04:04 -0400 Received: from nighthawk.sr71.net (sig-9-65-11-88.mts.ibm.com [9.65.11.88]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8GG41c0037022; Mon, 16 Sep 2002 10:04:01 -0600 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g8GG3iS00553; Mon, 16 Sep 2002 09:03:44 -0700 Message-ID: <3D8600DD.1010707@us.ibm.com> Date: Mon, 16 Sep 2002 09:03:41 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Samuel Flory , Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> X-Enigmail-Version: 0.65.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55ED74C752FF075D8DF4EEE1" X-archive-position: 402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: linux-xfs This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55ED74C752FF075D8DF4EEE1 Content-Type: multipart/mixed; boundary="------------010502070400000809040600" This is a multi-part message in MIME format. --------------010502070400000809040600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Arcangeli wrote: > On Thu, Sep 12, 2002 at 07:14:14PM -0700, Samuel Flory wrote: > >>Andrea Arcangeli wrote: >> >>>On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: >>> >>>>How much memory is in the machine by the way? And Andrea, is the >>>>vmalloc space size reduced in the 3G user space configuration? >>> >>>it's not reduced, it's the usual 128m. >>> >>>BTW, I forgot to say that to really take advantage of CONFIG_2G one >>>should increase __VMALLOC_RESERVE too, it's not directly in function of >>>the CONFIG_2G. >>> >> >>So how much do you recommend increasing it? Currently it's: >>include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) >>include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) > > > you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to > (512 << 20) and see if it helps. If it only happens a bit later then > it's most probably an address space leak, should be easy to track down > some debugging instrumentation. I just produced this little patch for 2.5. It should provide a bit of the extra information that you were looking for. It adds some entries to /proc/meminfo that look like this: VMalTotal: 92123 kB VmalUsed: 1264 kB VMalChunk: 80315 kB Total available, total used, and largest chunk available. It is simple enough that a backport shouldn't be any problem at all. Anybody interested? -- Dave Hansen haveblue@us.ibm.com --------------010502070400000809040600 Content-Type: text/plain; name="vmalloc-stats-2.5.34-mm4-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vmalloc-stats-2.5.34-mm4-2.patch" diff -ur linux-2.5.34-mm4/fs/proc/proc_misc.c linux-2.5.34-mm4-vmalloc-stats/fs/proc/proc_misc.c --- linux-2.5.34-mm4/fs/proc/proc_misc.c Sat Sep 14 21:23:54 2002 +++ linux-2.5.34-mm4-vmalloc-stats/fs/proc/proc_misc.c Sat Sep 14 22:38:12 2002 @@ -38,6 +38,7 @@ #include #include #include +#include #include #include @@ -128,6 +129,40 @@ return proc_calc_metrics(page, start, off, count, eof, len); } +struct vmalloc_info { + unsigned long used; + unsigned long largest_chunk; +}; + +static struct vmalloc_info get_vmalloc_info(void) +{ + unsigned long prev_end = VMALLOC_START; + struct vm_struct* vma; + struct vmalloc_info vmi; + vmi.used = 0; + + read_lock(&vmlist_lock); + + if(!vmlist) + vmi.largest_chunk = (VMALLOC_END-VMALLOC_START); + else + vmi.largest_chunk = 0; + + for (vma = vmlist; vma; vma = vma->next) { + unsigned long free_area_size = + (unsigned long)vma->addr - prev_end; + vmi.used += vma->size; + if (vmi.largest_chunk < free_area_size ) + vmi.largest_chunk = free_area_size; + prev_end = vma->size + (unsigned long)vma->addr; + } + if(VMALLOC_END-prev_end > vmi.largest_chunk) + vmi.largest_chunk = VMALLOC_END-prev_end; + + read_unlock(&vmlist_lock); + return vmi; +} + extern atomic_t vm_committed_space; static int meminfo_read_proc(char *page, char **start, off_t off, @@ -138,6 +173,8 @@ struct page_state ps; unsigned long inactive; unsigned long active; + unsigned long vmtot; + struct vmalloc_info vmi; get_page_state(&ps); get_zone_counts(&active, &inactive); @@ -150,6 +187,11 @@ si_swapinfo(&i); committed = atomic_read(&vm_committed_space); + vmtot = (VMALLOC_END-VMALLOC_START)>>10; + vmi = get_vmalloc_info(); + vmi.used >>= 10; + vmi.largest_chunk >>= 10; + /* * Tagged format, for easy grepping and expansion. */ @@ -174,7 +216,10 @@ "Slab: %8lu kB\n" "Committed_AS: %8u kB\n" "PageTables: %8lu kB\n" - "ReverseMaps: %8lu\n", + "ReverseMaps: %8lu\n" + "VmalTotal: %8lu kB\n" + "VmalUsed: %8lu kB\n" + "VmalChunk: %8lu kB\n", K(i.totalram), K(i.freeram), K(i.sharedram), @@ -195,7 +240,10 @@ K(ps.nr_slab), K(committed), K(ps.nr_page_table_pages), - ps.nr_reverse_maps + ps.nr_reverse_maps, + vmtot, + vmi.used, + vmi.largest_chunk ); #ifdef CONFIG_HUGETLB_PAGE --------------010502070400000809040600-- --------------enig55ED74C752FF075D8DF4EEE1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9hgDgzEzj1xe3kRwRAnnSAJ9k24P5uAG4Vt4clXIAoJIaXStaJwCfbGOX fYjGEmkIOfEBLzm5wtbktWA= =BQRo -----END PGP SIGNATURE----- --------------enig55ED74C752FF075D8DF4EEE1-- From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:06:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:06:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GG6DtG004211 for ; Mon, 16 Sep 2002 09:06:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA43698 for ; Mon, 16 Sep 2002 11:11:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA95115 for ; Mon, 16 Sep 2002 11:11:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8GG7f818454; Mon, 16 Sep 2002 11:07:41 -0500 Message-Id: <200209161607.g8GG7f818454@jen.americas.sgi.com> Date: Mon, 16 Sep 2002 11:07:41 -0500 Subject: TAKE - merge xfs up to 2.5.35 To: linux-xfs@oss.sgi.com X-archive-position: 403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The xfs part of the change, rest of the kernel comes in the next message. Date: Mon Sep 16 09:10:25 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127481a linux/fs/xfs/linux/xfs_lrw.c - 1.166 linux/fs/xfs/support/time.h - 1.7 linux/fs/xfs/linux/xfs_aops.c - 1.5 From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:13:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:13:25 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGDLtG005063 for ; Mon, 16 Sep 2002 09:13:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA43819 for ; Mon, 16 Sep 2002 11:18:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA43294 for ; Mon, 16 Sep 2002 11:18:10 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8GGEqc18523; Mon, 16 Sep 2002 11:14:52 -0500 Message-Id: <200209161614.g8GGEqc18523@jen.americas.sgi.com> Date: Mon, 16 Sep 2002 11:14:52 -0500 Subject: TAKE - merge xfs up to 2.5.35 To: linux-xfs@oss.sgi.com X-archive-position: 404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The rest of the tree Date: Mon Sep 16 09:14:28 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127483a linux/drivers/ide/pci/pdc202xx.c - 1.1 linux/arch/um/os-Linux/tty.c - 1.1 linux/arch/um/ptproxy/Makefile - 1.1 linux/drivers/ide/setup-pci.c - 1.1 linux/drivers/ide/ppc/swarm.c - 1.1 linux/drivers/ide/ppc/pmac.c - 1.1 linux/drivers/ide/ppc/mpc8xx.c - 1.1 linux/drivers/ide/ppc/Makefile - 1.1 linux/include/asm-ppc64/hvcall.h - 1.1 linux/drivers/ide/pci/via82cxxx.h - 1.1 linux/drivers/ide/pci/via82cxxx.c - 1.1 linux/drivers/ide/pci/trm290.h - 1.1 linux/drivers/ide/pci/trm290.c - 1.1 linux/drivers/ide/pci/slc90e66.h - 1.1 linux/drivers/ide/pci/slc90e66.c - 1.1 linux/drivers/ide/pci/sl82c105.h - 1.1 linux/drivers/ide/pci/sl82c105.c - 1.1 linux/drivers/ide/pci/sis5513.h - 1.1 linux/drivers/ide/pci/sis5513.c - 1.1 linux/drivers/ide/pci/siimage.h - 1.1 linux/drivers/ide/pci/siimage.c - 1.1 linux/drivers/ide/pci/serverworks.h - 1.1 linux/drivers/ide/pci/serverworks.c - 1.1 linux/drivers/ide/pci/rz1000.h - 1.1 linux/drivers/ide/pci/rz1000.c - 1.1 linux/drivers/ide/pci/piix.h - 1.1 linux/drivers/ide/pci/piix.c - 1.1 linux/drivers/ide/pci/pdcadma.h - 1.1 linux/drivers/ide/pci/pdcadma.c - 1.1 linux/drivers/ide/pci/pdc202xx_old.h - 1.1 linux/drivers/ide/pci/pdc202xx_old.c - 1.1 linux/drivers/ide/pci/pdc202xx_new.h - 1.1 linux/drivers/ide/pci/pdc202xx_new.c - 1.1 linux/drivers/ide/pci/pdc202xx.h - 1.1 linux/include/asm-ppc64/kmap_types.h - 1.1 linux/drivers/ide/pci/opti621.h - 1.1 linux/drivers/ide/pci/opti621.c - 1.1 linux/drivers/ide/pci/nvidia.h - 1.1 linux/drivers/ide/pci/nvidia.c - 1.1 linux/drivers/ide/pci/ns87415.h - 1.1 linux/drivers/ide/pci/ns87415.c - 1.1 linux/drivers/ide/pci/it8172.h - 1.1 linux/drivers/ide/pci/it8172.c - 1.1 linux/drivers/ide/pci/hpt366.h - 1.1 linux/drivers/ide/pci/hpt366.c - 1.1 linux/drivers/ide/pci/hpt34x.h - 1.1 linux/drivers/ide/pci/hpt34x.c - 1.1 linux/drivers/ide/pci/generic.h - 1.1 linux/drivers/ide/pci/generic.c - 1.1 linux/drivers/ide/pci/cy82c693.h - 1.1 linux/drivers/ide/pci/cy82c693.c - 1.1 linux/drivers/ide/pci/cs5530.h - 1.1 linux/drivers/ide/pci/cs5530.c - 1.1 linux/drivers/ide/pci/cmd64x.h - 1.1 linux/drivers/ide/pci/cmd64x.c - 1.1 linux/include/asm-um/vga.h - 1.1 linux/include/asm-um/user.h - 1.1 linux/include/asm-um/unistd.h - 1.1 linux/include/asm-um/unaligned.h - 1.1 linux/include/asm-um/uaccess.h - 1.1 linux/include/asm-um/types.h - 1.1 linux/include/asm-um/tlbflush.h - 1.1 linux/include/asm-um/tlb.h - 1.1 linux/include/asm-um/timex.h - 1.1 linux/include/asm-um/thread_info.h - 1.1 linux/include/asm-um/termios.h - 1.1 linux/include/asm-um/termbits.h - 1.1 linux/include/asm-um/system-ppc.h - 1.1 linux/include/asm-um/system-i386.h - 1.1 linux/include/asm-um/system-generic.h - 1.1 linux/include/asm-um/suspend.h - 1.1 linux/include/asm-um/string.h - 1.1 linux/include/asm-um/statfs.h - 1.1 linux/include/asm-um/stat.h - 1.1 linux/include/asm-um/spinlock.h - 1.1 linux/include/asm-um/softirq.h - 1.1 linux/include/asm-um/sockios.h - 1.1 linux/include/asm-um/socket.h - 1.1 linux/include/asm-um/smplock.h - 1.1 linux/include/asm-um/smp.h - 1.1 linux/include/asm-um/signal.h - 1.1 linux/drivers/ide/pci/cmd640.h - 1.1 linux/drivers/ide/pci/cmd640.c - 1.1 linux/drivers/ide/pci/amd74xx.h - 1.1 linux/drivers/ide/pci/amd74xx.c - 1.1 linux/drivers/ide/pci/alim15x3.h - 1.1 linux/drivers/ide/pci/alim15x3.c - 1.1 linux/drivers/ide/pci/aec62xx.h - 1.1 linux/drivers/ide/pci/aec62xx.c - 1.1 linux/drivers/ide/pci/adma100.h - 1.1 linux/drivers/ide/pci/adma100.c - 1.1 linux/drivers/ide/pci/Makefile - 1.1 linux/drivers/ide/legacy/umc8672.c - 1.1 linux/drivers/ide/legacy/qd65xx.h - 1.1 linux/drivers/ide/legacy/qd65xx.c - 1.1 linux/drivers/ide/legacy/q40ide.c - 1.1 linux/drivers/ide/legacy/pdc4030.h - 1.1 linux/drivers/ide/legacy/pdc4030.c - 1.1 linux/drivers/ide/legacy/macide.c - 1.1 linux/drivers/ide/legacy/ide-cs.c - 1.1 linux/drivers/ide/legacy/ht6560b.c - 1.1 linux/drivers/ide/legacy/hd.c - 1.1 linux/drivers/ide/legacy/gayle.c - 1.1 linux/drivers/ide/legacy/falconide.c - 1.1 linux/include/asm-um/siginfo.h - 1.1 linux/include/asm-um/sigcontext-ppc.h - 1.1 linux/drivers/ide/legacy/dtc2278.c - 1.1 linux/drivers/ide/legacy/buddha.c - 1.1 linux/drivers/ide/legacy/ali14xx.c - 1.1 linux/drivers/ide/legacy/Makefile - 1.1 linux/include/asm-um/a.out.h - 1.1 linux/include/asm-um/arch-signal-i386.h - 1.1 linux/include/asm-um/archparam-i386.h - 1.1 linux/include/asm-um/archparam-ppc.h - 1.1 linux/drivers/ide/ide-lib.c - 1.1 linux/arch/um/Makefile - 1.1 linux/arch/um/Makefile-i386 - 1.1 linux/arch/um/Makefile-ia64 - 1.1 linux/arch/um/Makefile-os-Linux - 1.1 linux/arch/um/Makefile-ppc - 1.1 linux/arch/um/boot/Makefile - 1.1 linux/arch/um/config.in - 1.1 linux/arch/um/config.release - 1.1 linux/arch/um/config_block.in - 1.1 linux/arch/um/config_char.in - 1.1 linux/arch/um/config_net.in - 1.1 linux/arch/um/config_scsi.in - 1.1 linux/arch/um/defconfig - 1.1 linux/arch/um/drivers/Makefile - 1.1 linux/arch/um/drivers/chan_kern.c - 1.1 linux/arch/um/drivers/chan_user.c - 1.1 linux/arch/um/drivers/daemon.h - 1.1 linux/arch/um/drivers/daemon_kern.c - 1.1 linux/arch/um/drivers/daemon_kern.h - 1.1 linux/arch/um/drivers/daemon_user.c - 1.1 linux/arch/um/drivers/fd.c - 1.1 linux/arch/um/drivers/harddog_kern.c - 1.1 linux/arch/um/drivers/harddog_user.c - 1.1 linux/arch/um/drivers/hostaudio_kern.c - 1.1 linux/arch/um/drivers/hostaudio_user.c - 1.1 linux/arch/um/drivers/line.c - 1.1 linux/arch/um/drivers/mcast.h - 1.1 linux/arch/um/drivers/mcast_kern.c - 1.1 linux/arch/um/drivers/mcast_kern.h - 1.1 linux/arch/um/drivers/mcast_user.c - 1.1 linux/arch/um/drivers/mconsole_kern.c - 1.1 linux/arch/um/drivers/mconsole_user.c - 1.1 linux/arch/um/drivers/mmapper_kern.c - 1.1 linux/arch/um/drivers/net_kern.c - 1.1 linux/arch/um/drivers/net_user.c - 1.1 linux/arch/um/drivers/null.c - 1.1 linux/arch/um/drivers/port.h - 1.1 linux/arch/um/drivers/port_kern.c - 1.1 linux/arch/um/drivers/port_user.c - 1.1 linux/arch/um/drivers/pty.c - 1.1 linux/arch/um/drivers/slip.h - 1.1 linux/arch/um/drivers/slip_kern.c - 1.1 linux/arch/um/drivers/slip_kern.h - 1.1 linux/arch/um/drivers/slip_user.c - 1.1 linux/arch/um/drivers/ssl.c - 1.1 linux/arch/um/drivers/ssl.h - 1.1 linux/arch/um/drivers/stdio_console.c - 1.1 linux/arch/um/drivers/stdio_console.h - 1.1 linux/arch/um/drivers/tty.c - 1.1 linux/arch/um/drivers/ubd_kern.c - 1.1 linux/arch/um/drivers/ubd_user.c - 1.1 linux/arch/um/drivers/xterm.c - 1.1 linux/arch/um/include/2_5compat.h - 1.1 linux/arch/um/include/Makefile - 1.1 linux/arch/um/include/chan_kern.h - 1.1 linux/arch/um/include/chan_user.h - 1.1 linux/arch/um/include/debug.h - 1.1 linux/arch/um/include/frame.h - 1.1 linux/arch/um/include/frame_kern.h - 1.1 linux/arch/um/include/frame_user.h - 1.1 linux/arch/um/include/helper.h - 1.1 linux/arch/um/include/hostaudio.h - 1.1 linux/arch/um/include/init.h - 1.1 linux/arch/um/include/initrd.h - 1.1 linux/arch/um/include/irq_user.h - 1.1 linux/arch/um/include/kern.h - 1.1 linux/arch/um/include/kern_util.h - 1.1 linux/arch/um/include/line.h - 1.1 linux/arch/um/include/mconsole.h - 1.1 linux/arch/um/include/mconsole_kern.h - 1.1 linux/arch/um/include/mem.h - 1.1 linux/arch/um/include/mem_user.h - 1.1 linux/arch/um/include/net_kern.h - 1.1 linux/arch/um/include/net_user.h - 1.1 linux/arch/um/include/os.h - 1.1 linux/arch/um/include/process.h - 1.1 linux/arch/um/include/ptrace_user.h - 1.1 linux/arch/um/include/sigcontext.h - 1.1 linux/arch/um/include/sigio.h - 1.1 linux/arch/um/include/signal_kern.h - 1.1 linux/arch/um/include/signal_user.h - 1.1 linux/arch/um/include/syscall_user.h - 1.1 linux/arch/um/include/sysdep-i386/frame.h - 1.1 linux/arch/um/include/sysdep-i386/frame_kern.h - 1.1 linux/arch/um/include/sysdep-i386/frame_user.h - 1.1 linux/arch/um/include/sysdep-i386/ptrace.h - 1.1 linux/arch/um/include/sysdep-i386/ptrace_user.h - 1.1 linux/arch/um/include/sysdep-i386/sigcontext.h - 1.1 linux/arch/um/include/sysdep-i386/syscalls.h - 1.1 linux/arch/um/include/sysdep-ia64/ptrace.h - 1.1 linux/arch/um/include/sysdep-ia64/sigcontext.h - 1.1 linux/arch/um/include/sysdep-ia64/syscalls.h - 1.1 linux/arch/um/include/sysdep-ppc/ptrace.h - 1.1 linux/arch/um/include/sysdep-ppc/sigcontext.h - 1.1 linux/arch/um/include/sysdep-ppc/syscalls.h - 1.1 linux/arch/um/include/sysrq.h - 1.1 linux/arch/um/include/tlb.h - 1.1 linux/arch/um/include/ubd_user.h - 1.1 linux/arch/um/include/umid.h - 1.1 linux/arch/um/include/umn.h - 1.1 linux/arch/um/include/user.h - 1.1 linux/arch/um/include/user_util.h - 1.1 linux/arch/um/kernel/Makefile - 1.1 linux/arch/um/kernel/config.c.in - 1.1 linux/arch/um/kernel/exec_kern.c - 1.1 linux/arch/um/kernel/exec_user.c - 1.1 linux/arch/um/kernel/exitcode.c - 1.1 linux/arch/um/kernel/frame.c - 1.1 linux/arch/um/kernel/frame_kern.c - 1.1 linux/arch/um/kernel/gmon_syms.c - 1.1 linux/arch/um/kernel/gprof_syms.c - 1.1 linux/arch/um/kernel/helper.c - 1.1 linux/arch/um/kernel/init_task.c - 1.1 linux/arch/um/kernel/initrd_kern.c - 1.1 linux/arch/um/kernel/initrd_user.c - 1.1 linux/arch/um/kernel/irq.c - 1.1 linux/arch/um/kernel/irq_user.c - 1.1 linux/arch/um/kernel/ksyms.c - 1.1 linux/arch/um/kernel/mem.c - 1.1 linux/arch/um/kernel/mem_user.c - 1.1 linux/arch/um/kernel/mprot.h - 1.1 linux/arch/um/kernel/process.c - 1.1 linux/arch/um/kernel/process_kern.c - 1.1 linux/arch/um/kernel/ptrace.c - 1.1 linux/arch/um/kernel/reboot.c - 1.1 linux/arch/um/kernel/resource.c - 1.1 linux/arch/um/kernel/setup.c - 1.1 linux/arch/um/kernel/sigio_kern.c - 1.1 linux/arch/um/kernel/sigio_user.c - 1.1 linux/arch/um/kernel/signal_kern.c - 1.1 linux/arch/um/kernel/signal_user.c - 1.1 linux/arch/um/kernel/smp.c - 1.1 linux/arch/um/kernel/sys_call_table.c - 1.1 linux/arch/um/kernel/syscall_kern.c - 1.1 linux/arch/um/kernel/syscall_user.c - 1.1 linux/arch/um/kernel/sysrq.c - 1.1 linux/arch/um/kernel/time.c - 1.1 linux/arch/um/kernel/time_kern.c - 1.1 linux/arch/um/kernel/tlb.c - 1.1 linux/arch/um/kernel/trap_kern.c - 1.1 linux/arch/um/kernel/trap_user.c - 1.1 linux/arch/um/kernel/tty_log.c - 1.1 linux/arch/um/kernel/uaccess_user.c - 1.1 linux/arch/um/kernel/um_arch.c - 1.1 linux/arch/um/kernel/umid.c - 1.1 linux/arch/um/kernel/unmap.c - 1.1 linux/arch/um/kernel/user_syms.c - 1.1 linux/arch/um/kernel/user_util.c - 1.1 linux/arch/um/link.ld.in - 1.1 linux/arch/um/main.c - 1.1 linux/arch/um/os-Linux/Makefile - 1.1 linux/arch/um/os-Linux/drivers/Makefile - 1.1 linux/arch/um/os-Linux/drivers/etap.h - 1.1 linux/arch/um/os-Linux/drivers/etap_kern.h - 1.1 linux/arch/um/os-Linux/drivers/ethertap_kern.c - 1.1 linux/arch/um/os-Linux/drivers/ethertap_user.c - 1.1 linux/arch/um/os-Linux/drivers/tuntap.h - 1.1 linux/arch/um/os-Linux/drivers/tuntap_kern.c - 1.1 linux/arch/um/os-Linux/drivers/tuntap_kern.h - 1.1 linux/arch/um/os-Linux/drivers/tuntap_user.c - 1.1 linux/arch/um/os-Linux/file.c - 1.1 linux/arch/um/os-Linux/include/file.h - 1.1 linux/arch/um/os-Linux/process.c - 1.1 linux/arch/um/sys-i386/ksyms.c - 1.1 linux/drivers/ide/ide-iops.c - 1.1 linux/arch/um/ptproxy/proxy.c - 1.1 linux/arch/um/ptproxy/ptproxy.h - 1.1 linux/arch/um/ptproxy/ptrace.c - 1.1 linux/arch/um/ptproxy/sysdep.c - 1.1 linux/arch/um/ptproxy/sysdep.h - 1.1 linux/arch/um/ptproxy/wait.c - 1.1 linux/arch/um/ptproxy/wait.h - 1.1 linux/arch/um/sys-i386/Makefile - 1.1 linux/arch/um/sys-i386/bugs.c - 1.1 linux/arch/um/sys-i386/fault.c - 1.1 linux/include/asm-um/pgtable.h - 1.1 linux/arch/um/sys-i386/ldt.c - 1.1 linux/arch/um/sys-i386/ptrace.c - 1.1 linux/arch/um/sys-i386/ptrace_user.c - 1.1 linux/arch/um/sys-i386/sigcontext.c - 1.1 linux/arch/um/sys-i386/syscalls.c - 1.1 linux/arch/um/sys-i386/sysrq.c - 1.1 linux/arch/um/sys-i386/util/Makefile - 1.1 linux/arch/um/sys-i386/util/mk_sc.c - 1.1 linux/arch/um/sys-i386/util/mk_thread_kern.c - 1.1 linux/arch/um/sys-i386/util/mk_thread_user.c - 1.1 linux/arch/um/sys-ia64/Makefile - 1.1 linux/arch/um/sys-ppc/Makefile - 1.1 linux/arch/um/sys-ppc/misc.S - 1.1 linux/arch/um/sys-ppc/miscthings.c - 1.1 linux/arch/um/sys-ppc/ptrace.c - 1.1 linux/arch/um/sys-ppc/ptrace_user.c - 1.1 linux/arch/um/sys-ppc/sigcontext.c - 1.1 linux/arch/um/sys-ppc/sysrq.c - 1.1 linux/arch/um/util/Makefile - 1.1 linux/arch/um/util/mk_task_kern.c - 1.1 linux/arch/um/util/mk_task_user.c - 1.1 linux/include/asm-um/sigcontext-i386.h - 1.1 linux/include/asm-um/sigcontext-generic.h - 1.1 linux/include/asm-um/shmparam.h - 1.1 linux/include/asm-um/shmbuf.h - 1.1 linux/include/asm-um/serial.h - 1.1 linux/include/asm-um/sembuf.h - 1.1 linux/include/asm-um/semaphore.h - 1.1 linux/include/asm-um/segment.h - 1.1 linux/include/asm-um/scatterlist.h - 1.1 linux/include/asm-um/rwsem.h - 1.1 linux/include/asm-um/rwlock.h - 1.1 linux/include/asm-um/rmap.h - 1.1 linux/include/asm-um/resource.h - 1.1 linux/include/asm-um/ptrace-i386.h - 1.1 linux/include/asm-um/ptrace-generic.h - 1.1 linux/include/asm-um/processor-ppc.h - 1.1 linux/include/asm-um/processor-i386.h - 1.1 linux/include/asm-um/processor-generic.h - 1.1 linux/include/asm-um/posix_types.h - 1.1 linux/include/asm-um/poll.h - 1.1 linux/include/asm-um/bitops.h - 1.1 linux/include/asm-um/pgalloc.h - 1.1 linux/include/asm-um/percpu.h - 1.1 linux/include/asm-um/pci.h - 1.1 linux/include/asm-um/param.h - 1.1 linux/include/asm-um/atomic.h - 1.1 linux/include/asm-um/locks.h - 1.1 linux/include/asm-um/boot.h - 1.1 linux/include/asm-um/page_offset.h - 1.1 linux/include/asm-um/bugs.h - 1.1 linux/include/asm-um/byteorder.h - 1.1 linux/include/asm-um/page.h - 1.1 linux/include/asm-um/cache.h - 1.1 linux/include/asm-um/cacheflush.h - 1.1 linux/include/asm-um/checksum.h - 1.1 linux/include/asm-um/namei.h - 1.1 linux/include/asm-um/cobalt.h - 1.1 linux/include/asm-um/current.h - 1.1 linux/include/asm-um/mtrr.h - 1.1 linux/include/asm-um/msgbuf.h - 1.1 linux/include/asm-um/delay.h - 1.1 linux/include/asm-um/module.h - 1.1 linux/include/asm-um/desc.h - 1.1 linux/include/asm-um/mmu_context.h - 1.1 linux/include/asm-um/mmu.h - 1.1 linux/include/asm-um/mman.h - 1.1 linux/include/asm-um/mca_dma.h - 1.1 linux/include/asm-um/kmap_types.h - 1.1 linux/include/asm-um/linux_logo.h - 1.1 linux/include/asm-um/linkage.h - 1.1 linux/include/asm-um/hw_irq.h - 1.1 linux/include/asm-um/keyboard.h - 1.1 linux/include/asm-um/irq_vectors.h - 1.1 linux/include/asm-um/irq.h - 1.1 linux/include/asm-um/ipcbuf.h - 1.1 linux/include/asm-um/ipc.h - 1.1 linux/include/asm-um/ioctls.h - 1.1 linux/include/asm-um/ioctl.h - 1.1 linux/include/asm-um/io.h - 1.1 linux/include/asm-um/init.h - 1.1 linux/include/asm-um/ide.h - 1.1 linux/include/asm-um/highmem.h - 1.1 linux/include/asm-um/div64.h - 1.1 linux/drivers/ide/arm/Makefile - 1.1 linux/drivers/ide/arm/icside.c - 1.1 linux/drivers/ide/arm/rapide.c - 1.1 linux/include/asm-um/hdreg.h - 1.1 linux/include/asm-um/hardirq.h - 1.1 linux/include/asm-um/floppy.h - 1.1 linux/include/asm-um/fcntl.h - 1.1 linux/include/asm-um/errno.h - 1.1 linux/include/asm-um/elf.h - 1.1 linux/include/asm-um/dma.h - 1.1 linux/net/ipv4/tcp_input.c - 1.41 linux/net/ipv4/ip_options.c - 1.7 linux/net/core/dev.c - 1.59 linux/net/802/psnap.c - 1.9 linux/net/802/p8022.c - 1.10 linux/mm/vmscan.c - 1.111 linux/mm/swap_state.c - 1.48 linux/mm/swap.c - 1.25 linux/mm/page_alloc.c - 1.90 linux/mm/filemap.c - 1.133 linux/kernel/time.c - 1.12 linux/kernel/sys.c - 1.39 linux/kernel/softirq.c - 1.29 linux/kernel/signal.c - 1.40 linux/kernel/sched.c - 1.81 linux/kernel/ksyms.c - 1.163 linux/kernel/fork.c - 1.69 linux/kernel/exit.c - 1.53 linux/kernel/capability.c - 1.10 linux/ipc/shm.c - 1.57 linux/init/main.c - 1.90 linux/include/linux/uio.h - 1.3 linux/include/linux/timex.h - 1.6 linux/include/linux/time.h - 1.8 linux/include/linux/serial.h - 1.16 linux/include/linux/sched.h - 1.82 linux/include/linux/pci.h - 1.64 linux/include/linux/nfsd/nfsfh.h - 1.14 linux/include/linux/nfsd/export.h - 1.14 linux/include/linux/nfsd/auth.h - 1.3 linux/include/linux/mm.h - 1.99 linux/include/linux/lockd/xdr.h - 1.6 linux/include/linux/lockd/sm_inter.h - 1.3 linux/include/linux/lockd/lockd.h - 1.8 linux/include/linux/lockd/bind.h - 1.4 linux/include/linux/hdreg.h - 1.27 linux/include/linux/fs.h - 1.190 linux/include/linux/blkdev.h - 1.67 linux/include/linux/atari_rootsec.h - 1.3 linux/include/asm-sparc64/unistd.h - 1.24 linux/include/asm-sparc64/spinlock.h - 1.13 linux/include/asm-sparc64/pgtable.h - 1.38 linux/include/asm-sparc64/ide.h - 1.17 linux/include/asm-sparc64/hardirq.h - 1.18 linux/include/asm-sparc/unistd.h - 1.22 linux/include/asm-sparc/system.h - 1.14 linux/include/asm-sparc/spinlock.h - 1.11 linux/include/asm-sparc/pgtable.h - 1.29 linux/include/asm-sparc/irq.h - 1.9 linux/include/asm-sparc/hardirq.h - 1.15 linux/include/asm-ppc/unistd.h - 1.25 linux/include/asm-ppc/spinlock.h - 1.16 linux/include/asm-ppc/pgtable.h - 1.38 linux/include/asm-ppc/ide.h - 1.21 linux/include/asm-ppc/atomic.h - 1.11 linux/include/asm-mips/pgtable.h - 1.19 linux/include/asm-m68k/pgtable.h - 1.17 linux/include/asm-i386/unistd.h - 1.27 linux/include/asm-i386/pgtable.h - 1.38 linux/include/asm-i386/mtrr.h - 1.6 linux/include/asm-i386/ide.h - 1.13 linux/include/asm-i386/hardirq.h - 1.22 linux/include/asm-i386/fixmap.h - 1.11 linux/include/asm-arm/pgtable.h - 1.28 linux/include/asm-alpha/system.h - 1.23 linux/include/asm-alpha/signal.h - 1.5 linux/include/asm-alpha/pgtable.h - 1.37 linux/fs/ufs/super.c - 1.35 linux/fs/super.c - 1.92 linux/fs/read_write.c - 1.24 linux/fs/proc/inode.c - 1.25 linux/fs/proc/base.c - 1.42 linux/fs/nfsd/vfs.c - 1.56 linux/fs/nfsd/nfsfh.c - 1.45 linux/fs/nfsd/nfsctl.c - 1.34 linux/fs/nfsd/lockd.c - 1.11 linux/fs/nfsd/export.c - 1.40 linux/fs/nfs/symlink.c - 1.18 linux/fs/nfs/proc.c - 1.16 linux/fs/nfs/nfs3xdr.c - 1.14 linux/fs/nfs/nfs2xdr.c - 1.17 linux/fs/nfs/mount_clnt.c - 1.8 linux/fs/nfs/inode.c - 1.52 linux/fs/nfs/file.c - 1.35 linux/fs/nfs/dir.c - 1.44 linux/fs/locks.c - 1.32 linux/fs/lockd/xdr.c - 1.15 linux/fs/lockd/svcsubs.c - 1.10 linux/fs/lockd/svcproc.c - 1.13 linux/fs/lockd/svclock.c - 1.16 linux/fs/lockd/svc.c - 1.20 linux/fs/lockd/mon.c - 1.11 linux/fs/lockd/lockd_syms.c - 1.7 linux/fs/lockd/host.c - 1.9 linux/fs/lockd/clntlock.c - 1.13 linux/fs/inode.c - 1.81 linux/fs/fcntl.c - 1.25 linux/fs/ext2/inode.c - 1.53 linux/fs/ext2/file.c - 1.22 linux/fs/exec.c - 1.64 linux/fs/buffer.c - 1.133 linux/fs/block_dev.c - 1.58 linux/drivers/scsi/ide-scsi.c - 1.45 linux/drivers/pci/proc.c - 1.29 linux/drivers/pci/pci.c - 1.61 linux/drivers/pci/Makefile - 1.24 linux/drivers/net/ni65.c - 1.16 linux/drivers/net/hamradio/scc.c - 1.26 linux/drivers/net/de600.c - 1.18 linux/drivers/net/at1700.c - 1.20 linux/drivers/net/apne.c - 1.11 linux/drivers/net/3c505.c - 1.28 linux/drivers/char/tty_io.c - 1.51 linux/drivers/char/sysrq.c - 1.28 linux/drivers/char/lp.c - 1.34 linux/drivers/char/keyboard.c - 1.28 linux/drivers/char/ftape/zftape/zftape_syms.c - 1.4 linux/drivers/char/ftape/lowlevel/ftape_syms.c - 1.4 linux/drivers/char/ftape/lowlevel/Makefile - 1.6 linux/drivers/char/Makefile - 1.72 linux/drivers/char/Config.in - 1.66 linux/drivers/cdrom/cdrom.c - 1.46 linux/drivers/block/ll_rw_blk.c - 1.112 linux/drivers/block/floppy.c - 1.48 linux/arch/sparc64/prom/misc.c - 1.14 linux/arch/sparc64/mm/init.c - 1.49 linux/arch/sparc64/kernel/time.c - 1.23 linux/arch/sparc64/kernel/systbls.S - 1.32 linux/arch/sparc64/kernel/sys_sparc32.c - 1.56 linux/arch/sparc64/kernel/signal32.c - 1.26 linux/arch/sparc64/kernel/signal.c - 1.24 linux/arch/sparc64/kernel/setup.c - 1.34 linux/arch/sparc64/kernel/process.c - 1.41 linux/arch/sparc64/kernel/init_task.c - 1.9 linux/arch/sparc64/kernel/entry.S - 1.27 linux/arch/sparc64/defconfig - 1.75 linux/arch/sparc/prom/misc.c - 1.5 linux/arch/sparc/mm/sun4c.c - 1.37 linux/arch/sparc/mm/srmmu.c - 1.37 linux/arch/sparc/kernel/unaligned.c - 1.8 linux/arch/sparc/kernel/time.c - 1.19 linux/arch/sparc/kernel/tick14.c - 1.3 linux/arch/sparc/kernel/tadpole.c - 1.4 linux/arch/sparc/kernel/systbls.S - 1.26 linux/arch/sparc/kernel/sparc-stub.c - 1.10 linux/arch/sparc/kernel/signal.c - 1.27 linux/arch/sparc/kernel/setup.c - 1.25 linux/arch/sparc/kernel/process.c - 1.31 linux/arch/sparc/kernel/pcic.c - 1.23 linux/arch/sparc/kernel/init_task.c - 1.8 linux/arch/sparc/kernel/entry.S - 1.14 linux/arch/sparc/kernel/ebus.c - 1.15 linux/arch/sparc/kernel/check_asm.sh - 1.7 linux/arch/sparc/kernel/Makefile - 1.17 linux/arch/sparc/defconfig - 1.34 linux/arch/sparc/config.in - 1.43 linux/arch/ppc/kernel/time.c - 1.21 linux/arch/ppc/kernel/setup.c - 1.50 linux/arch/ppc/kernel/process.c - 1.42 linux/arch/ppc/kernel/pci.c - 1.29 linux/arch/ppc/kernel/misc.S - 1.46 linux/arch/ppc/kernel/irq.c - 1.39 linux/arch/i386/kernel/vm86.c - 1.17 linux/arch/i386/kernel/time.c - 1.25 linux/arch/i386/kernel/io_apic.c - 1.44 linux/arch/i386/kernel/entry.S - 1.62 linux/arch/i386/config.in - 1.89 linux/arch/alpha/kernel/signal.c - 1.18 linux/arch/alpha/Makefile - 1.19 linux/Rules.make - 1.30 linux/Makefile - 1.216 linux/CREDITS - 1.87 linux/include/linux/ide.h - 1.62 linux/include/asm-ppc/hdreg.h - 1.3 linux/include/asm-i386/hdreg.h - 1.2 linux/include/asm-arm/hdreg.h - 1.3 linux/include/asm-alpha/hdreg.h - 1.2 linux/drivers/char/dz.c - 1.16 linux/drivers/char/raw.c - 1.28 linux/include/asm-i386/apic.h - 1.18 linux/fs/partitions/check.c - 1.51 linux/arch/alpha/kernel/pci.c - 1.23 linux/arch/sparc64/kernel/power.c - 1.10 linux/arch/sparc64/kernel/pci.c - 1.30 linux/arch/sh/Makefile - 1.12 linux/include/asm-sh/pgtable.h - 1.26 linux/include/asm-i386/kmap_types.h - 1.11 linux/fs/udf/udfdecl.h - 1.21 linux/include/linux/acpi.h - 1.28 linux/arch/i386/kernel/smpboot.c - 1.46 linux/include/linux/pci_ids.h - 1.73 linux/drivers/net/pcmcia/3c574_cs.c - 1.20 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.17 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.16 linux/include/linux/highmem.h - 1.26 linux/include/asm-sh/hdreg.h - 1.3 linux/include/asm-i386/highmem.h - 1.14 linux/drivers/pci/pci.ids - 1.52 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.14 linux/kernel/timer.c - 1.29 linux/arch/i386/kernel/acpi.c - 1.29 linux/drivers/net/arcnet/arcnet.c - 1.13 linux/include/asm-sparc/ide.h - 1.14 linux/arch/ia64/Makefile - 1.18 linux/include/asm-ia64/pgtable.h - 1.19 linux/fs/lockd/xdr4.c - 1.10 linux/fs/lockd/svc4proc.c - 1.9 linux/include/asm-mips64/pgtable.h - 1.15 linux/arch/mips64/Makefile - 1.12 linux/drivers/ide/via82cxxx.c - 1.34 linux/drivers/ide/umc8672.c - 1.10 linux/drivers/ide/trm290.c - 1.17 linux/drivers/ide/sl82c105.c - 1.17 linux/drivers/ide/sis5513.c - 1.25 linux/drivers/ide/rz1000.c - 1.11 linux/drivers/ide/rapide.c - 1.9 linux/drivers/ide/q40ide.c - 1.8 linux/drivers/ide/piix.c - 1.30 linux/drivers/ide/pdc4030.h - 1.3 linux/drivers/ide/pdc4030.c - 1.22 linux/drivers/ide/pdc202xx.c - 1.28 linux/drivers/ide/opti621.c - 1.16 linux/drivers/ide/ns87415.c - 1.15 linux/drivers/ide/macide.c - 1.7 linux/drivers/ide/ide_modes.h - 1.8 linux/drivers/ide/ide.c - 1.65 linux/drivers/ide/ide-tape.c - 1.36 linux/drivers/ide/ide-proc.c - 1.22 linux/drivers/ide/ide-probe.c - 1.36 linux/drivers/ide/ide-pnp.c - 1.10 linux/drivers/ide/ide-pmac.c - 1.22 linux/drivers/ide/ide-pci.c - 1.34 linux/drivers/ide/ide-geometry.c - 1.17 linux/drivers/ide/ide-floppy.c - 1.35 linux/drivers/ide/ide-dma.c - 1.29 linux/drivers/ide/ide-disk.c - 1.47 linux/drivers/ide/ide-cs.c - 1.13 linux/drivers/ide/ide-cd.c - 1.47 linux/drivers/ide/icside.c - 1.23 linux/drivers/ide/ht6560b.c - 1.14 linux/drivers/ide/hpt366.c - 1.25 linux/drivers/ide/hpt34x.c - 1.19 linux/drivers/ide/hd.c - 1.29 linux/drivers/ide/gayle.c - 1.10 linux/drivers/ide/falconide.c - 1.8 linux/drivers/ide/dtc2278.c - 1.12 linux/drivers/ide/cy82c693.c - 1.17 linux/drivers/ide/cs5530.c - 1.16 linux/drivers/ide/cmd64x.c - 1.21 linux/drivers/ide/cmd640.c - 1.15 linux/drivers/ide/buddha.c - 1.13 linux/drivers/ide/alim15x3.c - 1.22 linux/drivers/ide/ali14xx.c - 1.14 linux/drivers/ide/Makefile - 1.28 linux/drivers/ide/Config.in - 1.32 linux/Documentation/DocBook/kernel-api.tmpl - 1.22 linux/net/ipv4/netfilter/ipt_owner.c - 1.8 linux/fs/ramfs/inode.c - 1.30 linux/fs/nfs/nfs3proc.c - 1.14 linux/drivers/ide/aec62xx.c - 1.15 linux/drivers/s390/net/iucv.h - 1.5 linux/include/asm-s390/pgtable.h - 1.15 linux/drivers/usb/storage/usb.h - 1.16 linux/drivers/usb/storage/usb.c - 1.28 linux/drivers/usb/storage/transport.c - 1.26 linux/drivers/usb/storage/protocol.c - 1.10 linux/drivers/acpi/include/acpiosxf.h - 1.11 linux/include/asm-sparc/kmap_types.h - 1.9 linux/include/asm-sparc/highmem.h - 1.7 linux/drivers/input/input.c - 1.14 linux/drivers/md/raid5.c - 1.33 linux/drivers/char/toshiba.c - 1.5 linux/drivers/md/md.c - 1.54 linux/include/asm-ppc/highmem.h - 1.10 linux/drivers/ide/slc90e66.c - 1.11 linux/mm/oom_kill.c - 1.17 linux/drivers/usb/serial/belkin_sa.c - 1.23 linux/drivers/usb/serial/belkin_sa.h - 1.5 linux/include/asm-parisc/hdreg.h - 1.2 linux/include/asm-parisc/pgtable.h - 1.6 linux/mm/shmem.c - 1.45 linux/drivers/acpi/acpi_ksyms.c - 1.10 linux/drivers/usb/storage/unusual_devs.h - 1.12 linux/include/asm-s390x/pgtable.h - 1.11 linux/include/asm-cris/pgtable.h - 1.11 linux/drivers/acpi/Config.in - 1.8 linux/drivers/acpi/debugger/dbcmds.c - 1.9 linux/drivers/acpi/debugger/dbdisply.c - 1.10 linux/drivers/acpi/debugger/dbexec.c - 1.7 linux/drivers/acpi/debugger/dbfileio.c - 1.10 linux/drivers/acpi/debugger/dbhistry.c - 1.6 linux/drivers/acpi/debugger/dbinput.c - 1.7 linux/drivers/acpi/debugger/dbstats.c - 1.8 linux/drivers/acpi/debugger/dbutils.c - 1.8 linux/drivers/acpi/debugger/dbxface.c - 1.8 linux/drivers/ieee1394/sbp2.c - 1.10 linux/drivers/ide/serverworks.c - 1.17 linux/drivers/ide/it8172.c - 1.14 linux/drivers/ide/ide-adma.c - 1.4 linux/drivers/ide/amd74xx.c - 1.17 linux/arch/ppc/mm/pgtable.c - 1.8 linux/drivers/ide/qd65xx.h - 1.5 linux/drivers/ide/qd65xx.c - 1.13 linux/drivers/char/serial_tx3912.c - 1.6 linux/Documentation/input/ff.txt - 1.3 linux/drivers/md/multipath.c - 1.13 linux/drivers/acpi/kdb/README.txt - 1.2 linux/drivers/acpi/kdb/kdbm_acpi.c - 1.2 linux/drivers/acpi/debugger/Makefile - 1.4 linux/fs/namespace.c - 1.22 linux/drivers/ide/ide-m8xx.c - 1.7 linux/net/ipv6/netfilter/ip6t_owner.c - 1.2 linux/net/8021q/vlan.c - 1.5 linux/fs/ext3/file.c - 1.6 linux/fs/ext3/inode.c - 1.19 linux/drivers/hotplug/pci_hotplug.h - 1.2 linux/drivers/hotplug/cpqphp_proc.c - 1.4 linux/drivers/hotplug/cpqphp_pci.c - 1.5 linux/drivers/hotplug/cpqphp_nvram.c - 1.3 linux/drivers/hotplug/cpqphp_ctrl.c - 1.3 linux/drivers/hotplug/cpqphp_core.c - 1.6 linux/drivers/hotplug/cpqphp.h - 1.2 linux/include/linux/bio.h - 1.13 linux/fs/driverfs/inode.c - 1.21 linux/include/linux/init_task.h - 1.12 linux/drivers/ide/ide-taskfile.c - 1.20 linux/drivers/ide/pdcadma.c - 1.7 linux/drivers/char/Config.help - 1.10 linux/drivers/pnp/pnpbios_core.c - 1.12 linux/drivers/input/serio/serport.c - 1.5 linux/Documentation/filesystems/directory-locking - 1.3 linux/Documentation/filesystems/porting - 1.13 linux/arch/alpha/kernel/init_task.c - 1.2 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.5 linux/sound/pci/cs46xx/cs46xx.c - 1.10 linux/arch/ppc/platforms/pmac_time.c - 1.2 linux/arch/ppc/platforms/prep_pci.c - 1.4 linux/sound/oss/cs46xx.c - 1.4 linux/include/asm-x86_64/pgtable.h - 1.7 linux/include/asm-x86_64/ide.h - 1.6 linux/include/asm-x86_64/hdreg.h - 1.2 linux/include/asm-ppc64/hardirq.h - 1.5 linux/arch/ppc64/mm/fault.c - 1.5 linux/arch/ppc64/mm/init.c - 1.8 linux/include/asm-ppc64/elf.h - 1.3 linux/include/asm-ppc64/eeh.h - 1.3 linux/include/asm-ppc64/delay.h - 1.3 linux/include/asm-ppc64/io.h - 1.3 linux/arch/ppc64/config.in - 1.10 linux/arch/ppc64/defconfig - 1.8 linux/arch/ppc64/kernel/align.c - 1.4 linux/arch/ppc64/kernel/chrp_setup.c - 1.6 linux/arch/ppc64/kernel/eeh.c - 1.4 linux/arch/ppc64/kernel/entry.S - 1.7 linux/arch/ppc64/kernel/head.S - 1.6 linux/arch/ppc64/kernel/iSeries_pci.c - 1.5 linux/arch/ppc64/kernel/iSeries_setup.c - 1.6 linux/arch/ppc64/kernel/idle.c - 1.6 linux/arch/ppc64/kernel/init_task.c - 1.2 linux/arch/ppc64/kernel/ioctl32.c - 1.6 linux/arch/ppc64/kernel/irq.c - 1.6 linux/arch/ppc64/kernel/lmb.c - 1.3 linux/arch/ppc64/kernel/misc.S - 1.7 linux/arch/ppc64/kernel/mk_defs.c - 1.7 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.6 linux/arch/ppc64/kernel/pSeries_pci.c - 1.6 linux/arch/ppc64/kernel/pci.c - 1.5 linux/arch/ppc64/kernel/pci_dma.c - 1.4 linux/arch/ppc64/kernel/pci_dn.c - 1.4 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.7 linux/arch/ppc64/kernel/process.c - 1.7 linux/arch/ppc64/kernel/prom.c - 1.7 linux/arch/ppc64/kernel/ptrace.c - 1.3 linux/arch/ppc64/kernel/ptrace32.c - 1.4 linux/arch/ppc64/kernel/ras.c - 1.2 linux/arch/ppc64/kernel/rtas.c - 1.4 linux/arch/ppc64/kernel/setup.c - 1.7 linux/arch/ppc64/kernel/signal.c - 1.8 linux/arch/ppc64/kernel/smp.c - 1.9 linux/arch/ppc64/kernel/sys32.S - 1.3 linux/arch/ppc64/kernel/sys_ppc32.c - 1.7 linux/arch/ppc64/kernel/syscalls.c - 1.4 linux/arch/ppc64/kernel/time.c - 1.7 linux/arch/ppc64/kernel/traps.c - 1.6 linux/arch/ppc64/xmon/xmon.c - 1.6 linux/include/asm-ppc64/lmb.h - 1.4 linux/include/asm-ppc64/machdep.h - 1.6 linux/include/asm-ppc64/mmu.h - 1.5 linux/include/asm-ppc64/user.h - 1.2 linux/include/asm-ppc64/unistd.h - 1.6 linux/include/asm-ppc64/spinlock.h - 1.5 linux/include/asm-ppc64/smp.h - 1.5 linux/include/asm-ppc64/rtas.h - 1.4 linux/include/asm-ppc64/prom.h - 1.3 linux/include/asm-ppc64/processor.h - 1.8 linux/include/asm-ppc64/ppcdebug.h - 1.4 linux/include/asm-ppc64/pgtable.h - 1.6 linux/include/asm-ppc64/pgalloc.h - 1.6 linux/include/asm-ppc64/page.h - 1.7 linux/fs/jfs/jfs_metapage.h - 1.6 linux/drivers/hotplug/ibmphp_res.c - 1.3 linux/drivers/hotplug/ibmphp_pci.c - 1.2 linux/fs/jfs/jfs_logmgr.h - 1.8 linux/drivers/hotplug/ibmphp_hpc.c - 1.5 linux/drivers/hotplug/ibmphp_ebda.c - 1.4 linux/drivers/hotplug/ibmphp_core.c - 1.6 linux/drivers/hotplug/ibmphp.h - 1.3 linux/fs/jfs/file.c - 1.11 linux/fs/jfs/inode.c - 1.13 linux/fs/jfs/jfs_btree.h - 1.3 linux/fs/jfs/jfs_defragfs.h - 1.3 linux/fs/jfs/jfs_dinode.h - 1.3 linux/fs/jfs/jfs_dmap.c - 1.8 linux/fs/jfs/jfs_dmap.h - 1.3 linux/fs/jfs/jfs_dtree.c - 1.8 linux/fs/jfs/jfs_dtree.h - 1.4 linux/fs/jfs/jfs_extent.c - 1.5 linux/fs/jfs/jfs_incore.h - 1.10 linux/fs/jfs/jfs_imap.h - 1.5 linux/fs/jfs/jfs_imap.c - 1.8 linux/fs/jfs/jfs_filsys.h - 1.3 linux/fs/jfs/namei.c - 1.12 linux/fs/jfs/jfs_xtree.h - 1.3 linux/fs/jfs/jfs_xtree.c - 1.6 linux/fs/jfs/jfs_logmgr.c - 1.16 linux/fs/jfs/super.c - 1.14 linux/fs/jfs/jfs_mount.c - 1.10 linux/fs/jfs/jfs_txnmgr.c - 1.15 linux/fs/jfs/jfs_txnmgr.h - 1.5 linux/fs/jfs/jfs_types.h - 1.4 linux/fs/jfs/jfs_umount.c - 1.6 linux/fs/jfs/jfs_unicode.c - 1.3 linux/fs/jfs/jfs_unicode.h - 1.4 linux/fs/jfs/jfs_metapage.c - 1.11 linux/drivers/net/tg3.h - 1.9 linux/drivers/net/tg3.c - 1.10 linux/drivers/usb/image/microtek.c - 1.3 linux/drivers/usb/core/hcd.c - 1.10 linux/drivers/usb/core/inode.c - 1.8 linux/drivers/usb/host/ehci-dbg.c - 1.6 linux/drivers/usb/host/ehci-hcd.c - 1.8 linux/drivers/usb/host/ehci-hub.c - 1.4 linux/drivers/usb/host/ehci-q.c - 1.9 linux/drivers/usb/host/ehci-sched.c - 1.8 linux/drivers/usb/host/ehci.h - 1.4 linux/drivers/usb/host/ohci-dbg.c - 1.7 linux/drivers/usb/host/ohci-hcd.c - 1.10 linux/drivers/usb/host/ohci-mem.c - 1.4 linux/drivers/usb/host/ohci-q.c - 1.11 linux/drivers/usb/host/ohci.h - 1.7 linux/drivers/usb/image/hpusbscsi.c - 1.5 linux/drivers/usb/image/scanner.c - 1.9 linux/drivers/usb/media/se401.c - 1.8 linux/drivers/usb/media/se401.h - 1.2 linux/drivers/usb/net/usbnet.c - 1.9 linux/drivers/usb/net/pegasus.h - 1.6 linux/drivers/usb/net/kaweth.c - 1.8 linux/mm/pdflush.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.2 linux/scripts/mkcompile_h - 1.5 linux/drivers/usb/host/uhci-hcd.c - 1.8 linux/drivers/usb/host/uhci-hcd.h - 1.3 linux/arch/i386/pci/common.c - 1.5 linux/arch/i386/pci/i386.c - 1.2 linux/drivers/pci/hotplug.c - 1.4 linux/drivers/pci/probe.c - 1.6 linux/fs/fs-writeback.c - 1.6 linux/include/linux/page-flags.h - 1.8 linux/arch/i386/pci/pci.h - 1.3 linux/arch/i386/pci/visws.c - 1.2 linux/mm/page-writeback.c - 1.10 linux/include/linux/buffer_head.h - 1.9 linux/include/linux/backing-dev.h - 1.2 linux/kernel/suspend.c - 1.11 linux/fs/mpage.c - 1.7 linux/drivers/char/hvc_console.c - 1.5 linux/drivers/acpi/ac.c - 1.3 linux/drivers/acpi/battery.c - 1.4 linux/drivers/acpi/bus.c - 1.7 linux/drivers/acpi/pci_root.c - 1.5 linux/drivers/acpi/pci_link.c - 1.4 linux/drivers/acpi/button.c - 1.3 linux/drivers/acpi/pci_irq.c - 1.5 linux/drivers/acpi/system.c - 1.8 linux/drivers/acpi/osl.c - 1.5 linux/drivers/usb/class/usb-midi.c - 1.4 linux/arch/i386/kernel/cpu/intel.c - 1.5 linux/net/llc/llc_if.c - 1.4 linux/include/net/llc_sap.h - 1.3 linux/include/net/llc_if.h - 1.2 linux/include/net/llc_s_ev.h - 1.3 linux/include/net/llc_pdu.h - 1.4 linux/include/net/llc_main.h - 1.3 linux/include/linux/llc.h - 1.2 linux/net/llc/llc_sock.c - 1.3 linux/net/llc/llc_sap.c - 1.4 linux/net/llc/llc_s_ac.c - 1.3 linux/net/llc/llc_mac.c - 1.4 linux/include/net/llc_mac.h - 1.3 linux/net/llc/llc_actn.c - 1.3 linux/net/llc/llc_pdu.c - 1.4 linux/net/llc/llc_c_ac.c - 1.4 linux/net/llc/llc_c_ev.c - 1.4 linux/net/llc/llc_main.c - 1.4 linux/net/llc/llc_conn.c - 1.4 linux/include/net/llc_c_st.h - 1.2 linux/include/net/llc_c_ev.h - 1.3 linux/include/net/llc_conn.h - 1.3 linux/include/net/llc_evnt.h - 1.3 linux/drivers/acpi/toshiba_acpi.c - 1.2 linux/drivers/input/serio/i8042-io.h - 1.3 linux/drivers/input/serio/q40kbd.c - 1.3 linux/fs/direct-io.c - 1.5 linux/drivers/usb/input/hid-lgff.c - 1.3 linux/include/asm-ppc64/ptrace-common.h - 1.2 linux/mm/rmap.c - 1.6 linux/include/asm-generic/rmap.h - 1.2 linux/include/asm-i386/rmap.h - 1.2 linux/include/asm-ppc64/mmzone.h - 1.4 linux/fs/jfs/resize.c - 1.4 linux/drivers/serial/sunzilog.c - 1.2 linux/drivers/serial/sunsu.c - 1.2 linux/drivers/usb/misc/Config.in - 1.2 linux/include/linux/pagevec.h - 1.3 linux/drivers/input/misc/pcspkr.c - 1.2 linux/fs/aio.c - 1.3 linux/arch/i386/kernel/cpu/mtrr/generic.c - 1.2 linux/drivers/ide/ide-swarm.c - 1.2 linux/drivers/ide/adma100.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/cyrix.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/main.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/mtrr.h - 1.2 linux/arch/i386/kernel/cpu/mtrr/state.c - 1.2 linux/include/linux/aio.h - 1.2 linux/fs/jfs/jfs_xattr.h - 1.2 linux/fs/jfs/xattr.c - 1.3 linux/arch/i386/mm/discontig.c - 1.2 linux/arch/i386/kernel/numaq.c - 1.2 linux/include/asm-i386/mmzone.h - 1.2 linux/include/asm-i386/numaq.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:14:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:14:50 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGEktG005496 for ; Mon, 16 Sep 2002 09:14:47 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id SAA18016; Mon, 16 Sep 2002 18:52:16 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8GGKaoq000719; Mon, 16 Sep 2002 18:20:36 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8GGKA8Q008617; Mon, 16 Sep 2002 18:20:10 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8GGK1MU008616; Mon, 16 Sep 2002 18:20:01 +0200 Date: Mon, 16 Sep 2002 18:20:01 +0200 From: Andrea Arcangeli To: Dave Hansen Cc: Samuel Flory , Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020916162001.GK11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D8600DD.1010707@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8600DD.1010707@us.ibm.com> User-Agent: Mutt/1.3.27i X-archive-position: 405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 09:03:41AM -0700, Dave Hansen wrote: > + vmi = get_vmalloc_info(); hmm, not sure if it's better to slowdown vmalloc instead of /proc/meminfo and to keep meminfo o1. In theory vmalloc should be used only for persistent infrequent allocations, so meminfo has a chance to be recalled more frequently with monitors like xosview during workloads. Admittedly in final production with no monitoring meminfo is going to never be recalled, however I like the idea to keep meminfo very quick. Andrea From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:34:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:35:02 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGYutG006211 for ; Mon, 16 Sep 2002 09:34:57 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8GGdjlN195228; Mon, 16 Sep 2002 12:39:46 -0400 Received: from nighthawk.sr71.net (sig-9-65-11-88.mts.ibm.com [9.65.11.88]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8GGdfm5165384; Mon, 16 Sep 2002 12:39:42 -0400 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g8GGdWS00755; Mon, 16 Sep 2002 09:39:32 -0700 Message-ID: <3D860943.9070903@us.ibm.com> Date: Mon, 16 Sep 2002 09:39:31 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Samuel Flory , Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D8600DD.1010707@us.ibm.com> <20020916162001.GK11605@dualathlon.random> X-Enigmail-Version: 0.65.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: linux-xfs Andrea Arcangeli wrote: > On Mon, Sep 16, 2002 at 09:03:41AM -0700, Dave Hansen wrote: > >>+ vmi = get_vmalloc_info(); > > hmm, not sure if it's better to slowdown vmalloc instead of > /proc/meminfo and to keep meminfo o1. In theory vmalloc should be used > only for persistent infrequent allocations, so meminfo has a chance to > be recalled more frequently with monitors like xosview during workloads. > Admittedly in final production with no monitoring meminfo is going to > never be recalled, however I like the idea to keep meminfo very quick. When I first set out to do it, I modified vmalloc. But, I decided that it would probably be easier to get a patch in that didn't modify vmalloc itself. The used calculation is much easier (used += requested_size), but the largest free chunk gets harder to do. I think that this would have required vfree to get into the game as well. It seemed much easier to just make meminfo do a little more work. -- Dave Hansen haveblue@us.ibm.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:56:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:56:48 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGuitG006844 for ; Mon, 16 Sep 2002 09:56:44 -0700 Received: from vk-clued0.fnal.gov ([131.225.224.23]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0H2J00L8BJARFP@smtp.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 16 Sep 2002 12:01:39 -0500 (CDT) Date: Mon, 16 Sep 2002 12:01:39 -0500 (CDT) From: vkuznet Subject: XFS mount failure To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vkuznet@fnal.gov Precedence: bulk X-list: linux-xfs Hi, we do have 3Ware RAID machine where XFS is using. After unexpected reboot we cannot longer mount our XFS filesystem. Here the /var/log/messages Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold exceeded: Port #6. Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - can't mount Any idea how to fix the problem. We do have Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 i686 unknown patched kernel with XFS. Thanks, Valentin. P.S. could you please reply me directly I'm not currently in a mailing list. From owner-linux-xfs@oss.sgi.com Mon Sep 16 10:13:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 10:13:09 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GHD4tG007469 for ; Mon, 16 Sep 2002 10:13:04 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA43123; Mon, 16 Sep 2002 12:17:54 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-13.corp.sgi.com [134.15.64.13]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA61752; Mon, 16 Sep 2002 12:17:53 -0500 (CDT) Subject: RE: Re-occurance of NFS server panics From: Stephen Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 12:16:14 -0500 Message-Id: <1032196576.9808.149.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > Steve, > > Thanks for the quick response. I don't always get a Oops output > (sometimes the server just hangs and requires a reboot). However as it > happens the server has just crashed again with the following Oops > (through 'ksymoops'): This one suggests heap corruption more than anything else. Steve > > EFLAGS: 00010016 > eax: 5a2cf071 ebx: 003a0dc0 ecx: f7ee3dd0 edx: c200b060 > esi: ce837000 edi: ce8372b4 ebp: ce837ce0 esp: f7ee1f38 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=f7ee1000) > Stack: f7ee0000 00000009 f7ee3dd0 f7ee3c00 00000000 00000007 00000000 > 00000000 > 00000000 c200b060 00000020 000001d0 00000006 00000000 c01325d9 > c036aa70 > 00000006 000001d0 c036aa70 00000000 c013268c 00000020 c036aa70 > 00000002 > Call Trace: [] [] [] [] > [] > [] [] [] [] > Code: 0f 0b 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 2c 5a 01 ca 87 42 > > >>EIP; c013127e <===== > Trace; c01325d8 > Trace; c013268c > Trace; c0132730 > Trace; c01327a6 > Trace; c01328e0 > Trace; c0132840 > Trace; c0105000 <_stext+0/0> > Trace; c0105836 > Trace; c0132840 > Code; c013127e > 00000000 <_EIP>: > Code; c013127e <===== > 0: 0f 0b ud2a <===== > Code; c0131280 > 2: 8b 44 24 24 mov 0x24(%esp,1),%eax > Code; c0131284 > 6: 89 ea mov %ebp,%edx > Code; c0131286 > 8: 8b 48 18 mov 0x18(%eax),%ecx > Code; c0131288 > b: b8 71 f0 2c 5a mov $0x5a2cf071,%eax > Code; c013128e > 10: 01 ca add %ecx,%edx > Code; c0131290 > 12: 87 42 00 xchg %eax,0x0(%edx) > > Entering kdb (current=0xf7ee0000, pid 5) on processor 1 Oops: invalid > operand > eax = 0x5a2cf071 ebx = 0x003a0dc0 ecx = 0xf7ee3dd0 edx = 0xc200b060 > esi = 0xce837000 edi = 0xce8372b4 esp = 0xf7ee1f38 eip = 0xc013127e > ebp = 0xce837ce0 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 > > ->====================================================================== > > This is a different trace to the last one I posted, this new one makes > no direct reference to XFS which may mean that it is not XFS related (in > which case apologies....) or that it was another non XFS process > (kswapd) that ran into difficulty in obtaining kernel memory as a result > of XFS/extent issues. I seem to remember that the was an issue with the > XFS/KDB implementation around the time of the CVS kernel I'm currently > using. (No, the server shouldn't be running out of memory, it has 1Gbyte > RAM and does nothing but NFS serving, it normally has ~957684K cached). > > If I remember correctly we have tried the fix you refer to regarding > memory getting freed to the wrong pool: > > > > > Only happens under high memory pressure, Ian, I think this was > > your original oops. > > > > Date: Wed Mar 20 11:06:42 PST 2002 > > Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > Modid: 2.4.x-xfs:slinx:114531a > > linux/fs/xfs_support/kmem.c - 1.22 > > - Fix the case where we used vmalloc to allocate memory under > pressure, > > we need to free it that way > > Anyway, I think I need to get the current 2.4.19-XFS tree installed even > if this doesn't fix the problem it will give us a better base to work > from. > > Regards > > Ian Hardy > > -----Original Message----- > From: Stephen Lord [mailto:lord@sgi.com] > Sent: 16 September 2002 16:36 > To: I.D.Hardy@soton.ac.uk > Cc: linux-xfs@oss.sgi.com > Subject: RE: Re-occurance of NFS server panics > > > On Mon, 2002-09-16 at 09:52, Ian D. Hardy wrote: > > Steve +, > > > > Sorry to bother you again. You may remember that we've corresponded > > several times over the past ~9months with regards to kernel memory > > allocation problems and fragmented files (see bellow). > > > > We had a period of relative stability, however the last few weeks we > > have gone back to a situation of having one or more crashes/hangs > > every week and are now having to again review our continued use of > > XFS. Therefore any update on progress towards a fix for these > > problems would be very useful (I'd hate to go though the pain of > > converting our ~1Tbyte filesystem to Reiser of ext3 if there are fixes > > > immanent). > > > > We have been running a 2.4.18 XFS CVS kernel from Mid May for some > > time now, I'm just in the process of compiling and testing the current > > > 2.4.19 XFS CVS, is this likely to help? (looking through the list > > archive I can't find anything of direct relevance but may have missed > > something). > > > > We appear to be running at a lower overall system fragmentation level > > now (currently 13% in the past it has been 28% or more), though I > > guess it is possible for only a couple of large very fragmented files > > to result in kernel memory allocation problems and still have > > reasonably low overall FS fragmentation levels? > > > > Unfortunately the NFS load on our server is such that it is > > difficult/impossible to predict times of light NFS load in which to > > run fsr and as reported before we've had several incidents of > > filesystem corruption and the kernel taking the FS offline running fsr > > > under a NFS load. > > > > Thanks for your time (BTW: We've persevered with XFS for so long as it > > > seems to give better performance for our workload than ext3 or > > ReiserFS, however, stability is again becoming a problem). > > > > Nothing immediately rings a bell, there have been some recent changes > which fixed some hangs HP was having in doing large scale NFS > benchmarking. These might be beneficial to you. The last oops output I > have from you looked like this: > > >>EIP; c012ff76 <===== > Trace; c01fd146 > Trace; c01fd1a4 > Trace; c01d04f0 > Trace; c01a6996 > Trace; c01a5f12 > Trace; c01d6474 > Trace; c01fd2e0 > Trace; c01aac14 > Trace; c01cf962 > Trace; c01e6e22 > Trace; c01e6340 > Trace; c026cf44 > Trace; c01f696e > Trace; c01e6340 > Trace; c014f45c > Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> > Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> > Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> > Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> > Trace; f8d2b348 <[nfsd]nfsd+1b8/370> > Trace; c01057ea > Code; c012ff76 > 00000000 <_EIP>: > Code; c012ff76 <===== > 0: 0f 0b ud2a <===== > Code; c012ff78 > 2: 83 c4 08 add $0x8,%esp > Code; c012ff7a > 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx > Code; c012ff80 > b: 8b 2c 1a mov (%edx,%ebx,1),%ebp > Code; c012ff84 > e: 89 7c 24 14 mov %edi,0x14(%esp,1) > Code; c012ff88 > 12: b8 00 00 00 00 mov $0x0,%eax > > Is this still what you see? > > This one does bear the symptoms of a problem which was fixed a while ago > - memory was freed into the wrong pool. > > Steve > > From owner-linux-xfs@oss.sgi.com Mon Sep 16 10:57:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 10:57:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GHvXtG008742 for ; Mon, 16 Sep 2002 10:57:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA45603; Mon, 16 Sep 2002 13:02:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA75391; Mon, 16 Sep 2002 13:02:22 -0500 (CDT) Subject: Re: XFS mount failure From: Eric Sandeen To: vkuznet Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Sep 2002 12:57:32 -0500 Message-Id: <1032199053.6354.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs hi Valentin - Well, you can mount with "-o nouuid" to get around this, but the question remains, which other filesystem has this same uuid? Try xfs_db -r -c "sb 0" -c "p uuid" /dev/ for each of your mounted filesystems' devices, and see if you can find it. -Eric On Mon, 2002-09-16 at 12:01, vkuznet wrote: > Hi, > we do have 3Ware RAID machine where XFS is using. > After unexpected reboot we cannot longer mount our XFS filesystem. > > Here the /var/log/messages > > Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold exceeded: Port #6. > Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - can't mount > > Any idea how to fix the problem. > > We do have > Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 i686 unknown > patched kernel with XFS. > > Thanks, > Valentin. > P.S. could you please reply me directly I'm not currently in a mailing list. > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Sep 16 11:10:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 11:10:35 -0700 (PDT) Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GIAMtG009312 for ; Mon, 16 Sep 2002 11:10:22 -0700 Received: by musuko.uchicago.edu (Postfix, from userid 1002) id 940E82839E50; Mon, 16 Sep 2002 12:44:05 -0500 (CDT) Subject: Lost interrupt on repairing file system From: Stuart Luppescu To: Linux XFS List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T/Mp9pMWzbpedOtYT2ot" X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 12:44:05 -0500 Message-Id: <1032198245.32318.11.camel@musuko.uchicago.edu> Mime-Version: 1.0 X-archive-position: 410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s-luppescu@uchicago.edu Precedence: bulk X-list: linux-xfs --=-T/Mp9pMWzbpedOtYT2ot Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We had a power failure here, and when I restarted my machine and the xfs repair ran, I got this message repeated about 4 or 5 times: /dev/hda lost interrupt It seems to be running ok now, but I'm curious about what this means. Can someone explain this, please? (I'm running Gentoo Linux on an Athlon XP 2100 system, with the Gentoo 2.4.19-r7 kernel sources.) --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.19-gentoo-r7=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 Can I have an IMPULSE ITEM instead?=20 =20 --=-T/Mp9pMWzbpedOtYT2ot Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9hhhlDBHcBS0tWxMRAqeXAJ4gtTcPFlifQl9jxj19pM+uBlNa7ACfQ2uS Ehmiu2v1nWepbTXBpbIDLN8= =D/Y1 -----END PGP SIGNATURE----- --=-T/Mp9pMWzbpedOtYT2ot-- From owner-linux-xfs@oss.sgi.com Mon Sep 16 13:38:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 13:38:20 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GKcFtG012416 for ; Mon, 16 Sep 2002 13:38:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA41283 for ; Mon, 16 Sep 2002 15:43:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA92940; Mon, 16 Sep 2002 15:43:05 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8GKcDb07390; Mon, 16 Sep 2002 15:38:13 -0500 Message-Id: <200209162038.g8GKcDb07390@stout.americas.sgi.com> Date: Mon, 16 Sep 2002 15:38:13 -0500 Subject: PARTIAL TAKE - mkfs trips ASSERT in ag resizing code X-archive-position: 411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Reiterating for the benefit of the folks on linux-xfs: mkfs.xfs contains code which looks to see if all AGs will start on the same disk stripe, a non-optimal configuration, and changes the ag size by +/- 1 data stripe unit to avoid this. However, in the 1 AG case, this can lead to an ag size > data size, which ultimately fails in an ASSERT. This can be demonstrated with: mkfs.xfs -f -b size=4096 -d file,name=foo,size=10m,sunit=8,swidth=8 This can be avoided by not even going down the path for the 1-ag case, but a check for (agsize > dblocks) is added as well, to ensure that this never happens. Date: Mon Sep 16 13:38:02 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127521a cmd/xfsprogs/VERSION - 1.58 - Bump to 2.3.3 cmd/xfsprogs/doc/CHANGES - 1.83 - Document changes for 2.3.3 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.36 - Don't do ag resizing based on stripe alignment for single ag fs Don't ever let agsize > dblocks when doing this resizing. From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:03:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:03:12 -0700 (PDT) Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GM35tG020059 for ; Mon, 16 Sep 2002 15:03:06 -0700 Received: from [195.20.224.214] (helo=mrvdomng2.kundenserver.de) by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1) id 17r427-0002rk-00 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 00:07:55 +0200 Received: from [217.88.221.79] (helo=kernelpanix.aura.of.mankind) by mrvdomng2.kundenserver.de with esmtp (Exim 3.35 #1) id 17r427-0004RR-00 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 00:07:55 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.6/8.11.2) id g8GM5WY18388 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 00:05:32 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 17 Sep 2002 00:05:32 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: Linus merges XFS Message-ID: <20020917000532.A18289@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@s2y4n2c.de Precedence: bulk X-list: linux-xfs saw this on lwn.net. linus had merged XFS in the 2.5 tree. congratulation! and many thanks to all who made this possible. utz From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:09:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:09:53 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GM9otG020547 for ; Mon, 16 Sep 2002 15:09:50 -0700 Received: (qmail 14242 invoked by uid 500); 16 Sep 2002 22:14:32 -0000 Subject: Re: Linus merges XFS From: Austin Gonyou To: utz lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020917000532.A18289@s2y4n2c.de> References: <20020917000532.A18289@s2y4n2c.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032214472.13127.50.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 16 Sep 2002 17:14:32 -0500 X-archive-position: 413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Wooohooooo!!!! Hip-hip Hooooray!!!! On Mon, 2002-09-16 at 17:05, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:12:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:12:14 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GMCCtG021015 for ; Mon, 16 Sep 2002 15:12:12 -0700 Received: from attbi.com ([12.253.73.46]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020916221703.RCNK16829.rwcrmhc51.attbi.com@attbi.com> for ; Mon, 16 Sep 2002 22:17:03 +0000 Message-ID: <3D8658FF.30301@attbi.com> Date: Mon, 16 Sep 2002 16:19:43 -0600 From: "D. Stimits" Reply-To: stimits@attbi.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stimits@attbi.com Precedence: bulk X-list: linux-xfs utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz > > > Yay! I may have an excuse to go with 2.5 now. I have never kept up with issues on 2.5 though, I especially avoid devfs which I *think* is more important to 2.5 series. Can anyone give me any warnings or other hints one what to look out for if I use the next 2.5 release based on Linus merge of XFS? D. Stimits, stimits AT attbi.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:15:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:15:06 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GMF4tG021460 for ; Mon, 16 Sep 2002 15:15:04 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA47824; Mon, 16 Sep 2002 17:19:55 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-4.corp.sgi.com [134.15.64.4]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA59408; Mon, 16 Sep 2002 17:19:54 -0500 (CDT) Subject: Re: Linus merges XFS From: Stephen Lord To: stimits@attbi.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D8658FF.30301@attbi.com> References: <20020917000532.A18289@s2y4n2c.de> <3D8658FF.30301@attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 17:18:13 -0500 Message-Id: <1032214695.9808.216.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-16 at 17:19, D. Stimits wrote: > > Yay! I may have an excuse to go with 2.5 now. I have never kept up with > issues on 2.5 though, I especially avoid devfs which I *think* is more > important to 2.5 series. Can anyone give me any warnings or other hints > one what to look out for if I use the next 2.5 release based on Linus > merge of XFS? > > D. Stimits, stimits AT attbi.com > devfs is pretty much a dead issue in 2.5, there is a new spiffy driverfs, but it is a different beast entirely and you do not need it. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 16 16:01:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 16:01:46 -0700 (PDT) Received: from echo.computel.nl (IDENT:postfix@echo.computel.nl [195.86.134.74]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GN1htG024620 for ; Mon, 16 Sep 2002 16:01:44 -0700 Received: from localhost (localhost [127.0.0.1]) by echo.computel.nl (Postfix) with SMTP id DF1409E54 for ; Tue, 17 Sep 2002 01:06:38 +0200 (CEST) X-AV-Checked: Tue Sep 17 01:06:38 2002 www.nederland.net Received: from balefire10ww (e122144.upc-e.chello.nl [213.93.122.144]) by echo.computel.nl (Postfix) with ESMTP id 9C7A19E53 for ; Tue, 17 Sep 2002 01:06:38 +0200 (CEST) Message-ID: <004401c25dd5$b64bbfb0$64c8a8c0@balefire10ww> From: "Sander Steffann" To: References: <20020917000532.A18289@s2y4n2c.de> Subject: Re: Linus merges XFS Date: Tue, 17 Sep 2002 01:06:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sander@steffann.nl Precedence: bulk X-list: linux-xfs > saw this on lwn.net. linus had merged XFS in the 2.5 tree. Congratulations everyone! Sander. From owner-linux-xfs@oss.sgi.com Mon Sep 16 16:41:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 16:41:44 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GNfctG027229 for ; Mon, 16 Sep 2002 16:41:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 QAA03465 for ; Mon, 16 Sep 2002 16:46:34 -0700 (PDT) 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 JAA10877; Tue, 17 Sep 2002 09:45:17 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA52758; Tue, 17 Sep 2002 09:45:16 +1000 (AEDT) Date: Tue, 17 Sep 2002 09:45:15 +1000 From: Nathan Scott To: Frasenyak Dmitrij Cc: linux-xfs@oss.sgi.com Subject: Re: Need information about XFS tests Message-ID: <20020917094515.A154181@wobbly.melbourne.sgi.com> References: <3D85C8D5.6030901@rtsoft.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D85C8D5.6030901@rtsoft.msk.ru>; from sed@rtsoft.msk.ru on Mon, Sep 16, 2002 at 04:04:37PM +0400 X-archive-position: 417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 04:04:37PM +0400, Frasenyak Dmitrij wrote: > Hello > I'm looking for any documentation about XFS tests included in CVS tree. > I've searched over sgi site and Internet but found only small remarks > in the headers of scripts. There's a bit more info here... cmd/xfstests# ls */*README* *README* README dmapi/README crash/README tools/README.auto-qa cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 16 18:00:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 18:00:15 -0700 (PDT) Received: from web40612.mail.yahoo.com (web40612.mail.yahoo.com [66.218.78.149]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H109tG030563 for ; Mon, 16 Sep 2002 18:00:09 -0700 Message-ID: <20020917010501.70562.qmail@web40612.mail.yahoo.com> Received: from [208.35.40.2] by web40612.mail.yahoo.com via HTTP; Mon, 16 Sep 2002 18:05:01 PDT Date: Mon, 16 Sep 2002 18:05:01 -0700 (PDT) From: Ravi Wijayaratne Subject: oops in 2.4.18 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Hi all, In our stress test we see the oops that is attached. Having examined the code we see that the oops is happening in page_buf.c function pagebuf_page_io. Apparently the call to kmalloc failed in the following function. ---------------------------------- psync=(pagesync_t *)kmalloc(sizeof(pagesync_t),GFP_NOFS); if(psync==NULL) BUG(); <======== oopsed here ---------------------------------- We are running 2.4.18-xfs code with LVM on RAID 5. Is there a fix available for this ? Thank you Ravi ---------------------0x--------------x0----------- invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000008 ecx: 00000246 edx: 00000000 esi: 0c0002a0 edi: c1631780 ebp: 00000000 esp: efecde9c ds: 0018 es: 0018 ss: 0018 Process pagebuf_daemon (pid: 7, stackpage=efecd000) Stack: 00000000 0c0002a0 c1631780 d69cda60 e97dd7a0 0c8000cf 00000008 00000008 00000000 efecdec8 3a009fc8 d7ce49e0 d7ce46e0 d7ce4200 d7ce4bc0 d7ce43e0 d7ce42c0 d7ce4440 e97dd7a0 c01decf2 c1631780 d69cda60 0c0002a0 00000000 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 74 24 54 89 75 00 8b 7c 24 70 89 7d 04 c7 45 08 00 >>EIP; c01de997 <_pagebuf_page_io+bf/324> <===== Trace; c01decf2 <_page_buf_page_apply+f6/108> Trace; c01df16a Trace; c01dedf4 Trace; c01debfc <_page_buf_page_apply+0/108> Trace; c01e8742 Trace; c01df418 Trace; c0105000 <_stext+0/0> Trace; c01df250 Trace; c01056f3 Code; c01de997 <_pagebuf_page_io+bf/324> 00000000 <_EIP>: Code; c01de997 <_pagebuf_page_io+bf/324> <===== 0: 0f 0b ud2a <===== Code; c01de999 <_pagebuf_page_io+c1/324> 2: 8b 74 24 54 mov 0x54(%esp,1),%esi Code; c01de99d <_pagebuf_page_io+c5/324> 6: 89 75 00 mov %esi,0x0(%ebp) Code; c01de9a0 <_pagebuf_page_io+c8/324> 9: 8b 7c 24 70 mov 0x70(%esp,1),%edi Code; c01de9a4 <_pagebuf_page_io+cc/324> d: 89 7d 04 mov %edi,0x4(%ebp) Code; c01de9a7 <_pagebuf_page_io+cf/324> 10: c7 45 08 00 00 00 00 movl $0x0,0x8(%ebp) ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 19:48:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 19:48:48 -0700 (PDT) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H2mftG031740 for ; Mon, 16 Sep 2002 19:48:42 -0700 Received: from [209.96.179.45] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17r8Ub-000PNq-00 for linux-xfs@oss.sgi.com; Mon, 16 Sep 2002 22:53:38 -0400 Received: from daydream.shannon.net (daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g8H1t8229254 for ; Mon, 16 Sep 2002 21:55:08 -0400 (EDT) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id g8H1t51L016094 for ; Mon, 16 Sep 2002 21:55:05 -0400 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id g8H1sj3W016091 for linux-xfs@oss.sgi.com; Mon, 16 Sep 2002 21:54:45 -0400 Date: Mon, 16 Sep 2002 21:54:45 -0400 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917015442.GA15962@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020917000532.A18289@s2y4n2c.de> <3D8658FF.30301@attbi.com> <1032214695.9808.216.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032214695.9808.216.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shannon@widomaker.com Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 05:18:13PM -0500, Stephen Lord wrote: > devfs is pretty much a dead issue in 2.5, there is a new spiffy > driverfs, but it is a different beast entirely and you do not > need it. You mean they are getting rid of devfs? -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 20:30:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 20:30:31 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H3U3tG000464 for ; Mon, 16 Sep 2002 20:30:04 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8H3Yxq04948 for ; Mon, 16 Sep 2002 23:34:59 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8H3Yxx04939; Mon, 16 Sep 2002 23:34:59 -0400 Date: Mon, 16 Sep 2002 23:34:58 -0400 (EDT) From: Benito Venegas To: utz lehmann cc: Subject: Re: Linus merges XFS In-Reply-To: <20020917000532.A18289@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Congratulation guys!!!! On Tue, 17 Sep 2002, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz > > Vene.- From owner-linux-xfs@oss.sgi.com Mon Sep 16 23:48:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 23:48:58 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6mstG002645 for ; Mon, 16 Sep 2002 23:48:55 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H6rkg6046463; Tue, 17 Sep 2002 08:53:51 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917085058.0373f448@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 08:52:34 +0200 To: Benito Venegas , From: Seth Mos Subject: Re: kernel src to compile In-Reply-To: References: <200209131823.g8DINgZ25682@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:08 16-9-2002 -0400, Benito Venegas wrote: >Good morning team: >(bad morning for me, but I hope you have better than mine) > >I have a problem in one of my servers. >Kernel Panic, only I have latest line, due Kernel Panic >debug message was too big for my console (nfs_ related problem I think) >grrrrrr..I ate don;t have good logs.... > >Does any of you guys have a kernel-2.4.18 or higher version >in format src.rpm ready to compile? or at least > 2.4.9-31 that I am using >today. ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/2.4.18/SRPMS/ This one? -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Sep 16 23:52:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 23:52:39 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6qatG003108 for ; Mon, 16 Sep 2002 23:52:36 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H6vWuO060460; Tue, 17 Sep 2002 08:57:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917085353.038c0c88@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 08:56:19 +0200 To: Stuart Luppescu , Linux XFS List From: Seth Mos Subject: Re: Lost interrupt on repairing file system In-Reply-To: <1032198245.32318.11.camel@musuko.uchicago.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_2517079==_" X-archive-position: 422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs --=====================_2517079==_ Content-Type: multipart/related; type="text/plain"; boundary="=====================_2517079==_.REL" --=====================_2517079==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:44 16-9-2002 -0500, Stuart Luppescu wrote: >23eed0.jpg Lost interrupt on repairing >fil.ems<0880.0002>> >*** PGP Signature Status: bad >*** Signer: Stuart Luppescu (Invalid) >*** Signed: 16-9-2002 19:44:05 >*** Verified: 17-9-2002 8:53:39 >*** BEGIN PGP VERIFIED MESSAGE *** > >We had a power failure here, and when I restarted my machine and the xfs >repair ran, I got this message repeated about 4 or 5 times: >/dev/hda lost interrupt >It seems to be running ok now, but I'm curious about what this means. >Can someone explain this, please? A flakky IDE controller at best. As long as it is not reporting media errors you might be OK. You might have either not compiled the driver for your IDE chipset into the kernel and the controller is working in compatability mode which might cause interesting problems. In general I'd said the disk/machine was very busy and a interrupt got dropped. Cheers --=====================_2517079==_.REL Content-Type: image/jpeg; name="23eed0.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.3.2.7.2.20020917085353.038c0c88@pop.xs4all.nl.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="23eed0.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/ 2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAgACADASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+gCvlf9tW b4sW37Nvjq4+DFp4ov8AxfBrHwym1mw8DtrCeNL34TRfFfwO/wAfLTwg/ha5 svHieKLn4Fr8RodAb4W3lp8Yl1Z7Q/By5g+KI8Iypp3dx8fviH8dfjX4F+Hf xZ+HXwl8A/BD4Rfsh+MdRl1L9ij4+/tnfEPxf4t/as+M/wC0t8KLWHTvDPwK /aJ+EOt6B4T8Ht8EPD9/q+oL4R8VQ6dYeIPEHifxHrWgeHPDtxOn09Y/sP8A 7cmoWtneQftvfsqpDfW9pcwpcf8ABNj41W10sd5HYSxrNYzf8FO0vYrgLqEY a0a3+1PJ9khghmm13wwmufB8TeJ/AHBuNhl/FHFWV5NjalP2sKGLqVVJxtGT TdOlUhGpGFSlUlRlJVYUq+HqygqWIozqdVHBYrERcqFCdSKdm4penVp2vdJ7 NppO6aX8w3iD4Qa/+xd+0J+wr8S/D/hzwf8ABf47/tW6h8M9Z+P3gj4YfC79 nn4Y+BPhPquu/tM/sPfCb4ufs+fDTTfgD8O/B2k+Ifgfd6R+018QdAGg/FLX /jhc2ms+BPhL8TPCnja2+JXgq1+IGp/04V+Pnxn8OeHvhRL/AMFA9W/aj8N/ 8E+/2oPjD8Ef2rPgn4E8PfGD9o39jf8AZT13w34a+HPj39lf9ifxzZeAvB3h f9s//goJ4Fm+Hnw8t9V+InjrWNK8Nr+0v4Y8F618R/FHxU+J/gi/8eax468T 6D8Lvmr9qSw+HfgfWf8Agl148+B3wS/Zb+CXiX4j/tH/ALEfizxN49/ZZ/Zh /Zq+CHiDWfD3xVv/AIR+F/GmmWXxB/Z68O/E7U7f4L+PLfxh418Pal4b0H48 +J/g54rl1zX/AAwv7VHxouBd/s++Cfk868deDsoz/grh+GHzjNK3H3EGQcP5 BmWXUMDPKZz4iyHE8S4HMcRXr5hQxUMveU4SrLno4KvXliZ0KKw6o1KmJo7U 8sxFSliat6cFhaVSrVhNyVS1KtGhKCSg4uftJLRyS5U3e6UX+6X/AATi/YV/ YP8AFX7IH/BMzSvFn/BHT9n/AOK//C1/2AP2WfiL8Sf2vdT/AGav2Cdc8Cad 471z9n/R9e1yD4pS+OfGenftNeKviB4q1rTra61DxF4Z+Cnj7R9R1jx9oWoa z4uTy/G174V+Zf8Agn/4x/ac/YJ1n/gn1+xFq37D/wAePgr4I+M/g74d/s2+ PdG+N/jz4BT/AAT0X9q74Y/s0+KPiH8afjZ+zl4i+C3xU+P3jfT/AAx8Xr74 U/E7VfHnwy1T4Yp8LviB418VWn7Qa+Kfgn4x8Y/tB+Fv2neL/Zu/aZ/4JheL v2Vv+Cc+m/F79sj/AIIoGw8Of8E4P2FP2ev2oPhb+1R+zn4E/aD/AGh/EPhX 4e+Hvh18SvGfwOm+NNx+1N4C0PwJ4f0Xxnomh6po3w08b/BL4m6d8LPjr4Xu fiDrui+IdetIfC2iN/bA/bD+CvxZ0v8A4JO/BP8AY7+PP/BLv9tL9oD4KftE fE21tPhB8O9Nk+EX7K2l/DrSf2L/ANqjwz4Tih+Avhvx1+0/4x+H3gf4ceA2 0PQ9As7PV/G3hc+PtE8NpJbeFPDniGx8O6P9p4h8MZfxfwZxFkeYZLTz9YjK 8bUwWWSlQpVa2aUMNVqZb9UxOIxODpYPGfW1Tjh8VPG4OnSlN+2xNKhKrI58 JWnh8RRqwqOk4zjzT1aUHJc/NFKTlHlvePLJvpFux9zj9gjQP239Vb9qO6+N n7Zf7F/xI+KcPgXxv8Vvhd8AfEHiDw74G1P4oReDvg3YW3j6Oy/bf/YW8M/F W08ayeFPhP8AArwrqtz4Z8B+C9MuJfhN8MNe13wafjVp99e/Eb8tfi/+wD4a +GX/AAU4/Zh/Z88YftE/tG/tGfCjwL+zprv7bHhPw78dNR+Bt9JoHxz+C3xX +CHwq+GWraJrHwr+C/w31fQ9D0Lw7c6BfJp+h6hp0utWvhDwj4Q1LW/Fnwfj v/D/AIw+0NJ/aF/4K0eH9Z1PxF4f/Zb/AOCSmheINas7TTtW13Sfin+0rZaz qen6dYrpel2Op6nF+zsL3VLPTdMg0/TrS11Oe7gFjpy2kyTW+q+IY9Z4Pw54 c/bc+MP7bnhr9q/9q/w1+yz4LsfBf7LPxM/Z70bRv2e/iZ8YfHN3qt345+MP wq+J2n6pqmn/ABO+FXgyPT4dPj8GeJLXUtRtfEmoXWqXWoaRPPpD6g+t63e/ xn4YeCniHgPGXhXiviTw6yfJ+F8lw9P/AGnHVOBc5zbA1cu4Nq5LlVKGbYLF ZhxFjfqOZQwkMuxFWtzUcNhsNVlHC+wp0aX0ONzHCTy6tQpYupUr1JP3YrE0 6clPERqTfs5KNKPNHmc0lq21eV23/9k= --=====================_2517079==_.REL-- --=====================_2517079==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Seth It might just be your lucky day, if you only knew. --=====================_2517079==_-- From owner-linux-xfs@oss.sgi.com Mon Sep 16 23:55:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 23:55:28 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6tPtG003615 for ; Mon, 16 Sep 2002 23:55:26 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H70KO8007899; Tue, 17 Sep 2002 09:00:21 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917085626.038c0d90@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 08:59:07 +0200 To: vkuznet , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS mount failure In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:01 16-9-2002 -0500, vkuznet wrote: >Hi, >we do have 3Ware RAID machine where XFS is using. >After unexpected reboot we cannot longer mount our XFS filesystem. > >Here the /var/log/messages > >Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold >exceeded: Port #6. >Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - >can't mount I don't know about a 3ware controllers but I'd say the smart on the disk on port 6 is telling the controller that it's going bad. Better check. xfs_repair might be able to fix your filesystem. What 3ware controller are you using? >Any idea how to fix the problem. > >We do have >Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 >i686 unknown >patched kernel with XFS. Can you upgrade to something more recent please. You definitely want the XFS 1.1 release or later. Use CVS or the split patches if you want newer then 2.4.18. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 00:00:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 00:00:02 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6xxtG004099 for ; Tue, 17 Sep 2002 00:00:00 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H74uP9063935; Tue, 17 Sep 2002 09:04:56 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917090225.0438df38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 09:03:44 +0200 To: utz lehmann , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Linus merges XFS In-Reply-To: <20020917000532.A18289@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 00:05 17-9-2002 +0200, utz lehmann wrote: >saw this on lwn.net. linus had merged XFS in the 2.5 tree. > >congratulation! > >and many thanks to all who made this possible. ! :-) -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 00:07:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 00:07:34 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H77VtG004624 for ; Tue, 17 Sep 2002 00:07:31 -0700 Received: from erbenson.alaska.net (160-pm11.nwc.alaska.net [209.112.140.160]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8H7CRBs091575 for ; Mon, 16 Sep 2002 23:12:28 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 187633A09 for ; Mon, 16 Sep 2002 23:12:27 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 999DC4104E7; Mon, 16 Sep 2002 23:12:26 -0800 (AKDT) Date: Mon, 16 Sep 2002 23:12:26 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917071226.GA10776@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020917000532.A18289@s2y4n2c.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20020917000532.A18289@s2y4n2c.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2002 at 12:05:32AM +0200, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. you know what they say, if at first you don't succeed, try, try try try, try again. > congratulation! >=20 > and many thanks to all who made this possible. indeed. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2G1doACgkQJKx7GixEevw3LgCfdloyqtOyL+jbsXwpyRaB96t6 WjUAnRQXzLPh6HiNYgIAvZCDJKG+QqPt =zLNb -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-linux-xfs@oss.sgi.com Tue Sep 17 00:18:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 00:18:09 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H7I6tG005178 for ; Tue, 17 Sep 2002 00:18:06 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8H7N2T7025487; Tue, 17 Sep 2002 09:23:03 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id C81FF69123; Tue, 17 Sep 2002 09:23:01 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: utz lehmann , linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Date: Tue, 17 Sep 2002 09:23:01 +0200 X-Mailer: KMail [version 1.3.2] References: <20020917000532.A18289@s2y4n2c.de> In-Reply-To: <20020917000532.A18289@s2y4n2c.de> MIME-Version: 1.0 Message-Id: <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8H7I7tG005179 X-archive-position: 426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Many thanks and congratulations to everyone involved!!! This is what I was waiting for so long, thanks. Simon On Tuesday 17 September 2002 00:05, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz From owner-linux-xfs@oss.sgi.com Tue Sep 17 03:40:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 03:40:35 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HAeWtG015284 for ; Tue, 17 Sep 2002 03:40:32 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8HAjTq10520 for ; Tue, 17 Sep 2002 06:45:29 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8HAjTH10510; Tue, 17 Sep 2002 06:45:29 -0400 Date: Tue, 17 Sep 2002 06:45:29 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: Subject: Re: kernel src to compile In-Reply-To: <4.3.2.7.2.20020917085058.0373f448@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs I was looking for a new one (many updates since last time you did that src.rpm @ oss.sgi.com I am using this one now. Thanks On Tue, 17 Sep 2002, Seth Mos wrote: > At 11:08 16-9-2002 -0400, Benito Venegas wrote: > >Good morning team: > >(bad morning for me, but I hope you have better than mine) > > > >I have a problem in one of my servers. > >Kernel Panic, only I have latest line, due Kernel Panic > >debug message was too big for my console (nfs_ related problem I think) > >grrrrrr..I ate don;t have good logs.... > > > >Does any of you guys have a kernel-2.4.18 or higher version > >in format src.rpm ready to compile? or at least > 2.4.9-31 that I am using > >today. > > ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/2.4.18/SRPMS/ > > This one? > -- > Seth > It might just be your lucky day, if you only knew. > -- Vene.- From owner-linux-xfs@oss.sgi.com Tue Sep 17 03:43:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 03:43:28 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HAhOtG016120 for ; Tue, 17 Sep 2002 03:43:24 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8HAmEh1068398; Tue, 17 Sep 2002 12:48:19 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917124548.03981060@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 12:47:05 +0200 To: Benito Venegas From: Seth Mos Subject: Re: kernel src to compile Cc: In-Reply-To: References: <4.3.2.7.2.20020917085058.0373f448@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 06:45 17-9-2002 -0400, Benito Venegas wrote: >I was looking for a new one (many updates since last time you did that >src.rpm @ oss.sgi.com There was discussion about releasing a newer one but there were/are some issues that need to be fixed for a new release to happen. Untill that time you can wait or us the CVS/split patches. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 05:38:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 05:38:55 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HCcntG019226 for ; Tue, 17 Sep 2002 05:38:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA52514 for ; Tue, 17 Sep 2002 07:43:42 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA46236 for ; Tue, 17 Sep 2002 07:43:41 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8HJwgL06252 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 15:58:42 -0400 Resent-Message-Id: <200209171958.g8HJwgL06252@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA95901 for ; Tue, 17 Sep 2002 07:43:19 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8HJwKV06207 for hch@sgi.com; Tue, 17 Sep 2002 15:58:20 -0400 Date: Tue, 17 Sep 2002 15:58:20 -0400 From: Christoph Hellwig Message-Id: <200209171958.g8HJwKV06207@dhcp212.munich.sgi.com> Subject: TAKE - Use do_gettimeofday() instead of racy direct access to xtime Resent-Date: Tue, 17 Sep 2002 15:58:42 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs This is the right fix for the small change in support/time.h in the 2.5.35 merge. Date: Tue Sep 17 05:42:00 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127568a linux/fs/xfs/support/time.h - 1.7 - Use do_gettimeofday() instead of racy direct access to xtime From owner-linux-xfs@oss.sgi.com Tue Sep 17 05:46:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 05:46:34 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HCkWtG019734 for ; Tue, 17 Sep 2002 05:46:32 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rHp8-0004Pb-00 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 06:51:26 -0600 Message-ID: <3D8723BE.8050702@emergence.com> Date: Tue, 17 Sep 2002 06:44:46 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs My discussions with some of the Gentoo developers there seems to be a number of them that have/had experienced data loss in the past and I think some of them have a problem that it only journals metadata. Looks like XFS didn't make it in to the latest 2.4.19 kernel they have in testing right: gentoo-sources-2.4.19-r9 I think some of the developers feel they can't recommending XFS due to past experiences and I think they have the impression that XFS won't or is hard to patch into their mainline kernel now due to other features they want to offer. I think that other than the metadata, their fears are unfounded but I don't know how to open a discussion with them them about how some of the problems that they experienced with early XFS up to and including 1.1 (where the 2.4.19-r7 XFS patches come from) does not reflect on the sheer amount of testing and bug fixing have occured in CVS (even if you just consider the 2.4.19 XFS kernel sync) Perhaps I could patch a current XFS into their current (2.4.19-r9) and running the test suite? Is there anything else that might be suggested. I suppose a good starting point would be to see which of their patches overlap with the XFS 2.4.19 or CVS code. -Mike Simon Matter wrote: > Many thanks and congratulations to everyone involved!!! > This is what I was waiting for so long, thanks. > > Simon > > > On Tuesday 17 September 2002 00:05, utz lehmann wrote: > >>saw this on lwn.net. linus had merged XFS in the 2.5 tree. >> >>congratulation! >> >>and many thanks to all who made this possible. >> >> >>utz From owner-linux-xfs@oss.sgi.com Tue Sep 17 05:55:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 05:55:02 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HCsvtG020311 for ; Tue, 17 Sep 2002 05:54:59 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17rHxK-0006Y9-00; Tue, 17 Sep 2002 13:59:54 +0100 Date: Tue, 17 Sep 2002 13:59:54 +0100 From: Christoph Hellwig To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917135954.A25165@infradead.org> References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D8723BE.8050702@emergence.com>; from mbest@emergence.com on Tue, Sep 17, 2002 at 06:44:46AM -0600 X-archive-position: 431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 06:44:46AM -0600, Michael Best wrote: > My discussions with some of the Gentoo developers there seems to be a > number of them that have/had experienced data loss in the past and I > think some of them have a problem that it only journals metadata. Some of their patches/patch combination almost guarntee data loss. I wouldn't trust gentoo for throw-away bk repo :) From owner-linux-xfs@oss.sgi.com Tue Sep 17 06:14:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 06:14:47 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HDEetG021618 for ; Tue, 17 Sep 2002 06:14:41 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rIGM-0004Tn-00; Tue, 17 Sep 2002 07:19:34 -0600 Message-ID: <3D872A57.5040301@emergence.com> Date: Tue, 17 Sep 2002 07:12:55 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <20020917135954.A25165@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > On Tue, Sep 17, 2002 at 06:44:46AM -0600, Michael Best wrote: > >>My discussions with some of the Gentoo developers there seems to be a >>number of them that have/had experienced data loss in the past and I >>think some of them have a problem that it only journals metadata. > > > Some of their patches/patch combination almost guarntee data loss. > I wouldn't trust gentoo for throw-away bk repo :) Just curious which of their patches/patch combinations were the worst? They have a separate xfs_sources available, and since keeping XFS out of their main tree anyways, I think I'll just stick to trying to get things like newer xfsprogs into their package system and perhaps a couple of things (like rml preempt) into their xfs kernel sources. I was also hoping to get their maintainer to build a weekly CVS snapshot kernel (as there appears to be a weekly XFS-patch snapshot) that would be masked/hidden, just in case developers wanted to test things. Other than the gcc-3.2 - O_DIRECT on i586 problem I know about I am using an XFS CVS kernel from a couple of weeks back. (using athlon so I'm not affected by the O_DIRECT problem) -Mike From owner-linux-xfs@oss.sgi.com Tue Sep 17 06:18:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 06:18:06 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HDI3tG022256 for ; Tue, 17 Sep 2002 06:18:04 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8HDMQDh034693; Tue, 17 Sep 2002 15:22:28 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917150318.0391a4b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 15:21:13 +0200 To: Michael Best , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Linus merges XFS In-Reply-To: <3D8723BE.8050702@emergence.com> References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 06:44 17-9-2002 -0600, Michael Best wrote: >My discussions with some of the Gentoo developers there seems to be a >number of them that have/had experienced data loss in the past and I >think some of them have a problem that it only journals metadata. The pre 1.1 releases had this problem. It should be a lot less common since the 1.1 release. So far I have had good success and the problems I did encounter could be worked around or fixed. >Looks like XFS didn't make it in to the latest 2.4.19 kernel they have >in testing right: XFS will only be integrated in 2.4 after it has succesfully made it in 2.5 according to Marcello. The merge would happen in 2.5.36 and we currently have 2.5.35 so a bit of patience please. Also of note is that the 2.4 tree is different from the 2.5 tree in many respects. You can find a link to Christoph' checklist in the FAQ that shows what functionality is available in 2.4 and 2.5 and what needs to be done to make it fit in. >I think some of the developers feel they can't recommending XFS due to >past experiences and I think they have the impression that XFS won't or >is hard to patch into their mainline kernel now due to other features >they want to offer. Not compared to the 2.4.0 days it's not :-) Since the VM has settled it did get easier. >I think that other than the metadata, their fears are unfounded but I >don't know how to open a discussion with them them about how some of the >problems that they experienced with early XFS up to and including 1.1 >(where the 2.4.19-r7 XFS patches come from) does not reflect on the >sheer amount of testing and bug fixing have occured in CVS (even if you >just consider the 2.4.19 XFS kernel sync) You can not compare XFS 1.1 from april to current CVS (5 months ago!). >Perhaps I could patch a current XFS into their current (2.4.19-r9) and >running the test suite? Is there anything else that might be suggested. There are some new features in current CVS that need somoe more testing. I believe a patch with more recent XFS code is going to Andrea and you might be able to use that as well. No warranty though since it is not a full fledged release (== tested). >I suppose a good starting point would be to see which of their patches >overlap with the XFS 2.4.19 or CVS code. That might be a lot :-) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 06:18:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 06:18:13 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HDIAtG022319 for ; Tue, 17 Sep 2002 06:18:11 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17rIJp-0006iX-00; Tue, 17 Sep 2002 14:23:09 +0100 Date: Tue, 17 Sep 2002 14:23:09 +0100 From: Christoph Hellwig To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917142309.A25763@infradead.org> References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <20020917135954.A25165@infradead.org> <3D872A57.5040301@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D872A57.5040301@emergence.com>; from mbest@emergence.com on Tue, Sep 17, 2002 at 07:12:55AM -0600 X-archive-position: 434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 07:12:55AM -0600, Michael Best wrote: > Just curious which of their patches/patch combinations were the worst? older xfs + preempt was very bad, merging of wli's unreleases per-zone kswapd + rmap + radix tree code was also very bad. Just look at some of the kernel patches, they're often random patch collections. From owner-linux-xfs@oss.sgi.com Tue Sep 17 07:14:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 07:14:42 -0700 (PDT) Received: from booster.telnet.hu (mail@booster.telnet.hu [212.75.128.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HEEVtG001359 for ; Tue, 17 Sep 2002 07:14:34 -0700 Received: from mx1.netposta.net ([212.75.128.65]) by booster.telnet.hu with esmtp (Exim 3.35 #1 (Debian)) id 17rJCE-00076f-00 for ; Tue, 17 Sep 2002 16:19:23 +0200 Received: from www-data by mx1.netposta.net with local (Exim 3.35 #1 (Debian)) id 17rIuR-0004TY-00 for ; Tue, 17 Sep 2002 16:00:59 +0200 From: "Regos Bendeguz" To: linux-xfs@oss.sgi.com Reply-To: "Regos Bendeguz" MIME-Version: 1.0 Content-Type: text/plain; ; charset="iso-8859-2" Content-Description: X-Mailer: NetPosta - http://www.netposta.net X-Originating-IP: 193.6.16.91 Subject: 2.4.18 kernel oops (RH7.3-SGI-XFS-1.1) Message-Id: Date: Tue, 17 Sep 2002 16:00:59 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8HEEbtG001360 X-archive-position: 435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bendeguz@netposta.net Precedence: bulk X-list: linux-xfs Hi all, I am using 2.4.18 kernel (RH7.3-SGI-XFS-1.1) If I try to do some simple stress test (dbench) I get the following kernel bug: #1 Sep 11 17:32:03 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Sep 11 17:32:03 kernel: printing eip: Sep 11 17:32:03 kernel: c01cad5c Sep 11 17:32:03 kernel: *pde = 00000000 Sep 11 17:32:03 kernel: Oops: 0000 Sep 11 17:32:03 kernel: ipt_LOG ipt_limit ipt_state ip_conntrack iptable_filter ip_tables autofs 8139t Sep 11 17:32:03 kernel: CPU: 0 Sep 11 17:32:03 kernel: EIP: 0010:[] Not tainted Sep 11 17:32:03 kernel: EFLAGS: 00010286 Sep 11 17:32:03 kernel: Sep 11 17:32:03 kernel: EIP is at xfs_syncsub [kernel] 0x42c (2.4.18- 4SGI_XFS_1.1smp) Sep 11 17:32:03 kernel: eax: 00000018 ebx: 0000000a ecx: 0000000a edx: 00000000 Sep 11 17:32:03 kernel: esi: dd2fc1f4 edi: ccb16820 ebp: d046ee24 esp: db76dcf4 Sep 11 17:32:04 kernel: ds: 0018 es: 0018 ss: 0018 Sep 11 17:32:04 kernel: Process dbench (pid: 9853, stackpage=db76d000) Sep 11 17:32:04 kernel: Stack: ede49d18 00000000 0000000e 00000000 00000001 0000000a 0000000a 00000040 Sep 11 17:32:04 kernel: 00000000 00000000 00000000 dd30068c 00000000 00010000 00000202 00000004 Sep 11 17:32:04 kernel: dd30057c c01b3d03 dd300608 dd30068c 00000000 c01dd664 ede49c00 d046f478 Sep 11 17:32:04 kernel: Call Trace: [] xfs_iunlock [kernel] 0x33 Sep 11 17:32:04 kernel: [] xfs_iomap_write [kernel] 0xc4 Sep 11 17:32:04 kernel: [] xfs_sync [kernel] 0x15 Sep 11 17:32:04 kernel: [] xfs_bmap [kernel] 0x202 Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x82 Sep 11 17:32:04 kernel: [] _pagebuf_file_write [kernel] 0xf8 Sep 11 17:32:04 kernel: [] xfs_symlink [kernel] 0x65b Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 17:32:04 kernel: [] pagebuf_generic_file_write [kernel] 0x19b Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 17:32:04 kernel: [] xfs_access [kernel] 0x2f Sep 11 17:32:04 kernel: [] xfs_write [kernel] 0x280 Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 17:32:04 kernel: [] linvfs_write [kernel] 0x2bf Sep 11 17:32:04 kernel: [] sys_write [kernel] 0x96 Sep 11 17:32:04 kernel: [] system_call [kernel] 0x33 Sep 11 17:32:04 kernel: Sep 11 17:32:04 kernel: Sep 11 17:32:04 kernel: Code: 39 42 18 0f 84 87 00 00 00 8b 44 24 10 85 c0 74 2c 8b 46 08 Oops report is here: >>EIP; c01cad5c <===== Trace; c01b3d03 Trace; c01dd664 Trace; c01ca925 Trace; c01dca72 Trace; c01db532 Trace; c01d7258 <_pagebuf_file_write+f8/210> Trace; c01d080b Trace; c01db4b0 Trace; c01d750b Trace; c01db4b0 Trace; c01cc77f Trace; c01dc660 Trace; c01db4b0 Trace; c01d867f Trace; c0142086 Trace; c0108c6b Code; c01cad5c 00000000 <_EIP>: Code; c01cad5c <===== 0: 39 42 18 cmp %eax,0x18(%edx) <===== Code; c01cad5f 3: 0f 84 87 00 00 00 je 90 <_EIP+0x90> c01cadec Code; c01cad65 9: 8b 44 24 10 mov 0x10(%esp,1),%eax Code; c01cad69 d: 85 c0 test %eax,%eax Code; c01cad6b f: 74 2c je 3d <_EIP+0x3d> c01cad99 Code; c01cad6d 11: 8b 46 08 mov 0x8(%esi),%eax #2 Sep 11 18:02:40 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Sep 11 18:02:40 kernel: printing eip: Sep 11 18:02:40 kernel: c01cad5c Sep 11 18:02:40 kernel: *pde = 00000000 Sep 11 18:02:40 kernel: Oops: 0000 Sep 11 18:02:40 kernel: autofs 8139too mii ne2k-pci 8390 ipt_LOG ipt_limit ipt_state ip_conntrack ipta Sep 11 18:02:40 kernel: CPU: 1 Sep 11 18:02:40 kernel: EIP: 0010:[] Not tainted Sep 11 18:02:40 kernel: EFLAGS: 00010286 Sep 11 18:02:40 kernel: Sep 11 18:02:40 kernel: EIP is at xfs_syncsub [kernel] 0x42c (2.4.18- 4SGI_XFS_1.1smp) Sep 11 18:02:40 kernel: eax: 00000018 ebx: 0000000a ecx: 0000000a edx: 00000000 Sep 11 18:02:40 kernel: esi: eb4e9750 edi: ef60f6c0 ebp: d1744184 esp: ead69cf4 Sep 11 18:02:40 kernel: ds: 0018 es: 0018 ss: 0018 Sep 11 18:02:40 kernel: Process dbench (pid: 1254, stackpage=ead69000) Sep 11 18:02:40 kernel: Stack: ef470118 00000000 00000006 00000000 00000001 0000000a 0000000a 00000040 Sep 11 18:02:40 kernel: 00000000 00000000 00000000 d1ace68c 00000000 00010000 00000202 00000004 Sep 11 18:02:40 kernel: d1ace57c c01b3d03 d1ace608 d1ace68c 00000000 c01dd664 ef470000 eb2a4740 Sep 11 18:02:40 kernel: Call Trace: [] xfs_iunlock [kernel] 0x33 Sep 11 18:02:40 kernel: [] xfs_iomap_write [kernel] 0xc4 Sep 11 18:02:40 kernel: [] xfs_sync [kernel] 0x15 Sep 11 18:02:40 kernel: [] xfs_bmap [kernel] 0x202 Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x82 Sep 11 18:02:40 kernel: [] _pagebuf_file_write [kernel] 0xf8 Sep 11 18:02:40 kernel: [] xfs_symlink [kernel] 0x65b Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 18:02:40 kernel: [] pagebuf_generic_file_write [kernel] 0x19b Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 18:02:40 kernel: [] xfs_access [kernel] 0x2f Sep 11 18:02:40 kernel: [] xfs_write [kernel] 0x280 Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 18:02:40 kernel: [] linvfs_write [kernel] 0x2bf Sep 11 18:02:40 kernel: [] sys_write [kernel] 0x96 Sep 11 18:02:40 kernel: [] system_call [kernel] 0x33 Sep 11 18:02:40 kernel: Sep 11 18:02:40 kernel: Sep 11 18:02:40 kernel: Code: 39 42 18 0f 84 87 00 00 00 8b 44 24 10 85 c0 74 2c 8b 46 08 Oops report: >>EIP; c01cad5c <===== Trace; c01b3d03 Trace; c01dd664 Trace; c01ca925 Trace; c01dca72 Trace; c01db532 Trace; c01d7258 <_pagebuf_file_write+f8/210> Trace; c01d080b Trace; c01db4b0 Trace; c01d750b Trace; c01db4b0 Trace; c01cc77f Trace; c01dc660 Trace; c01db4b0 Trace; c01d867f Trace; c0142086 Trace; c0108c6b Code; c01cad5c 00000000 <_EIP>: Code; c01cad5c <===== 0: 39 42 18 cmp %eax,0x18(%edx) <===== Code; c01cad5f 3: 0f 84 87 00 00 00 je 90 <_EIP+0x90> c01cadec Code; c01cad65 9: 8b 44 24 10 mov 0x10(%esp,1),%eax Code; c01cad69 d: 85 c0 test %eax,%eax Code; c01cad6b f: 74 2c je 3d <_EIP+0x3d> c01cad99 Code; c01cad6d 11: 8b 46 08 mov 0x8(%esi),%eax This happens reproducably under high load (with dbench) Best regards, Bendeguz --------------------------------------------------------------------- http://www.netposta.net NetPosta, E-m@il ingyen! From owner-linux-xfs@oss.sgi.com Tue Sep 17 07:27:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 07:27:16 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HERCtG001919 for ; Tue, 17 Sep 2002 07:27:12 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rJOX-0004es-00; Tue, 17 Sep 2002 08:32:05 -0600 Message-ID: <3D873B56.8040005@emergence.com> Date: Tue, 17 Sep 2002 08:25:26 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Regos Bendeguz CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 kernel oops (RH7.3-SGI-XFS-1.1) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs First mentioned: "XFS-1.1+DEBUG+debench = panic" - 2002/05/16 http://marc.theaimsgroup.com/?l=linux-xfs&s=dbench Dbench was also mentioned in most of the entire thread "2.4.20pre5aa2" - 2002/09/12 -> 2002/09/15 And a couple of times in: "snapshot regression test try 2" - 2002/08/30 -Mike Regos Bendeguz wrote: > Hi all, > > I am using 2.4.18 kernel (RH7.3-SGI-XFS-1.1) > If I try to do some simple stress test (dbench) I get > the following kernel bug From owner-linux-xfs@oss.sgi.com Tue Sep 17 07:40:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 07:40:43 -0700 (PDT) Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HEedtG003334 for ; Tue, 17 Sep 2002 07:40:39 -0700 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id H2L7ND00.610; Tue, 17 Sep 2002 16:45:13 +0200 Message-ID: <3D87944B.8040206@hamburg.fcb.com> Date: Tue, 17 Sep 2002 16:44:59 -0400 From: Harald Wagener Organization: FCB Wilkens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020909 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Best CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Michael Best wrote: >My discussions with some of the Gentoo developers there seems to be a >number of them that have/had experienced data loss in the past and I >think some of them have a problem that it only journals metadata. > >Looks like XFS didn't make it in to the latest 2.4.19 kernel they have >in testing right: > >gentoo-sources-2.4.19-r9 > >I think some of the developers feel they can't recommending XFS due to >past experiences and I think they have the impression that XFS won't or >is hard to patch into their mainline kernel now due to other features >they want to offer. > >I think that other than the metadata, their fears are unfounded but I >don't know how to open a discussion with them them about how some of the >problems that they experienced with early XFS up to and including 1.1 >(where the 2.4.19-r7 XFS patches come from) does not reflect on the >sheer amount of testing and bug fixing have occured in CVS (even if you >just consider the 2.4.19 XFS kernel sync) > >Perhaps I could patch a current XFS into their current (2.4.19-r9) and >running the test suite? Is there anything else that might be suggested. > >I suppose a good starting point would be to see which of their patches >overlap with the XFS 2.4.19 or CVS code. > >-Mike > >Simon Matter wrote: > > >>Many thanks and congratulations to everyone involved!!! >>This is what I was waiting for so long, thanks. >> >>Simon >> >> >>On Tuesday 17 September 2002 00:05, utz lehmann wrote: >> >> >> >>>saw this on lwn.net. linus had merged XFS in the 2.5 tree. >>> >>>congratulation! >>> >>>and many thanks to all who made this possible. >>> >>> >>>utz >>> >>> > > > > did You do an emerge -s xfs? I know that a few day ago, xfs-sources still popped up. Regards, Harald -- Harald Wagener*An der Alster 42*20099 Hamburg*http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 08:30:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 08:30:34 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HFU2tG004214 for ; Tue, 17 Sep 2002 08:30:03 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rKNM-0004rB-00; Tue, 17 Sep 2002 09:34:57 -0600 Message-ID: <3D874BA3.5040809@emergence.com> Date: Tue, 17 Sep 2002 09:34:59 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbest@emergence.com CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <3D87944B.8040206@hamburg.fcb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Yes, the xfs-sources are using the 2.4.19 kernel tree. The gentoo-sources-2.4.19-r7 contains the older xfs 1.1 code, the new proposed gentoo-sources-2.4.19-r9 does not contain xfs at all. But based on comments I've read, it probably better for XFS to not be included and force people to use the xfs-sources tree. -Mike Harald Wagener wrote: > did You do an emerge -s xfs? I know that a few day ago, xfs-sources > still popped up. > > Regards, > Harald From owner-linux-xfs@oss.sgi.com Tue Sep 17 09:56:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 09:56:31 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HGuRtG009238 for ; Tue, 17 Sep 2002 09:56:27 -0700 Received: from vk-clued0.fnal.gov ([131.225.224.23]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0H2L006AFDYDFT@smtp.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 12:01:26 -0500 (CDT) Date: Tue, 17 Sep 2002 12:01:23 -0500 (CDT) From: vkuznet Subject: Re: XFS mount failure In-reply-to: <4.3.2.7.2.20020917085626.038c0d90@pop.xs4all.nl> To: Seth Mos Cc: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vkuznet@fnal.gov Precedence: bulk X-list: linux-xfs The controller we use is 3Ware Escalade 7850. Thanks for help, I used suggestion to mount xfs with -nouuid and at least we are able now to make a backup and them will think about upgrade of XFS. Valentin. On Tue, 17 Sep 2002, Seth Mos wrote: > At 12:01 16-9-2002 -0500, vkuznet wrote: > >Hi, > >we do have 3Ware RAID machine where XFS is using. > >After unexpected reboot we cannot longer mount our XFS filesystem. > > > >Here the /var/log/messages > > > >Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold > >exceeded: Port #6. > >Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - > >can't mount > > I don't know about a 3ware controllers but I'd say the smart on the disk on > port 6 is telling the controller that it's going bad. > Better check. xfs_repair might be able to fix your filesystem. > > What 3ware controller are you using? > > >Any idea how to fix the problem. > > > >We do have > >Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 > >i686 unknown > >patched kernel with XFS. > > Can you upgrade to something more recent please. You definitely want the > XFS 1.1 release or later. Use CVS or the split patches if you want newer > then 2.4.18. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > From owner-linux-xfs@oss.sgi.com Tue Sep 17 10:55:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 10:55:28 -0700 (PDT) Received: from mail.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HHtHtG014282 for ; Tue, 17 Sep 2002 10:55:21 -0700 Received: from sgo.es (tinto.sgo.es [193.127.97.48]) by mail.sgo.es (8.9.3/8.9.3) with ESMTP id UAA04842 for ; Tue, 17 Sep 2002 20:02:41 +0200 Message-ID: <3D876B70.84EA1A25@sgo.es> Date: Tue, 17 Sep 2002 17:50:40 +0000 From: jose Hernandez Organization: SGO X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.17 + XFS? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhernandez@sgo.es Precedence: bulk X-list: linux-xfs Hello. I would like to install the XFS support for my kernel (2.4.17).but I have seen that the supported kernel is 2.4.9. Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to 2.4.9? Thanks a lot for your help. From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:04:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:04:07 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HI45tG015276 for ; Tue, 17 Sep 2002 11:04:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA57198; Tue, 17 Sep 2002 13:08:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA99337; Tue, 17 Sep 2002 13:08:56 -0500 (CDT) Subject: Re: 2.4.17 + XFS? From: Eric Sandeen To: jose Hernandez Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D876B70.84EA1A25@sgo.es> References: <3D876B70.84EA1A25@sgo.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 17 Sep 2002 13:03:57 -0500 Message-Id: <1032285837.6354.87.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs You have several choices. You could grab old cvs snapshot patches from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/ and apply them to your kernel. Or, you could try backporting the 2.4.18-XFS 1.1 patch to 2.4.17, which would probably not be too hard. ftp://oss.sgi.com/projects/xfs/download/latest/kernel_patches/xfs-1.1-2.4.18-all.patch.bz2 Or, you could upgrade your ancient kernel. :) -Eric On Tue, 2002-09-17 at 12:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:05:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:05:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HI5ZtG015744 for ; Tue, 17 Sep 2002 11:05:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA58251; Tue, 17 Sep 2002 13:10:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA50970; Tue, 17 Sep 2002 13:10:29 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8HI70M27747; Tue, 17 Sep 2002 13:07:00 -0500 Subject: Re: 2.4.17 + XFS? From: Steve Lord To: jose Hernandez Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D876B70.84EA1A25@sgo.es> References: <3D876B70.84EA1A25@sgo.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 13:07:00 -0500 Message-Id: <1032286020.22719.145.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-17 at 12:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > 2.4.9? That's a little old, so is 2.4.17, there are patches and cvs code for 2.4.19 on oss.sgi.com. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:19:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:19:18 -0700 (PDT) Received: from chimta03.algx.net (chimta03.algx.net [216.99.233.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HIJGtG016415 for ; Tue, 17 Sep 2002 11:19:16 -0700 Received: from [192.168.10.106] (ip66-2-81-26.z81-2-66.customer.algx.net [66.2.81.26]) by chimmx03.algx.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H2L007YBHRE5H@chimmx03.algx.net> for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 13:23:38 -0500 (CDT) Date: Tue, 17 Sep 2002 14:22:56 -0400 From: John M Trostel Subject: Re: 2.4.17 + XFS? In-reply-to: <3D876B70.84EA1A25@sgo.es> To: jose Hernandez Cc: linux-xfs@oss.sgi.com Message-id: <1032286976.2348.8.camel@jtsdell> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: <3D876B70.84EA1A25@sgo.es> X-archive-position: 443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: john.trostel@quantum.com Precedence: bulk X-list: linux-xfs Hi Jose The currently supported kernel in the CVS tree is 2.4.19 (not 2.4.9). The currently supported kernel for RPM installs with version 1.1 of XFS is kernel 2.4.18. Only if one wants a RH 7.1 or 7.2 rpm install, is the kernel version 2.4.9-x used. I would upgrade my kernel from 2.4.17 to 2.4.19 and take advantage of that advance also, if possible. You could also be somewhat more conservative and upgrade to the version 1.1 of XFS on the 2.4.18 kernel level. (Actually, I have kept my laptop up with the CVS tree... but I enjoy living dangerously.) On Tue, 2002-09-17 at 13:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > > -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:58:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:58:36 -0700 (PDT) Received: from notes.guilford.edu ([192.154.63.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HIwUtG017375 for ; Tue, 17 Sep 2002 11:58:31 -0700 Subject: Can Windows read XFS? To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: vricks@guilford.edu Date: Tue, 17 Sep 2002 15:03:13 -0400 X-MIMETrack: Serialize by Router on notes.guilford.edu/Guilford(Release 5.0.10 |March 22, 2002) at 09/17/2002 03:03:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vricks@guilford.edu Precedence: bulk X-list: linux-xfs I've unsuccessfully checked the archives for the answer to the above question. Are there any programs that allow Windows NT/2k/XP systems to read XFS filesystem data? I have a dual-boot XP/Linux system with the /home partition formatted XFS. Thanks Vance Ricks Assistant Professor of Philosophy Guilford College Greensboro, NC 27410 John M Trostel ntum.com> cc: linux-xfs@oss.sgi.com Sent by: Subject: Re: 2.4.17 + XFS? linux-xfs-bounce@ oss.sgi.com 09/17/02 02:22 PM Hi Jose The currently supported kernel in the CVS tree is 2.4.19 (not 2.4.9). The currently supported kernel for RPM installs with version 1.1 of XFS is kernel 2.4.18. Only if one wants a RH 7.1 or 7.2 rpm install, is the kernel version 2.4.9-x used. I would upgrade my kernel from 2.4.17 to 2.4.19 and take advantage of that advance also, if possible. You could also be somewhat more conservative and upgrade to the version 1.1 of XFS on the 2.4.18 kernel level. (Actually, I have kept my laptop up with the CVS tree... but I enjoy living dangerously.) On Tue, 2002-09-17 at 13:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > > -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:41:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:41:47 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJfjtG018614 for ; Tue, 17 Sep 2002 12:41:45 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.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 MAA00853 for ; Tue, 17 Sep 2002 12:46:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA31979; Tue, 17 Sep 2002 14:37:28 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA06882; Tue, 17 Sep 2002 14:37:28 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8HJXw827934; Tue, 17 Sep 2002 14:33:58 -0500 Subject: Re: Can Windows read XFS? From: Steve Lord To: vricks@guilford.edu Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 14:33:58 -0500 Message-Id: <1032291238.22767.261.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > I've unsuccessfully checked the archives for the answer to the above > question. Are there any programs that allow Windows NT/2k/XP systems to > read XFS filesystem data? I have a dual-boot XP/Linux system with the > /home partition formatted XFS. I am not aware of anything which runs on windows which can read XFS. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:49:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:49:03 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJn0tG019486 for ; Tue, 17 Sep 2002 12:49:01 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 04D0314AEE; Tue, 17 Sep 2002 21:53:55 +0200 (MEST) Date: Tue, 17 Sep 2002 21:53:51 +0200 From: Andi Kleen To: Steve Lord Cc: vricks@guilford.edu, linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? Message-ID: <20020917215351.A32709@wotan.suse.de> References: <1032291238.22767.261.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032291238.22767.261.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 02:33:58PM -0500, Steve Lord wrote: > On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > > > I've unsuccessfully checked the archives for the answer to the above > > question. Are there any programs that allow Windows NT/2k/XP systems to > > read XFS filesystem data? I have a dual-boot XP/Linux system with the > > /home partition formatted XFS. > > I am not aware of anything which runs on windows which can read XFS. I guess vmware on Windows with a linux in it would do the trick... -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:49:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:50:02 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJnwtG020098 for ; Tue, 17 Sep 2002 12:49:58 -0700 Received: from erbenson.alaska.net (100-pm30.nwc.alaska.net [209.112.158.100]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8HJsrBs076509 for ; Tue, 17 Sep 2002 11:54:55 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 463363A0F for ; Tue, 17 Sep 2002 11:54:50 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 575364104E7; Tue, 17 Sep 2002 11:54:50 -0800 (AKDT) Date: Tue, 17 Sep 2002 11:54:50 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917195450.GE10776@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <3D87944B.8040206@hamburg.fcb.com> <3D874BA3.5040809@emergence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gMR3gsNFwZpnI/Ts" Content-Disposition: inline In-Reply-To: <3D874BA3.5040809@emergence.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --gMR3gsNFwZpnI/Ts Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2002 at 09:34:59AM -0600, Michael Best wrote: > Yes, the xfs-sources are using the 2.4.19 kernel tree. >=20 > The gentoo-sources-2.4.19-r7 contains the older xfs 1.1 code, the new > proposed gentoo-sources-2.4.19-r9 does not contain xfs at all. and they expect that to work? 1.1 was made for 2.4.18, its not all that surprising it doesn't get along with 2.4.19, especially with the half dozen other random patches they added alongside. i always suspected the gentoo people were just spewing FUD when one told me `XFS is vile crap' now im sure. > But based on comments I've read, it probably better for XFS to not be > included and force people to use the xfs-sources tree. yes, since they obviously don't know how to do it right. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --gMR3gsNFwZpnI/Ts Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2HiIoACgkQJKx7GixEevz80QCfS6nS26wT/be5c9W2D38NshDg QloAnAolwmY7HERbXd3eKdrm2daMRmwQ =guMz -----END PGP SIGNATURE----- --gMR3gsNFwZpnI/Ts-- From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:50:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:50:45 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJogtG020609 for ; Tue, 17 Sep 2002 12:50:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA56798; Tue, 17 Sep 2002 14:55:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA56862; Tue, 17 Sep 2002 14:55:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8HJq6b28064; Tue, 17 Sep 2002 14:52:06 -0500 Subject: Re: Can Windows read XFS? From: Steve Lord To: Andi Kleen Cc: vricks@guilford.edu, linux-xfs@oss.sgi.com In-Reply-To: <20020917215351.A32709@wotan.suse.de> References: <1032291238.22767.261.camel@jen.americas.sgi.com> <20020917215351.A32709@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 14:52:06 -0500 Message-Id: <1032292326.22719.264.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-17 at 14:53, Andi Kleen wrote: > On Tue, Sep 17, 2002 at 02:33:58PM -0500, Steve Lord wrote: > > On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > > > > > I've unsuccessfully checked the archives for the answer to the above > > > question. Are there any programs that allow Windows NT/2k/XP systems to > > > read XFS filesystem data? I have a dual-boot XP/Linux system with the > > > /home partition formatted XFS. > > > > I am not aware of anything which runs on windows which can read XFS. > > I guess vmware on Windows with a linux in it would do the trick... True, but then you are reading it into a linux application not a windows one.... Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:59:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:59:49 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJxktG022167 for ; Tue, 17 Sep 2002 12:59:46 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E2A6A14AED; Tue, 17 Sep 2002 22:04:40 +0200 (MEST) Date: Tue, 17 Sep 2002 22:04:34 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , vricks@guilford.edu, linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? Message-ID: <20020917220434.A2985@wotan.suse.de> References: <1032291238.22767.261.camel@jen.americas.sgi.com> <20020917215351.A32709@wotan.suse.de> <1032292326.22719.264.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032292326.22719.264.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 02:52:06PM -0500, Steve Lord wrote: > On Tue, 2002-09-17 at 14:53, Andi Kleen wrote: > > On Tue, Sep 17, 2002 at 02:33:58PM -0500, Steve Lord wrote: > > > On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > > > > > > > I've unsuccessfully checked the archives for the answer to the above > > > > question. Are there any programs that allow Windows NT/2k/XP systems to > > > > read XFS filesystem data? I have a dual-boot XP/Linux system with the > > > > /home partition formatted XFS. > > > > > > I am not aware of anything which runs on windows which can read XFS. > > > > I guess vmware on Windows with a linux in it would do the trick... > > True, but then you are reading it into a linux application not a > windows one.... ... but you can run samba on the linux and then Windows apps can read it via a network drive. Apparently someone is working on making User Mode Linux work on Windows too, so you may be able to go via this route too. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 17 13:23:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 13:23:23 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HKNGtG024987 for ; Tue, 17 Sep 2002 13:23:16 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8HKSFq02374 for ; Tue, 17 Sep 2002 16:28:15 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8HKSFC02368 for ; Tue, 17 Sep 2002 16:28:15 -0400 Date: Tue, 17 Sep 2002 16:28:15 -0400 (EDT) From: Benito Venegas To: Subject: Kernel HANG Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463806619-1244800539-1032294495=:22051" X-archive-position: 450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs 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. ---1463806619-1244800539-1032294495=:22051 Content-Type: TEXT/PLAIN; charset=US-ASCII HW: Dell PE 2450 1 CPU 512 MB ram 2x 16 GB HD , RAID 1 using perc3 card. (aacraid module) Kernel 2.4.9-31SGI_XFS_1.1 compiled with gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) (mm...I supposed to have egc or gcc3 ....mm :/ ) nfs client. mounting 1 partition from man SAN server (1/4 TB) This server was in production until 2 days ago, when creashed by 2 second time and we couldn;t see kernel panic in console (was too big) We connected a serial console and vuala', after to reboot server and active one of our process that sycronize data using rsync, machine crashed again. any idea? can be the compiler I used to build kernel? btw, I have several servers installed with this kernel version since Build Date: Tue 23 Apr 2002 05:13:59 PM GMT and this is the first big problem. The only new module (since aug 15) in this server is snare to do audit to some process and users. we disabled after this 3rd crash. Any suggestion? attached you will find more info. Thanks for you help Vene.- Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf <1>Unable to handle kernel paging request at virtual address 04a20000 printing eip: dfdf4282 *pde = 00000000 Oops: 0002 Kernel 2.4.9-31SGI_XFS_1.1 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010286 EIP is at ___strtok_R29805c13 [] 0x1f9edc6e eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 ds: 0018 es: 0018 ss: 0018 Process rsync (pid: 4785, stackpage=d823f000) Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b 00000000 c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 0000000b d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 df68fb24 ---1463806619-1244800539-1032294495=:22051 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="crash.cap" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="crash.cap" Q29kZTogYTIgMDAgMDAgYTIgMDQgZGQgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMGMgYmYgMWMgYzAgNTggYmYgDQoNCiA8MT5VbmFibGUgdG8gaGFuZGxl IGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDRh MjAwMDANCiBwcmludGluZyBlaXA6DQpkZmRmNDI4Mg0KKnBkZSA9IDAwMDAw MDAwDQpPb3BzOiAwMDAyDQpLZXJuZWwgMi40LjktMzFTR0lfWEZTXzEuMQ0K Q1BVOiAgICAwDQpFSVA6ICAgIDAwMTA6WzxkZmRmNDI4Mj5dICAgIFRhaW50 ZWQ6IFAgDQpFRkxBR1M6IDAwMDEwMjg2DQpFSVAgaXMgYXQgX19fc3RydG9r X1IyOTgwNWMxMyBbXSAweDFmOWVkYzZlIA0KZWF4OiBkZmRmNDI4MiAgIGVi eDogMDAwMDAwMDIgICBlY3g6IGRmNjhmYjI0ICAgZWR4OiBkZjY4ZmFjMA0K ZXNpOiBkODIzZTAwMCAgIGVkaTogZDgyM2UwMDAgICBlYnA6IDAwMDAwMDBi ICAgZXNwOiBkODIzZjA3NA0KZHM6IDAwMTggICBlczogMDAxOCAgIHNzOiAw MDE4DQpQcm9jZXNzIHJzeW5jIChwaWQ6IDQ3ODUsIHN0YWNrcGFnZT1kODIz ZjAwMCkNClN0YWNrOiBjMDExOWNlYyAwMDAwMDAwMiAwMDAwMDAxMiBkODIz ZjE1OCAwMDAwMDAwYiBjMDEwNzMzYiAwMDAwMDAwYiAwMDAwMDAwMCANCiAg ICAgICBjMDExNDExNiBjMDI4NzAzZSBkODIzZjE1OCAwMDAwMDAwMiBkODIz ZTAwMCAwMDAwMDAwMiBjMDExM2Q2MCAwMDAwMDAwYiANCiAgICAgICBkODIz ZTAwMCBkZmRmNDI4MiBkZmRmNDI4MiBkODIzZTAwMCBkZDI0OTk3YyAwNGEy MDAwMCA4MDAwODM4MCBkZjY4ZmIyNCANCkNhbGwgVHJhY2U6IFs8YzAxMTlj ZWM+XSBkb19leGl0IFtrZXJuZWxdIDB4ZDAgDQpbPGMwMTA3MzNiPl0gZGll IFtrZXJuZWxdIDB4NGYgDQpbPGMwMTE0MTE2Pl0gZG9fcGFnZV9mYXVsdCBb a2VybmVsXSAweDNiNiANCls8YzAyODcwM2U+XSBjb3B5cml0ZSBba2VybmVs XSAweDY3ZSANCls8YzAxMTNkNjA+XSBkb19wYWdlX2ZhdWx0IFtrZXJuZWxd IDB4MCANCls8YzAxMWQzNDk+XSBkb19hY2N0X3Byb2Nlc3MgW2tlcm5lbF0g MHgyNzUgDQpbPGMwMWNjNjgwPl0gbGludmZzX3dyaXRlIFtrZXJuZWxdIDB4 MCANCls8YzAxMDZlZDg+XSBlcnJvcl9jb2RlIFtrZXJuZWxdIDB4MzggDQpb PGMwMTE5Y2VjPl0gZG9fZXhpdCBba2VybmVsXSAweGQwIA0KWzxjMDEwNzMz Yj5dIGRpZSBba2VybmVsXSAweDRmIA0KWzxjMDExNDExNj5dIGRvX3BhZ2Vf ZmF1bHQgW2tlcm5lbF0gMHgzYjYgDQpbPGMwMjg3MDNlPl0gY29weXJpdGUg W2tlcm5lbF0gMHg2N2UgDQpbPGMwMTEzZDYwPl0gZG9fcGFnZV9mYXVsdCBb a2VybmVsXSAweDAgDQpbPGMwMTFkMzQ5Pl0gZG9fYWNjdF9wcm9jZXNzIFtr ZXJuZWxdIDB4Mjc1IA0KWzxjMDFjYzY4MD5dIGxpbnZmc193cml0ZSBba2Vy bmVsXSAweDAgDQpbPGMwMTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2VybmVsXSAw eDM4IA0KWzxjMDExOWNlYz5dIGRvX2V4aXQgW2tlcm5lbF0gMHhkMCANCls8 YzAxMDczM2I+XSBkaWUgW2tlcm5lbF0gMHg0ZiANCls8YzAxMTQxMTY+XSBk b19wYWdlX2ZhdWx0IFtrZXJuZWxdIDB4M2I2IA0KWzxjMDI4NzAzZT5dIGNv cHlyaXRlIFtrZXJuZWxdIDB4NjdlIA0KWzxjMDExM2Q2MD5dIGRvX3BhZ2Vf ZmF1bHQgW2tlcm5lbF0gMHgwIA0KWzxjMDI3OWY0MT5dIF9fY29uc3RfdWRl bGF5IFtrZXJuZWxdIDB4MTUgDQpbPGMwMTFkMzQ5Pl0gZG9fYWNjdF9wcm9j ZXNzIFtrZXJuZWxdIDB4Mjc1IA0KWzxjMDFjYzY4MD5dIGxpbnZmc193cml0 ZSBba2VybmVsXSAweDAgDQpbPGMwMTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2Vy bmVsXSAweDM4IA0KWzxjMDExOWNlYz5dIGRvX2V4aXQgW2tlcm5lbF0gMHhk MCANCls8YzAxMDczM2I+XSBkaWUgW2tlcm5lbF0gMHg0ZiANCls8YzAxMTQx MTY+XSBkb19wYWdlX2ZhdWx0IFtrZXJuZWxdIDB4M2I2IA0KWzxjMDI4NzAz ZT5dIGNvcHlyaXRlIFtrZXJuZWxdIDB4NjdlIA0KWzxjMDExM2Q2MD5dIGRv X3BhZ2VfZmF1bHQgW2tlcm5lbF0gMHgwIA0KWzxjMDExZDM0OT5dIGRvX2Fj Y3RfcHJvY2VzcyBba2VybmVsXSAweDI3NSANCls8YzAxY2M2ODA+XSBsaW52 ZnNfd3JpdGUgW2tlcm5lbF0gMHgwIA0KWzxjMDEwNmVkOD5dIGVycm9yX2Nv ZGUgW2tleGl0IFtrZXJuZWxdIDB4ZDAgDQpbPGMwMTEwMDE4Pl0gbXRycl9p b2N0bCBba2VybmVsXSAweDQ4NCANCls8YzAxMDc1NGM+XSBkb19pbnZhbGlk X29wIFtrZXJuZWxdIDB4MCANCls8YzAxMDczM2I+XSBkaWUgW2tlcm5lbF0g MHg0ZiANCls8YzAxMDc1Y2U+XSBkb19pbnZhbGlkX29wIFtrZXJuZWxdIDB4 ODIgDQpbPGMwMjgxMGZhPl0gLnJvZGF0YSBba2VybmVsXSAweDEzM2EgDQpb PGMwMTFkMzQ5Pl0gZG9fYWNjdF9wcm9jZXNzIFtrZXJuZWxdIDB4Mjc1IA0K WzxjMDFjYzY4MD5dIGxpbnZmc193cml0ZSBba2VybmVsXSAweDAgDQpbPGMw MTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2VybmVsXSAweDM4IA0KWzxjMDExOWNl Yz5dIGRvX2V4aXQgW2tlcm5lbF0gMHhkMCANCls8YzAxMTAwMTg+XSBtdHJy X2lvY3RsIFtrZXJuZWxdIDB4NDg0IA0KWzxjMDEwNzU0Yz5dIGRvX2ludmFs aWRfb3AgW2tlcm5lbF0gMHgwIA0KWzxjMDEwNzMzYj5dIGRpZSBba2VybmVs XSAweDRmIA0KWzxjMDEwNzVjZT5dIGRvX2ludmFsaWRfb3AgW2tlcm5lbF0g MHg4MiANCls8YzAyODEwZmE+XSAucm9kYXRhIFtrZXJuZWxdIDB4MTMzYSAN Cls8YzAxMWQzNDk+XSBkb19hY2N0X3Byb2Nlc3MgW2tlcm5lbF0gMHgyNzUg DQpbPGMwMWNjNjgwPl0gbGludmZzX3dyaXRlIFtrZXJuZWxdIDB4MCANCls8 YzAxMDZlZDg+XSBlcnJvcl9jb2RlIFtrZXJuZWxdIDB4MzggDQpbPGMwMTE5 Y2VjPl0gZG9fZXhpdCBba2VybmVsXSAweGQwIA0KWzxjMDExMDAxOD5dIG10 cnJfaW9jdGwgW2tlcm5lbF0gMHg0ODQgDQpbPGMwMTA3MzNiPl0gZGllIFtr ZXJuZWxdIDB4NGYgDQpbPGMwMTE0MTE2Pl0gZG9fcGFnZV9mYXVsdCBba2Vy bmVsXSAweDNiNiANCls8YzAyODcwM2U+XSBjb3B5cml0ZSBba2VybmVsXSAw eDY3ZSANCls8YzAxMTNkNjA+XSBkb19wYWdlX2ZhdWx0IFtrZXJuZWxdIDB4 MCANCls8YzAxMWYwYWU+XSBkZXF1ZXVlX3NpZ25hbCBba2VybmVsXSAweDMy IA0KWzxjMDExZjBhZT5dIGRlcXVldWVfc2lnbmFsIFtrZXJuZWxdIDB4MzIg DQpbPGMwMTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2VybmVsXSAweDM4IA0KWzxj MDExZjBhZT5dIGRlcXVldWVfc2lnbmFsIFtrZXJuZWxdIDB4MzIgDQpbPGMw MTA2YzllPl0gZG9fc2lnbmFsIFtrZXJuZWxdIDB4MjMyIA0KWzxjMDEwNmUx Yz5dIHNpZ25hbF9yZXR1cm4gW2tlcm5lbF0gMHgxNCANCg0K ---1463806619-1244800539-1032294495=:22051-- From owner-linux-xfs@oss.sgi.com Tue Sep 17 18:28:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 18:28:49 -0700 (PDT) Received: from area51.underboost.net (mail@dsl-65-188-232-225.telocity.com [65.188.232.225]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I1SgtG032630 for ; Tue, 17 Sep 2002 18:28:43 -0700 Received: from area51.underboost.net ([65.188.232.225] ident=dijital1) by area51.underboost.net with esmtp (Exim 3.36 #1 (Debian)) id 17r7BZ-0004Vo-00 for ; Mon, 16 Sep 2002 21:29:53 -0400 Date: Mon, 16 Sep 2002 21:29:50 -0400 (AST) From: Ron Henry To: linux-xfs@oss.sgi.com Subject: stat() and xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dijital1@underboost.net Precedence: bulk X-list: linux-xfs if I do stat("filename", &entry); and I then procede to printf() some of the fields of the returned structure, is there a problem with casting the elements to int vs something else? for ex should it be printf("inode: %d\n", (int)entry.st_ino); OR printf("inode: %lld\n", (long long)entry.st_ino); The platform is x86. OS is Linux Ron Henry "the illiterate of the future are not those who can neither read or write; but those who cannot learn, unlearn, and relearn..." From owner-linux-xfs@oss.sgi.com Tue Sep 17 20:16:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 20:16:31 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I3GOtG005147 for ; Tue, 17 Sep 2002 20:16:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 UAA07929 for ; Tue, 17 Sep 2002 20:21:09 -0700 (PDT) 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 NAA08853; Wed, 18 Sep 2002 13:19:47 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA58529; Wed, 18 Sep 2002 13:19:46 +1000 (AEDT) Date: Wed, 18 Sep 2002 13:19:45 +1000 From: Nathan Scott To: Ron Henry Cc: linux-xfs@oss.sgi.com Subject: Re: stat() and xfs Message-ID: <20020918131945.A158353@wobbly.melbourne.sgi.com> 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 dijital1@underboost.net on Mon, Sep 16, 2002 at 09:29:50PM -0400 X-archive-position: 452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs hi, On Mon, Sep 16, 2002 at 09:29:50PM -0400, Ron Henry wrote: > if I do stat("filename", &entry); and I then procede to printf() some of > the fields of the returned structure, is there a problem with casting the > elements to int vs something else? for ex should it be > > printf("inode: %d\n", (int)entry.st_ino); OR > > printf("inode: %lld\n", (long long)entry.st_ino); > > The platform is x86. OS is Linux > The latter is more correct - the first would chop off the top 32 bits (and get the wrong result, should the inode number be greater than 2^32 - 1). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 17 20:25:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 20:26:02 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I3PwtG005680 for ; Tue, 17 Sep 2002 20:25:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 UAA09369 for ; Tue, 17 Sep 2002 20:30:54 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA51128 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 13:29:35 +1000 (EST) Date: Wed, 18 Sep 2002 13:29:35 +1000 (EST) From: Nathan Scott Message-Id: <200209180329.NAA51128@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA X-archive-position: 453 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Sep 17 20:28:20 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127713a cmd/xfstests/bench - 1.1 - First cut at a framework for running benchmarks along with all of the functional tests we have. Aim is to get wind of performance regressions as changes are checked in, rather than at arbitrary points down the track. Still work to do wrt this framework though. cmd/xfstests/run.dbench - 1.1 - wrapper script for running dbench with a configurable number of clients and spitting out csv format values. cmd/xfstests/run.tar - 1.1 - wrapper script for running untar with a configurable tar file and then spitting out csv format values. cmd/xfstests/common.config - 1.22 - Move all configurations in here - previously some options lived in the auto-qa script and some here. cmd/xfstests/tools/auto-qa - 1.34 - Move configuration options out of here and into common.config. Add in a hook to call out to the bench script, if requested. From owner-linux-xfs@oss.sgi.com Tue Sep 17 20:46:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 20:46:31 -0700 (PDT) Received: from mail.miratek.com ([216.97.55.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I3kNtG006473 for ; Tue, 17 Sep 2002 20:46:24 -0700 Received: from maherxp [24.145.147.99] by mail.miratek.com with ESMTP (SMTPD32-7.13) id A6E217C01AE; Tue, 17 Sep 2002 22:45:38 -0500 Reply-To: From: "Mike" To: Subject: Install 24.18-4SMP Date: Tue, 17 Sep 2002 23:51:01 -0400 Message-ID: <001301c25ec6$9ca093a0$9c7ba8c0@maherxp> 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, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-archive-position: 454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: samba@miratek.com Precedence: bulk X-list: linux-xfs I am trying to install kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm on a redhat 7.2 and I am getting the following error: [root ~]# rpm -ivh kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm error: failed dependencies: dev < 3.2-7 conflicts with kernel-smp-2.4.18-4SGI_XFS_1.1 Any help is greatly appreciated. I do not have a dev 3.2-7 rpm: [root ~]# rpm -q dev dev-3.2-5 I am on 2.4.9-34SGI_XFS_1.1smp kernel now. And I am having nfsd kernel error when I run xfsdump. It hangs nfsd and the only way to restart nfs is to reboot. I am hoping that 2.4.18-4 will fix this problem. Thanks, Mike From owner-linux-xfs@oss.sgi.com Tue Sep 17 23:58:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 23:58:53 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I6wmtG011669 for ; Tue, 17 Sep 2002 23:58:50 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8I73jT7092805; Wed, 18 Sep 2002 09:03:49 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id AF16F65104; Wed, 18 Sep 2002 09:03:45 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: Benito Venegas , Subject: Re: Kernel HANG Date: Wed, 18 Sep 2002 09:03:44 +0200 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <20020918070345.AF16F65104@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8I6wptG011670 X-archive-position: 455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs On Tuesday 17 September 2002 22:28, Benito Venegas wrote: > HW: Dell PE 2450 > 1 CPU > 512 MB ram > 2x 16 GB HD , RAID 1 using perc3 card. (aacraid module) > Kernel 2.4.9-31SGI_XFS_1.1 > compiled with > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) > (mm...I supposed to have egc or gcc3 ....mm :/ ) > > nfs client. mounting 1 partition from man SAN server (1/4 TB) > > > This server was in production until 2 days ago, when creashed by 2 second > time and we couldn;t see kernel panic in console (was too big) > We connected a serial console and vuala', after to reboot server and > active one of our process that sycronize data using rsync, machine > crashed again. Do you use rsync in verbose mode? This was my problem some months ago when I had many crashes using XFS/rsync. Then I read this verbose thing on lkml (or was it rsync ML) and removing verbose option from rsync helped. And of course, you didn't use the recommended compiler, did you? Have a look at ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/contributed/2.4.9-34-RH/ HTH Simon > > any idea? can be the compiler I used to build kernel? > btw, I have several servers installed with this kernel version since > > Build Date: Tue 23 Apr 2002 05:13:59 PM GMT > > and this is the first big problem. > > The only new module (since aug 15) in this server is snare to do audit to > some process and users. we disabled after this 3rd crash. > > Any suggestion? > attached you will find more info. > > Thanks for you help > > Vene.- > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > <1>Unable to handle kernel paging request at virtual address 04a20000 > printing eip: > dfdf4282 > *pde = 00000000 > Oops: 0002 > Kernel 2.4.9-31SGI_XFS_1.1 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010286 > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > ds: 0018 es: 0018 ss: 0018 > Process rsync (pid: 4785, stackpage=d823f000) > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > 00000000 > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > 0000000b > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > df68fb24 From owner-linux-xfs@oss.sgi.com Wed Sep 18 00:11:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 00:11:12 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I7B9tG012858 for ; Wed, 18 Sep 2002 00:11:10 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8I7G8T7094214; Wed, 18 Sep 2002 09:16:09 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id EC61A65104; Wed, 18 Sep 2002 09:16:07 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: , Subject: Re: Install 24.18-4SMP Date: Wed, 18 Sep 2002 09:16:07 +0200 X-Mailer: KMail [version 1.3.2] References: <001301c25ec6$9ca093a0$9c7ba8c0@maherxp> In-Reply-To: <001301c25ec6$9ca093a0$9c7ba8c0@maherxp> MIME-Version: 1.0 Message-Id: <20020918071607.EC61A65104@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8I7BBtG012871 X-archive-position: 456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs On Wednesday 18 September 2002 05:51, Mike wrote: > I am trying to install kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm on a > redhat 7.2 and I am getting the following error: > > [root ~]# rpm -ivh kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm > error: failed dependencies: > dev < 3.2-7 conflicts with kernel-smp-2.4.18-4SGI_XFS_1.1 > > Any help is greatly appreciated. I do not have a dev 3.2-7 rpm: > [root ~]# rpm -q dev > dev-3.2-5 kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm belongs to RH 7.3, so you may try the dev rpm from 7.3. Simon > > I am on 2.4.9-34SGI_XFS_1.1smp kernel now. And I am having nfsd kernel > error when I run xfsdump. It hangs nfsd and the only way to restart nfs > is to reboot. I am hoping that 2.4.18-4 will fix this problem. > > Thanks, > > Mike From owner-linux-xfs@oss.sgi.com Wed Sep 18 01:47:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 01:47:34 -0700 (PDT) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I8lTtG014257 for ; Wed, 18 Sep 2002 01:47:30 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8I8qTTh013718; Wed, 18 Sep 2002 10:52:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8I8qTO52042; Wed, 18 Sep 2002 10:52:29 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 18 Sep 2002 10:52:29 +0200 (CEST) From: Seth Mos To: vkuznet cc: linux-xfs@oss.sgi.com Subject: Re: XFS mount failure In-Reply-To: Message-ID: <20020918105102.N49810-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Tue, 17 Sep 2002, vkuznet wrote: > The controller we use is 3Ware Escalade 7850. > Thanks for help, I used suggestion to mount xfs with -nouuid > and at least we are able now to make a backup and them will think > about upgrade of XFS. Okay, do check the disk on port 6. It's complaining about something. It might have been causing troubles. It shouldn't have, but computers are just people after all. Cheers From owner-linux-xfs@oss.sgi.com Wed Sep 18 01:52:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 01:52:09 -0700 (PDT) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I8q6tG014878 for ; Wed, 18 Sep 2002 01:52:07 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8I8v5Th016348; Wed, 18 Sep 2002 10:57:05 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8I8v5152274; Wed, 18 Sep 2002 10:57:05 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 18 Sep 2002 10:57:04 +0200 (CEST) From: Seth Mos To: vricks@guilford.edu cc: linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? In-Reply-To: Message-ID: <20020918105654.I49810-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Tue, 17 Sep 2002 vricks@guilford.edu wrote: > > I've unsuccessfully checked the archives for the answer to the above > question. Are there any programs that allow Windows NT/2k/XP systems to > read XFS filesystem data? I have a dual-boot XP/Linux system with the > /home partition formatted XFS. No. Cheers From owner-linux-xfs@oss.sgi.com Wed Sep 18 01:55:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 01:55:22 -0700 (PDT) Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I8tJtG015415 for ; Wed, 18 Sep 2002 01:55:20 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8I90KZo009771; Wed, 18 Sep 2002 11:00:21 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8I90Kg52406; Wed, 18 Sep 2002 11:00:20 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 18 Sep 2002 11:00:20 +0200 (CEST) From: Seth Mos To: Benito Venegas cc: linux-xfs@oss.sgi.com Subject: Re: Kernel HANG In-Reply-To: Message-ID: <20020918105959.M49810-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Tue, 17 Sep 2002, Benito Venegas wrote: Run it through ksymoops please. > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > <1>Unable to handle kernel paging request at virtual address 04a20000 > printing eip: > dfdf4282 > *pde = 00000000 > Oops: 0002 > Kernel 2.4.9-31SGI_XFS_1.1 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010286 > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > ds: 0018 es: 0018 ss: 0018 > Process rsync (pid: 4785, stackpage=d823f000) > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > 00000000 > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > 0000000b > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > df68fb24 > > > From owner-linux-xfs@oss.sgi.com Wed Sep 18 03:14:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 03:14:39 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IAEXtG016895 for ; Wed, 18 Sep 2002 03:14:33 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 902B31D5306; Wed, 18 Sep 2002 03:19:35 -0700 (PDT) Date: Wed, 18 Sep 2002 03:19:35 -0700 From: Chris Wedgwood To: Simon Matter Cc: Benito Venegas , linux-xfs@oss.sgi.com Subject: Re: Kernel HANG Message-ID: <20020918101935.GA16439@tapu.f00f.org> References: <20020918070345.AF16F65104@xxl.bi.corp.invoca.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918070345.AF16F65104@xxl.bi.corp.invoca.ch> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Sep 18, 2002 at 09:03:44AM +0200, Simon Matter wrote: > Do you use rsync in verbose mode? This was my problem some months > ago when I had many crashes using XFS/rsync. Then I read this > verbose thing on lkml (or was it rsync ML) and removing verbose > option from rsync helped. Verbose, terse or otherwise ... rsync should not cause an oops. Benito, can you please try a more recent kernel? 2.4.9 is rather old. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 18 03:37:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 03:37:08 -0700 (PDT) Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IAb4tG017924 for ; Wed, 18 Sep 2002 03:37:05 -0700 Message-Id: <200209181037.g8IAb4tG017924@oss.sgi.com> Received: from there ([144.135.25.75]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15 mta05ps Jul 16 2002 22:47:55) with SMTP id H2MR2000.99Q for ; Wed, 18 Sep 2002 20:42:00 +1000 Received: from CPE-203-51-226-46.qld.bigpond.net.au ([203.51.226.46]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0n 89/9604230); 18 Sep 2002 20:42:00 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Date: Wed, 18 Sep 2002 20:41:57 +1000 X-Mailer: KMail [version 1.3.1] References: <20020917000532.A18289@s2y4n2c.de> <3D87944B.8040206@hamburg.fcb.com> <3D874BA3.5040809@emergence.com> In-Reply-To: <3D874BA3.5040809@emergence.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ahead@bigpond.net.au Precedence: bulk X-list: linux-xfs For those people out there including me that didn't know about this until now - here are a few Gentoo mailing list pointers. Various posts regarding XFS vs yda yda yda... w.r.t. Gentoo & Data loss. http://marc.theaimsgroup.com/?l=gentoo-user&m=103180819906339&w=2 http://marc.theaimsgroup.com/?l=gentoo-user&m=103180893506745&w=2 http://marc.theaimsgroup.com/?l=gentoo-user&m=103185359619182&w=2 http://marc.theaimsgroup.com/?l=gentoo-user&m=103185563621841&w=2 This basically sums the argument up... http://marc.theaimsgroup.com/?l=gentoo-user&m=103184030901850&w=2 The start of the thread can be found here: http://marc.theaimsgroup.com/?l=gentoo-user&m=103175216417207&w=2 -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Wed Sep 18 03:41:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 03:41:15 -0700 (PDT) Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IAfCtG018391 for ; Wed, 18 Sep 2002 03:41:13 -0700 Message-Id: <200209181041.g8IAfCtG018391@oss.sgi.com> Received: from there ([144.135.25.78]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps Jul 16 2002 22:47:55) with SMTP id H2MR8X00.6MV for ; Wed, 18 Sep 2002 20:46:09 +1000 Received: from CPE-203-51-226-46.qld.bigpond.net.au ([203.51.226.46]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0n 98/10053110); 18 Sep 2002 20:46:09 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Date: Wed, 18 Sep 2002 20:46:06 +1000 X-Mailer: KMail [version 1.3.1] References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> In-Reply-To: <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ahead@bigpond.net.au Precedence: bulk X-list: linux-xfs Thanks to the hard working XFS team, the major goal of getting XFS into the 2.5/6+ kernel has been achieved. The only way to go now is up ;-) Congratulations to everyone involved. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Wed Sep 18 05:25:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 05:25:20 -0700 (PDT) Received: from mail.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ICPDtG020577 for ; Wed, 18 Sep 2002 05:25:17 -0700 Received: from sgo.es (ecastyneira.sgo.es [193.127.97.115] (may be forged)) by mail.sgo.es (8.9.3/8.9.3) with ESMTP id OAA08897 for ; Wed, 18 Sep 2002 14:32:36 +0200 Message-ID: <3D886F99.EF7A6BC8@sgo.es> Date: Wed, 18 Sep 2002 12:20:41 +0000 From: jose Hernandez Organization: SGO X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.17 + XFS Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 944 X-archive-position: 463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhernandez@sgo.es Precedence: bulk X-list: linux-xfs At first, thanks for your quickly response. I am not a expert in linux. Normally I work with Irix. I have download the patch of XFS for 2.4.17, but after I have patched it , I try to rebuild the kernel but (make bzImage) , but it give me several compilation errors. In any case I have one doubt: Can I use that 2.4.17XFS patch from a original ( without XFS previous version) 2.4.17 kernel? Or Have I to install 2.4.9(with XFS) , then upgrade to 2.4.17 and finally to patch with 2.4.17XFS? On the other hand , I have download from CVS the 2.4.19 version, but I have error compiling the kernel. Exactly the error is that the file kernel.h is including a file called stdarg.h , and this file is not found. I think that I have done fine all the steps(mrproper,config...), but it is the firs time that a CLEAN kernel give me errors. Thanks a lot for your help. Salud y suerte,Jose. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Sep 18 05:50:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 05:50:57 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ICoptG021422 for ; Wed, 18 Sep 2002 05:50:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA63814 for ; Wed, 18 Sep 2002 07:55:49 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA81024 for ; Wed, 18 Sep 2002 07:55:48 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IKAlm25990 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 16:10:47 -0400 Resent-Message-Id: <200209182010.g8IKAlm25990@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA58749 for ; Wed, 18 Sep 2002 07:52:42 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IK7gZ25927 for hch@sgi.com; Wed, 18 Sep 2002 16:07:42 -0400 Date: Wed, 18 Sep 2002 16:07:42 -0400 From: Christoph Hellwig Message-Id: <200209182007.g8IK7gZ25927@dhcp212.munich.sgi.com> Subject: TAKE - Small comment corrections/updates Resent-Date: Wed, 18 Sep 2002 16:10:47 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Sep 18 05:33:01 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127729a linux/fs/xfs/linux/xfs_vnode.h - 1.64 - Small comment corrections/updates From owner-linux-xfs@oss.sgi.com Wed Sep 18 05:52:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 05:52:48 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ICqjtG021688 for ; Wed, 18 Sep 2002 05:52:45 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8ICvgGc014467; Wed, 18 Sep 2002 14:57:42 +0200 (CEST) Message-Id: <4.3.2.7.2.20020918145423.0386a350@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Sep 2002 14:56:22 +0200 To: Adrian Head , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Linus merges XFS In-Reply-To: <200209181037.g8IAb4tG017924@oss.sgi.com> References: <3D874BA3.5040809@emergence.com> <20020917000532.A18289@s2y4n2c.de> <3D87944B.8040206@hamburg.fcb.com> <3D874BA3.5040809@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 20:41 18-9-2002 +1000, Adrian Head wrote: >This basically sums the argument up... >http://marc.theaimsgroup.com/?l=gentoo-user&m=103184030901850&w=2 I'd say so yes. It gives new meaning to the "Test in your environment and see if it works for you" argument. I have seen lot's of things fail over the years to which some people say that it shouldn't be possible, but it happens anyways. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 18 07:23:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 07:23:32 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IENQtG031562 for ; Wed, 18 Sep 2002 07:23:27 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA65097 for ; Wed, 18 Sep 2002 09:28:25 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA73231 for ; Wed, 18 Sep 2002 09:28:23 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8ILhMF28323 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 17:43:22 -0400 Resent-Message-Id: <200209182143.g8ILhMF28323@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA90925 for ; Wed, 18 Sep 2002 09:27:40 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8ILgel28313 for hch@sgi.com; Wed, 18 Sep 2002 17:42:40 -0400 Date: Wed, 18 Sep 2002 17:42:40 -0400 From: Christoph Hellwig Message-Id: <200209182142.g8ILgel28313@dhcp212.munich.sgi.com> Subject: TAKE - Make pagebuf use the generic xfs ASSERT() instead of it's own assert() Resent-Date: Wed, 18 Sep 2002 17:43:22 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs This is a leftover from the times when pagebug wasn't part of the XFS module Date: Wed Sep 18 07:26:00 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127736a linux/fs/xfs/pagebuf/Makefile - 1.14 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.30 linux/fs/xfs/pagebuf/page_buf.c - 1.63 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.15 - Make pagebuf use the generic xfs ASSERT() instead of it's own assert() From owner-linux-xfs@oss.sgi.com Wed Sep 18 07:53:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 07:53:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IErjtG032340 for ; Wed, 18 Sep 2002 07:53:46 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA39200 for ; Wed, 18 Sep 2002 09:58:44 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA57891 for ; Wed, 18 Sep 2002 09:58:43 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IMDgn28945 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 18:13:42 -0400 Resent-Message-Id: <200209182213.g8IMDgn28945@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA33565 for ; Wed, 18 Sep 2002 09:58:29 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IMDTR28939 for hch@sgi.com; Wed, 18 Sep 2002 18:13:29 -0400 Date: Wed, 18 Sep 2002 18:13:29 -0400 From: Christoph Hellwig Message-Id: <200209182213.g8IMDTR28939@dhcp212.munich.sgi.com> Subject: TAKE - Add back a invalidate_inode_pages2 that got lost in the XFS tree Resent-Date: Wed, 18 Sep 2002 18:13:42 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs XFS does this differently so this might only have caused problems if you used O_DIRECT on a non-XFS filesystem with the XFS tree. Date: Wed Sep 18 07:56:59 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127737a linux/mm/filemap.c - 1.115 - Add back a invalidate_inode_pages2 that got lost in the XFS tree From owner-linux-xfs@oss.sgi.com Wed Sep 18 10:03:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 10:03:44 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IH3atG005390 for ; Wed, 18 Sep 2002 10:03:37 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8GGud7O020548; Mon, 16 Sep 2002 17:56:39 +0100 Reply-To: From: "Ian D. Hardy" To: "'Stephen Lord'" Cc: Subject: RE: Re-occurance of NFS server panics Date: Mon, 16 Sep 2002 17:56:40 +0100 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, Build 10.0.3416 In-Reply-To: <1032190545.1051.80.camel@laptop.americas.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MailScanner: Believed to be clean X-archive-position: 468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve, Thanks for the quick response. I don't always get a Oops output (sometimes the server just hangs and requires a reboot). However as it happens the server has just crashed again with the following Oops (through 'ksymoops'): EFLAGS: 00010016 eax: 5a2cf071 ebx: 003a0dc0 ecx: f7ee3dd0 edx: c200b060 esi: ce837000 edi: ce8372b4 ebp: ce837ce0 esp: f7ee1f38 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7ee1000) Stack: f7ee0000 00000009 f7ee3dd0 f7ee3c00 00000000 00000007 00000000 00000000 00000000 c200b060 00000020 000001d0 00000006 00000000 c01325d9 c036aa70 00000006 000001d0 c036aa70 00000000 c013268c 00000020 c036aa70 00000002 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 2c 5a 01 ca 87 42 >>EIP; c013127e <===== Trace; c01325d8 Trace; c013268c Trace; c0132730 Trace; c01327a6 Trace; c01328e0 Trace; c0132840 Trace; c0105000 <_stext+0/0> Trace; c0105836 Trace; c0132840 Code; c013127e 00000000 <_EIP>: Code; c013127e <===== 0: 0f 0b ud2a <===== Code; c0131280 2: 8b 44 24 24 mov 0x24(%esp,1),%eax Code; c0131284 6: 89 ea mov %ebp,%edx Code; c0131286 8: 8b 48 18 mov 0x18(%eax),%ecx Code; c0131288 b: b8 71 f0 2c 5a mov $0x5a2cf071,%eax Code; c013128e 10: 01 ca add %ecx,%edx Code; c0131290 12: 87 42 00 xchg %eax,0x0(%edx) Entering kdb (current=0xf7ee0000, pid 5) on processor 1 Oops: invalid operand eax = 0x5a2cf071 ebx = 0x003a0dc0 ecx = 0xf7ee3dd0 edx = 0xc200b060 esi = 0xce837000 edi = 0xce8372b4 esp = 0xf7ee1f38 eip = 0xc013127e ebp = 0xce837ce0 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 ->====================================================================== This is a different trace to the last one I posted, this new one makes no direct reference to XFS which may mean that it is not XFS related (in which case apologies....) or that it was another non XFS process (kswapd) that ran into difficulty in obtaining kernel memory as a result of XFS/extent issues. I seem to remember that the was an issue with the XFS/KDB implementation around the time of the CVS kernel I'm currently using. (No, the server shouldn't be running out of memory, it has 1Gbyte RAM and does nothing but NFS serving, it normally has ~957684K cached). If I remember correctly we have tried the fix you refer to regarding memory getting freed to the wrong pool: > > Only happens under high memory pressure, Ian, I think this was > your original oops. > > Date: Wed Mar 20 11:06:42 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > Modid: 2.4.x-xfs:slinx:114531a > linux/fs/xfs_support/kmem.c - 1.22 > - Fix the case where we used vmalloc to allocate memory under pressure, > we need to free it that way Anyway, I think I need to get the current 2.4.19-XFS tree installed even if this doesn't fix the problem it will give us a better base to work from. Regards Ian Hardy -----Original Message----- From: Stephen Lord [mailto:lord@sgi.com] Sent: 16 September 2002 16:36 To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com Subject: RE: Re-occurance of NFS server panics On Mon, 2002-09-16 at 09:52, Ian D. Hardy wrote: > Steve +, > > Sorry to bother you again. You may remember that we've corresponded > several times over the past ~9months with regards to kernel memory > allocation problems and fragmented files (see bellow). > > We had a period of relative stability, however the last few weeks we > have gone back to a situation of having one or more crashes/hangs > every week and are now having to again review our continued use of > XFS. Therefore any update on progress towards a fix for these > problems would be very useful (I'd hate to go though the pain of > converting our ~1Tbyte filesystem to Reiser of ext3 if there are fixes > immanent). > > We have been running a 2.4.18 XFS CVS kernel from Mid May for some > time now, I'm just in the process of compiling and testing the current > 2.4.19 XFS CVS, is this likely to help? (looking through the list > archive I can't find anything of direct relevance but may have missed > something). > > We appear to be running at a lower overall system fragmentation level > now (currently 13% in the past it has been 28% or more), though I > guess it is possible for only a couple of large very fragmented files > to result in kernel memory allocation problems and still have > reasonably low overall FS fragmentation levels? > > Unfortunately the NFS load on our server is such that it is > difficult/impossible to predict times of light NFS load in which to > run fsr and as reported before we've had several incidents of > filesystem corruption and the kernel taking the FS offline running fsr > under a NFS load. > > Thanks for your time (BTW: We've persevered with XFS for so long as it > seems to give better performance for our workload than ext3 or > ReiserFS, however, stability is again becoming a problem). > Nothing immediately rings a bell, there have been some recent changes which fixed some hangs HP was having in doing large scale NFS benchmarking. These might be beneficial to you. The last oops output I have from you looked like this: >>EIP; c012ff76 <===== Trace; c01fd146 Trace; c01fd1a4 Trace; c01d04f0 Trace; c01a6996 Trace; c01a5f12 Trace; c01d6474 Trace; c01fd2e0 Trace; c01aac14 Trace; c01cf962 Trace; c01e6e22 Trace; c01e6340 Trace; c026cf44 Trace; c01f696e Trace; c01e6340 Trace; c014f45c Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> Trace; f8d2b348 <[nfsd]nfsd+1b8/370> Trace; c01057ea Code; c012ff76 00000000 <_EIP>: Code; c012ff76 <===== 0: 0f 0b ud2a <===== Code; c012ff78 2: 83 c4 08 add $0x8,%esp Code; c012ff7a 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx Code; c012ff80 b: 8b 2c 1a mov (%edx,%ebx,1),%ebp Code; c012ff84 e: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c012ff88 12: b8 00 00 00 00 mov $0x0,%eax Is this still what you see? This one does bear the symptoms of a problem which was fixed a while ago - memory was freed into the wrong pool. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 18 10:16:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 10:16:31 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IHGNtG006270 for ; Wed, 18 Sep 2002 10:16:24 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8IFp5q31044 for ; Wed, 18 Sep 2002 11:51:05 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8IFp4Q31035; Wed, 18 Sep 2002 11:51:04 -0400 Date: Wed, 18 Sep 2002 11:51:04 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: Subject: Re: Kernel HANG In-Reply-To: <20020918105959.M49810-100000@xs1.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463806619-937713930-1032364264=:22051" X-archive-position: 469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs 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. ---1463806619-937713930-1032364264=:22051 Content-Type: TEXT/PLAIN; charset=US-ASCII Kernel Debug is attached to this email. Thanks for your help Seth and xfs list members. Vene.- On Wed, 18 Sep 2002, Seth Mos wrote: > On Tue, 17 Sep 2002, Benito Venegas wrote: > > Run it through ksymoops please. > > > > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > > <1>Unable to handle kernel paging request at virtual address 04a20000 > > printing eip: > > dfdf4282 > > *pde = 00000000 > > Oops: 0002 > > Kernel 2.4.9-31SGI_XFS_1.1 > > CPU: 0 > > EIP: 0010:[] Tainted: P > > EFLAGS: 00010286 > > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > > ds: 0018 es: 0018 ss: 0018 > > Process rsync (pid: 4785, stackpage=d823f000) > > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > > 00000000 > > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > > 0000000b > > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > > df68fb24 > > > > > > > > ---1463806619-937713930-1032364264=:22051 Content-Type: APPLICATION/x-gzip; name="debug-kernel.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="debug-kernel.gz" H4sICHWgiD0AA2RlYnVnLWtlcm5lbADtWmtv47gV/a5fwQ9dNKkd62lb9ngC tIPZRYACO2h2+sBgIVAk5aiRRS9JJc7++r2kHpYcKxN73CbbRghsU7w8vOfw XulSyq18WHG+lsgbBSMX8Rylk3BiWrML373+4Sr65/fXkTtyRwj9uFYpzyUq JKMW0sfF39EZZQkuMnVenblF9lpwYt8CsnzUm1W9K06LjD3u58jO0rjutvf4 YT8as0J2zLmyrx+kYqvRCq8v9oxrDbP+gUWe5ss5+hcvEE0pyrlCimUZWjF0 f8MEQ4qjJM0pAhYxz1CaJ1yssOYPQlyh+zTLLCxlAQPUDYbRNwxlfInAhtwA Md2+ZSJnGcIAU/M1thjwRZFrFyyRLm8UzH9vzK7+CD6AvGZ45S/ilew45ncM gR+1U4JJnhXGJ+sqMWNIIQTLVWtqG+zr2Sk3TI2PtcdD9AAiEJyjJVPWioNv mAAMVgzxQq0LheIHIw64i1aszeyOCQmzG9c7slmwCMN62iEqY4EpAtrd1hF3 cYPYZp3hNC/VqmiOLOujEOD0GfQCcMTjfzOi5PlcO6ndlwqrMxMmOCXTzWYz 4udGlqp5wHhMBE5pM75sPn+8pBFwrIeXrQNGE5l2xlftOjzRGeGrNQRLBGpq hFUqy6UDyasQgG6Vat2iHMPaoErrKMYQRBI/SEQcz5th4gzRNj/qHnc8JVNH B/Qy50JP2RoNYSQeDvElz1byjkRLgQmL1kyknGqHMk5uaTkjc2ZTOvGD4dez vIwwO5G2GV9+jvgWh+BZ0Pb8aMRjeeoY3kvPORE950XpqXTFIP/3UwxPRDF8 IYqJjCiLi6VmJ4tcrEnjlo/H3gErmDNllwjVV4uhjz3nqEXcB3oMSfokywPS 8Gssj8rE07DMVk+SPCBSv0byqGA9CUkY9hRJl5yKpJuQFyW5xCLGSxZhsZR7 uQbJ6bjSl+UqC0KY7KHJTkeTvDBNU3VETIj9weuc7GLrspe72G6oiHjOehbz ZFdal7zclVZTVPe8h+LJrrMuebnrrKb4KxN9HE8XqeTlIpW5juNEehMe0dTk pDnTeBcwb3IAUSpSvQu0MaU8tw1U+dkiHFB6XB30FPjBxAsZw030Dkq/G9iY ZSZX4RzRO97K03AW+PgI8gBjV1Bb2uHMZ5Nvot2F3SEMRCO9W4sUj0rM7R6z pJ5xTFn96KHe3OodOkZFnv5SsLqr3KOCpz/prRuMfjCPCWKGBMtSHGdsdIjQ 0mz7yt1wI4Ybs0Ou9LUEek/cbLNbYPTblO3CHhxKJns0hiFabdu33k19esDt u+tT80xgCzcm7lFX/T7gg+masZA6KYFwkKqHdOAccA94BungBCv8raRvuFRP Uj7gzv4Myv5RpdrpKctevqeN6+AVxHXGl0uwjzJ2x7LefD5taLv/gdD+wCmb I+whuJfDn/4RIEqr5p4/guIEuQQRB41D/dv6LLU71WNniRLBV63HtQqxLPG9 i9QPJ+gCI/1tmWnfIQAsD/QXlugbapIKyJpSZ6vpXEQfrz5dzp81CEH/HD52 GLWOFb/TX9/hbOhsAv2sxXF2oMd90GMNXaqz70gyCrGAzr5jeHO+gzntw5xq zNLXfQcUMbW7e3Fnfbizb8ON+3Djb8Olfbi0xjUR1otLDC5Nh+Yj2IF3+6LC NVFRxu2+Q8ax/vqDsyHOEJzfgfX6YD0NC4nQc6z52ngNQuwg+n2IvkYEBdpZ 1zqq8AVHHSOBZaGFe/k51/WWrtKqKrV61bLG+ioFBRnUbTALVuguFarAmdZT 6OcITp0CNKFJ4IWe9ac1Zeh9k2bWj5DHc930rA+fPmvvkGNBRpa/QPL5l0U9 +PJnffInnOaKwYJ+QtbH7//65x+uzXjX8SD3QYo5qu3BmMWbeT2ZaRPTPwmT 2NOJy2jdxsSxmEyhFXo+c4wuoEC3Ha/n2xCGtlyX/YkzDSxqiLih6Wh+yuqn 9QkKNK2JkA85QWfrFCgE03A81K9fyC2Iyd6XWI5zbl3rc3P9PsSdEUa2HJqY MbYuREfjEBg7U9+Pt2eaq5lVLbDGC1x3ol/BhFPHZ49gvC3h5owe5UN5uwWu 8RrbRvPtj6aLesFsNiVNNKAQPkI/dLYrYX3AWVbW+nP0ZVHThhWnPGKbVKEv ZdD9jJwNBT7GxrDVNilr9wdJ1W+olhha3qh8d9my9ONJaVqKAaaErx9Eqjp4 kymrAbUKTwHWnrnUD2alISZEmb2tXvyWqTcdV8aETEKNmqW53gre787f0J0w GoId02/zIgIZ3+ES1nO/Kff/qJw3nSWBC4YREMyligrKMtg2tyzd8ZvIv5/w 7BPH1bcTsF4pIaKUE5V1NAqDRsRxUAkN8+MspREUDPum/4raAETYU0Bwta/E dp0Eg+VIcIoV7sSe7+PfSfS9CfxqBH61l4HEwWbFdO1bsEimyxx3WPje4abP lfgQRDKrIuuxldee2NWLVtpEgqlC5J3ggiVpnmLomh1sMD2fI73v0KHDzONZ yVg+RLRYrbXhvf7HMhOmqUT4DqeZ3kdY1uUlFPjvtpXiImI5HbjJjFEywbbn +MkMB+El1JeL9/qwTGH4blsNL6roGlDH9sbhZcugrIAXEDKDILHHTruvLH0X ndUdQIzYAWvbVZXxoo6VAQSIHSSh28EyBfEOlrODVGaisWon4gCyz/bCoG1p 0hAt2lkIcP6kS04HCFps42Pgh3bQnfFNoP8lgcqqDlKkU9QNXJAneNPxdQea eQKw2N7kBnBnsyfTHZGghjBube/8MFtInqukqR12AUKvi1DWDWghFduoSP+P 2sAnCbaDSUxeeRS9qfhfVPFVJayucsCqU+QMfM/G5Aiz54j4XCQoqYz3lQWU UbvrauopCJR2OTVwAxuqXsuyvDG6L2spaf5NPSgLPgllkiwYHSH0NybN6469 r71/AwxPCXsgMQAA ---1463806619-937713930-1032364264=:22051-- From owner-linux-xfs@oss.sgi.com Wed Sep 18 10:53:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 10:53:39 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IHrWtG010157 for ; Wed, 18 Sep 2002 10:53:32 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1988E1D94C3; Wed, 18 Sep 2002 10:58:36 -0700 (PDT) Date: Wed, 18 Sep 2002 10:58:36 -0700 From: Chris Wedgwood To: jose Hernandez Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.17 + XFS Message-ID: <20020918175836.GA19707@tapu.f00f.org> References: <3D886F99.EF7A6BC8@sgo.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D886F99.EF7A6BC8@sgo.es> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Sep 18, 2002 at 12:20:41PM +0000, jose Hernandez wrote: > On the other hand , I have download from CVS the 2.4.19 version, but > I have error compiling the kernel. From CVS *when* and what is your error? Please also show your .config. If it would help people, I am happy to put up a 2.4.19-xfs tree (from CVS) and possible also 2.4.20-pre* kernels to as time permits so people can't just garb the tarball's and build from that. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 18 11:19:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 11:19:43 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IIJZtG010838 for ; Wed, 18 Sep 2002 11:19:36 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8IIOdq10809 for ; Wed, 18 Sep 2002 14:24:39 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8IIOde10800; Wed, 18 Sep 2002 14:24:39 -0400 Date: Wed, 18 Sep 2002 14:24:38 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: Subject: Re: Kernel HANG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Team: We found some conflicts between snare (auditmodule.o) and current 2.4.9-31SGI_XFS. We enabled snare and 1.5 hour later, machine was down. I will send information to snare developers. Thanks for your help. Vene.- On Wed, 18 Sep 2002, Benito Venegas wrote: > Kernel Debug is attached to this email. > Thanks for your help Seth and xfs list members. > > Vene.- > > On Wed, 18 Sep 2002, Seth Mos wrote: > > > On Tue, 17 Sep 2002, Benito Venegas wrote: > > > > Run it through ksymoops please. > > > > > > > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > > > <1>Unable to handle kernel paging request at virtual address 04a20000 > > > printing eip: > > > dfdf4282 > > > *pde = 00000000 > > > Oops: 0002 > > > Kernel 2.4.9-31SGI_XFS_1.1 > > > CPU: 0 > > > EIP: 0010:[] Tainted: P > > > EFLAGS: 00010286 > > > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > > > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > > > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > > > ds: 0018 es: 0018 ss: 0018 > > > Process rsync (pid: 4785, stackpage=d823f000) > > > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > > > 00000000 > > > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > > > 0000000b > > > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > > > df68fb24 > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Sep 18 11:26:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 11:26:30 -0700 (PDT) Received: from mta3.sucs.soton.ac.uk (mta3.sucs.soton.ac.uk [152.78.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IIQRtG011339 for ; Wed, 18 Sep 2002 11:26:28 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta3.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IIVN6C002093; Wed, 18 Sep 2002 19:31:24 +0100 Reply-To: From: "Ian D. Hardy" To: "'Stephen Lord'" Cc: , , , Subject: RE: Re-occurance of NFS server panics Date: Wed, 18 Sep 2002 19:31:23 +0100 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, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <1032196576.9808.149.camel@laptop.americas.sgi.com> X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.1, required 5, IN_REP_TO, WEIRD_PORT) X-archive-position: 472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve, >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: >> Steve, >> >> Thanks for the quick response. I don't always get a Oops output >> (sometimes the server just hangs and requires a reboot). However as it >> happens the server has just crashed again with the following Oops >> (through 'ksymoops'): > >This one suggests heap corruption more than anything else. > >Steve I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday 16th Sept.) today and got a very similar looking Ooops to the one I reported on Monday, see below. I guess it is very difficult to know what would have caused any heap corruption. As I understand it there's nothing in these latest panics to directly link them with XFS? I need to do some more thinking on this. Any pointers would be very welcome. Regards Ian Hardy kernel BUG at slab.c:1439! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010016 eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7edd000) Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 00000000 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 c036fa08 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 00000002 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid operand due to oops @ 0xc0133a64 eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 xds = 0xe51e0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf7eddf14 [0]kdb> kernel BUG at slab.c:1439! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010016 eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7edd000) Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 00000000 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 c036fa08 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 00000002 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 >>EIP; c0133a64 <===== Trace; c0134e58 Trace; c0134f0c Trace; c0134fb0 Trace; c0135026 Trace; c013515c Trace; c0105000 <_stext+0/0> Trace; c0107296 Trace; c01350c0 Code; c0133a64 00000000 <_EIP>: Code; c0133a64 <===== 0: 0f 0b ud2a <===== Code; c0133a66 2: 9f lahf Code; c0133a66 3: 05 a0 54 2b c0 add $0xc02b54a0,%eax Code; c0133a6c 8: 8b 44 24 24 mov 0x24(%esp,1),%eax Code; c0133a70 c: 89 ea mov %ebp,%edx Code; c0133a72 e: 8b 48 18 mov 0x18(%eax),%ecx Code; c0133a74 11: b8 71 f0 00 00 mov $0xf071,%eax Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid operand eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 From owner-linux-xfs@oss.sgi.com Wed Sep 18 11:38:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 11:38:57 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IIcptG011875 for ; Wed, 18 Sep 2002 11:38:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA68208; Wed, 18 Sep 2002 13:43:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA85618; Wed, 18 Sep 2002 13:43:49 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8IIe9l30357; Wed, 18 Sep 2002 13:40:09 -0500 Subject: RE: Re-occurance of NFS server panics From: Steve Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk, Russell Cattelan In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Sep 2002 13:40:09 -0500 Message-Id: <1032374409.30048.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > Steve, > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > >> Steve, > >> > >> Thanks for the quick response. I don't always get a Oops output > >> (sometimes the server just hangs and requires a reboot). However as > it > >> happens the server has just crashed again with the following Oops > >> (through 'ksymoops'): > > > >This one suggests heap corruption more than anything else. > > > >Steve > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday > 16th Sept.) today and got a very similar looking Ooops to the one I > reported on Monday, see below. I guess it is very difficult to know what > would have caused any heap corruption. As I understand it there's > nothing in these latest panics to directly link them with XFS? I need to > do some more thinking on this. Any pointers would be very welcome. > > Regards Ian Hardy > > > kernel BUG at slab.c:1439! OK, so you have slab debugging turned on, which I was going to ask you to do. Looks like someone walked off the end of an allocation here, that is progress. So, the question is what did it, thats the really hard part! Is this machine just running XFS via NFS, or is it doing anything else? Also, which options do you have turned on in XFS, in fact, sending the whole kernel config might be an idea. Steve > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010016 > eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 > esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=f7edd000) > Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 > 00000000 > 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 > c036fa08 > 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 > 00000002 > Call Trace: [] [] [] [] > [] > [] [] [] > > Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 > > Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid > operand > due to oops @ 0xc0133a64 > eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 > esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 > ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 > xds = 0xe51e0018 xes = 0x00000018 origeax = 0xffffffff ®s = > 0xf7eddf14 > [0]kdb> > kernel BUG at slab.c:1439! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010016 > eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 > esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=f7edd000) > Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 > 00000000 > 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 > c036fa08 > 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 > 00000002 > Call Trace: [] [] [] [] > [] > [] [] [] > Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 > > >>EIP; c0133a64 <===== > Trace; c0134e58 > Trace; c0134f0c > Trace; c0134fb0 > Trace; c0135026 > Trace; c013515c > Trace; c0105000 <_stext+0/0> > Trace; c0107296 > Trace; c01350c0 > Code; c0133a64 > 00000000 <_EIP>: > Code; c0133a64 <===== > 0: 0f 0b ud2a <===== > Code; c0133a66 > 2: 9f lahf > Code; c0133a66 > 3: 05 a0 54 2b c0 add $0xc02b54a0,%eax > Code; c0133a6c > 8: 8b 44 24 24 mov 0x24(%esp,1),%eax > Code; c0133a70 > c: 89 ea mov %ebp,%edx > Code; c0133a72 > e: 8b 48 18 mov 0x18(%eax),%ecx > Code; c0133a74 > 11: b8 71 f0 00 00 mov $0xf071,%eax > > Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid > operand > eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 > esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 > ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 18 13:44:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 13:44:28 -0700 (PDT) Received: from mta1.sucs.soton.ac.uk (mta1.sucs.soton.ac.uk [152.78.128.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IKiJtG014004 for ; Wed, 18 Sep 2002 13:44:20 -0700 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by mta1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IKnFD9005346; Wed, 18 Sep 2002 21:49:15 +0100 Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id VAA11727544; Wed, 18 Sep 2002 21:49:11 +0100 (BST) From: Message-Id: <200209182049.VAA11727544@plum.sucs.soton.ac.uk> Subject: Re: Re-occurance of NFS server panics To: lord@sgi.com (Steve Lord) Date: Wed, 18 Sep 2002 21:49:11 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk, cattelan@thebarn.com (Russell Cattelan) In-Reply-To: <1032374409.30048.8.camel@jen.americas.sgi.com> from "Steve Lord" at Sep 18, 2002 01:40:09 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=3.8, required 5, IN_REP_TO, NO_REAL_NAME, DOUBLE_CAPSWORD, PORN_10, PORN_11, SIGNATURE_DELIM, UPPERCASE_50_75, WEIRD_PORT) X-archive-position: 474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve +, > > On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > > Steve, > > > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > > >> Steve, > > >> > > >> Thanks for the quick response. I don't always get a Oops output > > >> (sometimes the server just hangs and requires a reboot). However as > > it > > >> happens the server has just crashed again with the following Oops > > >> (through 'ksymoops'): > > > > > >This one suggests heap corruption more than anything else. > > > > > >Steve > > > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday > > 16th Sept.) today and got a very similar looking Ooops to the one I > > reported on Monday, see below. I guess it is very difficult to know what > > would have caused any heap corruption. As I understand it there's > > nothing in these latest panics to directly link them with XFS? I need to > > do some more thinking on this. Any pointers would be very welcome. > > > > Regards Ian Hardy > > > > > > kernel BUG at slab.c:1439! > > > OK, so you have slab debugging turned on, which I was going to ask > you to do. Looks like someone walked off the end of an allocation > here, that is progress. > > So, the question is what did it, thats the really hard part! Is > this machine just running XFS via NFS, or is it doing anything > else? Also, which options do you have turned on in XFS, in fact, > sending the whole kernel config might be an idea. > > Steve > Thanks for your continued help/interest, it is much appreciated. The server (dual 1Ghz PIII, with 1Gbyte memory) is a dedicated NFS fileserver (no users have direct access to it). It is serving ~260 NFS clients (part of a computational/Beowulf system). The server has a 40Gbyte IDE system disk and 2 FC-IDE connected RAID units (each with ~500Gbytes usable storage - RAID 5 configuration). The RAID units are connected via a Qlogic QLA2200 HBA and a FC switch. The 2 RAID units are stripped together(RAID 0) using the kernel 'md' RAID driver. Below is the kernel configuration file: # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=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_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_MULTIQUAD is not set 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 is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # CONFIG_HOTPLUG_PCI is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set CONFIG_PARPORT_OTHER=y # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m # CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_LVM=m # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set # CONFIG_IP_NF_IPTABLES is not set # CONFIG_IP_NF_ARPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CMD680 is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_PIIX_TUNING is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_PDC202XX_FORCE is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y CONFIG_IDEDMA_IVB=y # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_DEBUG_QUEUES is not set CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set CONFIG_SCSI_MEGARAID=m # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set # CONFIG_SCSI_SYM53C8XX is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set CONFIG_SCSI_QLOGIC_FC=m # CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_DEBUG is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # CONFIG_I2O=m CONFIG_I2O_PCI=m CONFIG_I2O_BLOCK=m CONFIG_I2O_LAN=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set CONFIG_TULIP=m # CONFIG_TC35815 is not set # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set CONFIG_DE4X5=m # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=m # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_NEW_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set CONFIG_HAMACHI=m # CONFIG_YELLOWFIN is not set CONFIG_SK98LIN=m # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_PHILIPSPAR=m CONFIG_I2C_ELV=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ELEKTOR=m CONFIG_I2C_CHARDEV=m CONFIG_I2C_PROC=m # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=m CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_PCWATCHDOG is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_60XX_WDT is not set # CONFIG_SC1200_WDT is not set CONFIG_SOFT_WATCHDOG=m # CONFIG_W83877F_WDT is not set # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_MACHZ_WDT is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_FS_POSIX_ACL is not set CONFIG_QUOTA=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QIFACE_COMPAT=y CONFIG_QIFACE_V1=y # CONFIG_QIFACE_V2 is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=m CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_UMSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=m CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set # # Network File Systems # CONFIG_CODA_FS=m # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set CONFIG_ZLIB_FS_INFLATE=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_SLAB=y # CONFIG_DEBUG_IOVIRT is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_FRAME_POINTER is not set CONFIG_KDB=y # CONFIG_KDB_MODULES is not set # CONFIG_KDB_OFF is not set # # Load all symbols for debugging is required for KDB # CONFIG_KALLSYMS=y -- Regards and thanks Ian -- Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Information Systems Services email: i.d.hardy@soton.ac.uk Southampton University Southampton S017 1BJ, UK. From owner-linux-xfs@oss.sgi.com Wed Sep 18 14:08:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 14:08:08 -0700 (PDT) Received: from mta1.sucs.soton.ac.uk (mta1.sucs.soton.ac.uk [152.78.128.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IL85tG015399 for ; Wed, 18 Sep 2002 14:08:06 -0700 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by mta1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8ILD6D9007711 for ; Wed, 18 Sep 2002 22:13:06 +0100 Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA12649842 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 22:13:06 +0100 (BST) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by mailspool1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IL6M1b023152; Wed, 18 Sep 2002 22:06:22 +0100 From: I.D.Hardy@soton.ac.uk Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IL6Hlj013672; Wed, 18 Sep 2002 22:06:17 +0100 Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA12513678; Wed, 18 Sep 2002 22:06:17 +0100 (BST) Message-Id: <200209182106.WAA12513678@plum.sucs.soton.ac.uk> Subject: Re: Re-occurance of NFS server panics To: knuffie@xs4all.nl (Seth Mos) Date: Wed, 18 Sep 2002 22:06:07 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, O.G.Parchment@soton.ac.uk, linx-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020918223708.03a58ef0@pop.xs4all.nl> from "Seth Mos" at Sep 18, 2002 10:37:45 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean, Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-2.4, required 5, IN_REP_TO, NO_REAL_NAME, SIGNATURE_DELIM) X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-2.4, required 5, IN_REP_TO, NO_REAL_NAME, SIGNATURE_DELIM) X-archive-position: 475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Seth, I fairly certain its the Qlogic driver for the QLA2200 HBA (driver version 4.27b (I've tried but so far failed to get the more recent 5.38.9 driver to work). The only other possibility (well the only other driver not in the base/XFS kernel) is an intel driver for a e1000 PRO Gigabit Ethernet card (version 3.6.8). Regards Ian > > At 19:31 18-9-2002 +0100, you wrote: > >Steve, > > > >I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday > >16th Sept.) today and got a very similar looking Ooops to the one I > >reported on Monday, see below. I guess it is very difficult to know what > >would have caused any heap corruption. As I understand it there's > >nothing in these latest panics to directly link them with XFS? I need to > >do some more thinking on this. Any pointers would be very welcome. > > What driver have you loaded that taints your kernel. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > -- -- Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Computing Services email: idh@soton.ac.uk Southampton University i.d.hardy@soton.ac.uk Southampton S017 1BJ, UK. From owner-linux-xfs@oss.sgi.com Wed Sep 18 14:13:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 14:13:20 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e1f0.dsl.mediaWays.net [213.20.225.240]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ILDHtG015920 for ; Wed, 18 Sep 2002 14:13:18 -0700 Received: from indigo-3.berdmann.de ([192.168.1.15] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17rmDA-0003a4-00 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 23:18:16 +0200 Message-ID: <3D88ED97.5010507@berdmann.de> Date: Wed, 18 Sep 2002 23:18:15 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs > saw this on lwn.net. linus had merged XFS in the 2.5 tree. Wooooooooooooooooooooohhhhhhhhhhhhh!!!!!!!!!! From owner-linux-xfs@oss.sgi.com Wed Sep 18 14:23:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 14:23:58 -0700 (PDT) Received: from darwin.libc.org (ucntcme224.dsl.micron.net [206.207.111.224] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ILNrtG016528 for ; Wed, 18 Sep 2002 14:23:54 -0700 Received: (qmail 9164 invoked from network); 18 Sep 2002 14:11:44 -0000 Received: from ucntcme231.dsl.micron.net (HELO locutus.libc.org) (?TjMbz6QHSHR7A3SDyW9slfZBmYvdILZl?@206.207.111.231) by ucntcme224.dsl.micron.net with SMTP; 18 Sep 2002 14:11:44 -0000 Subject: Re: Linus merges XFS From: Bill Anderson To: "Linux XFS (SGI)" In-Reply-To: <3D88ED97.5010507@berdmann.de> References: <20020917000532.A18289@s2y4n2c.de> <3D88ED97.5010507@berdmann.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Sep 2002 15:28:58 -0600 Message-Id: <1032384538.8292.64.camel@locutus> Mime-Version: 1.0 X-archive-position: 477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@immosys.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-18 at 15:18, Bernhard Erdmann wrote: > > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > Wooooooooooooooooooooohhhhhhhhhhhhh!!!!!!!!!! > Yup, this means I should now be able to have UMLinux and XFS. Oh yeah! -- Bill Anderson Immosys Rebuilding the network of Tomorrow From owner-linux-xfs@oss.sgi.com Wed Sep 18 16:58:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 16:59:02 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8INwutG019171 for ; Wed, 18 Sep 2002 16:58:57 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id OAA30370 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 14:04:00 -1000 Date: Wed, 18 Sep 2002 14:03:59 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020918140359.A30339@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Hello - First, we've been running many raid5+XFS, some over 1TB in size: It's great! Thanks for adding this filesystem to Linux. We'd like to update a couple of our systems which are running vanilla 2.4.16+XFS to 2.4.19 (with XFS August 18th snapshot). We're recovering from a disk failure, so I'm currently mounting the fs read-only to be safe. 2.4.16 does this, and replays the log just fine. 2.4.19, however, oopses with a NULL pointer deref in xlog_do_log_recovery(0xf7d8679c, 0x36c58, 0x0). Also of interest, xfs_logprint (version 2.1.2) lists a bunch of entries in cycle 190, and then eventually prints a garbage entry ... bogus version, bogus cycle, etc. ... The 2.4.16 kernel apparently does not find problem here. xfs_logprint's memory usage blows up and eventually it gets oom-killed. Should I send you just the log? (How do I do that?) Thanks again! Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Wed Sep 18 19:18:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 19:19:01 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J2IttG028222 for ; Wed, 18 Sep 2002 19:18:55 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id QAA30829 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 16:23:59 -1000 Date: Wed, 18 Sep 2002 16:23:59 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020918162359.A30809@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020918140359.A30339@cfht.hawaii.edu>; from lksi@cfht.hawaii.edu on Wed, Sep 18, 2002 at 02:03:59PM -1000 X-archive-position: 479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Hello - As a follow-up to my previous posting: I just tried the current linux-2.4-xfs from CVS, and the same thing happens (mount crashes and I drop into kdb.) Something is strange about the formatting of the backtrace in kdb ... some lines are definitely scrolling off the top of my console before the "more>" prompt appears. This time the function at the top of my screen is "scrup", but I think there are stack levels above which rolled off the screen (is there a screen height setting in kdb?) Anyway, the crash still happens right after "Starting XFS recovery". Please let me know what I should do next... Thanks! - Sidik From owner-linux-xfs@oss.sgi.com Wed Sep 18 19:38:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 19:38:31 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J2cStG004219 for ; Wed, 18 Sep 2002 19:38:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 TAA02545 for ; Wed, 18 Sep 2002 19:43:32 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04228; Thu, 19 Sep 2002 12:42:13 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B73A23000B8; Thu, 19 Sep 2002 12:42:12 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 91BB885; Thu, 19 Sep 2002 12:42:12 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Sidik Isani Cc: linux-xfs@sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) In-reply-to: Your message of "Wed, 18 Sep 2002 16:23:59 -1000." <20020918162359.A30809@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 2002 12:42:07 +1000 Message-ID: <3697.1032403327@kao2.melbourne.sgi.com> X-archive-position: 480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 18 Sep 2002 16:23:59 -1000, Sidik Isani wrote: > As a follow-up to my previous posting: I just tried the current > linux-2.4-xfs from CVS, and the same thing happens (mount crashes > and I drop into kdb.) Something is strange about the formatting > of the backtrace in kdb ... some lines are definitely scrolling > off the top of my console before the "more>" prompt appears. This > time the function at the top of my screen is "scrup", but I think > there are stack levels above which rolled off the screen (is there > a screen height setting in kdb?) set LINES 15 The default LINES is 24 which matches the screen, but only if all lines are <= 80 characters. kdb does not track long lines so it does not detect wraparound. You are much better off using kdb over a serial console and capturing the output on a second machine - no problems with lost lines then. From owner-linux-xfs@oss.sgi.com Wed Sep 18 21:18:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 21:18:38 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J4IWtG008871 for ; Wed, 18 Sep 2002 21:18:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.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 VAA04289 for ; Wed, 18 Sep 2002 21:23:37 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05031; Thu, 19 Sep 2002 14:22:17 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) with ESMTP id g8J4M3Su001371; Thu, 19 Sep 2002 14:22:03 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g8J4M2LC001369; Thu, 19 Sep 2002 14:22:02 +1000 Date: Thu, 19 Sep 2002 14:22:02 +1000 From: Nathan Scott To: Sidik Isani Cc: linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020919042202.GC586@frodo> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918162359.A30809@cfht.hawaii.edu> User-Agent: Mutt/1.4i X-archive-position: 481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Hi, On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > Hello - > > As a follow-up to my previous posting: I just tried the current > linux-2.4-xfs from CVS, and the same thing happens (mount crashes > and I drop into kdb.) Something is strange about the formatting > of the backtrace in kdb ... some lines are definitely scrolling > off the top of my console before the "more>" prompt appears. This > time the function at the top of my screen is "scrup", but I think > there are stack levels above which rolled off the screen (is there > a screen height setting in kdb?) > > Anyway, the crash still happens right after "Starting XFS recovery". > Please let me know what I should do next... > I seem to remember Steve fixing an endian problem in the log code at one point several months ago - this may be what's biting you - perhaps you have a little endian number somewhere in the on disk log and the new kernel is expecting it is as big endian. If so, the right thing to do would be to run recovery using the old kernel - so first mount, then unmount the filesystem. This should complete fine with the old kernel. Then run xfs_repair on the filesystem. This will zero out the log in phase 2, so you can start afresh. Once you've done those things you should be able to mount and use this filesystem with the latest kernel. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 18 23:07:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 23:07:45 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J67etG012744 for ; Wed, 18 Sep 2002 23:07:40 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id UAA31850; Wed, 18 Sep 2002 20:12:42 -1000 Date: Wed, 18 Sep 2002 20:12:41 -1000 From: Sidik Isani To: Nathan Scott Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020918201241.A31826@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> <20020919042202.GC586@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020919042202.GC586@frodo>; from nathans@sgi.com on Thu, Sep 19, 2002 at 02:22:02PM +1000 X-archive-position: 482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs On Thu, Sep 19, 2002 at 02:22:02PM +1000, Nathan Scott wrote: > Hi, > > On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > > > > Anyway, the crash still happens right after "Starting XFS recovery". > > Please let me know what I should do next... > > > > I seem to remember Steve fixing an endian problem in the log code > at one point several months ago - this may be what's biting you - > perhaps you have a little endian number somewhere in the on disk > log and the new kernel is expecting it is as big endian. > > If so, the right thing to do would be to run recovery using the > old kernel - so first mount, then unmount the filesystem. This > should complete fine with the old kernel. Then run xfs_repair > on the filesystem. This will zero out the log in phase 2, so > you can start afresh. Once you've done those things you should > be able to mount and use this filesystem with the latest kernel. Great. That makes perfect sense. I guess it is not reasonable to expect the kernel itself to repair damage from previous bugs. Could it help you to have a copy of my log anyway, to at least make the new kernel detect this corruption in a more elegant way than crashing? I do see checks in there masking bits for valid version numbers and all. I wonder why these are not finding it. Another RAID with totally different data on it does the same thing. Thanks for solving my problem (well ... I'll let you know soon ;-) Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Thu Sep 19 00:23:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 00:23:12 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J7N8tG014713 for ; Thu, 19 Sep 2002 00:23:08 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 AAA01254 for ; Thu, 19 Sep 2002 00:28:12 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA87326 for linux-xfs@oss.sgi.com; Thu, 19 Sep 2002 17:26:54 +1000 (EST) Date: Thu, 19 Sep 2002 17:26:54 +1000 (EST) From: Nathan Scott Message-Id: <200209190726.RAA87326@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA X-archive-position: 483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Further work on a generic benchmarking framework. Date: Thu Sep 19 00:26:17 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127847a cmd/xfstests/tools/auto-qa - 1.36 - send off the benchmark results in the same way we do the other tests. cmd/xfstests/bench - 1.3 - make important arguments mandatory, do a better job of collecting results. cmd/xfstests/run.dbench - 1.3 - fix up cleanup, simplify the results reporting. cmd/xfstests/run.tar - 1.5 - fix up cleanup after running tar. From owner-linux-xfs@oss.sgi.com Thu Sep 19 04:55:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 04:55:05 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JBt0tG018514 for ; Thu, 19 Sep 2002 04:55:00 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA73787; Thu, 19 Sep 2002 07:00:01 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-17.corp.sgi.com [134.15.64.17]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA56101; Thu, 19 Sep 2002 07:00:01 -0500 (CDT) Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) From: Stephen Lord To: Sidik Isani Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020918201241.A31826@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> <20020919042202.GC586@frodo> <20020918201241.A31826@cfht.hawaii.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 06:58:14 -0500 Message-Id: <1032436696.1114.8.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 01:12, Sidik Isani wrote: > On Thu, Sep 19, 2002 at 02:22:02PM +1000, Nathan Scott wrote: > > Hi, > > > > On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > > > > > > Anyway, the crash still happens right after "Starting XFS recovery". > > > Please let me know what I should do next... > > > > > > > I seem to remember Steve fixing an endian problem in the log code > > at one point several months ago - this may be what's biting you - > > perhaps you have a little endian number somewhere in the on disk > > log and the new kernel is expecting it is as big endian. > > > > If so, the right thing to do would be to run recovery using the > > old kernel - so first mount, then unmount the filesystem. This > > should complete fine with the old kernel. Then run xfs_repair > > on the filesystem. This will zero out the log in phase 2, so > > you can start afresh. Once you've done those things you should > > be able to mount and use this filesystem with the latest kernel. > > Great. That makes perfect sense. I guess it is not reasonable > to expect the kernel itself to repair damage from previous bugs. > Could it help you to have a copy of my log anyway, to at least > make the new kernel detect this corruption in a more elegant way > than crashing? I do see checks in there masking bits for valid > version numbers and all. I wonder why these are not finding it. > Another RAID with totally different data on it does the same thing. > Thanks for solving my problem (well ... I'll let you know soon ;-) > > Be seeing you, > > - Sidik > This is what I fixed: revision 1.240 date: 2002/08/29 21:26:29; author: lord; state: Exp; lines: +2 -1 modid: 2.4.x-xfs:slinx:126410a when processing unlinked inodes and dealing with the di_next_unlinked field, endian flip it. However, this code is purely in recovery dealing with what is in the log, not with how the log is layed down. An old kernel would have crashed in the same way on this problem. Basically it would arise on a crash where the log had a lot of unlinked files to remove. There were some earlier fixes, too, but nothing which would make things worse so far as I can see. I presume in your original message you are saying you have the fs and the 2.4.16 kernel will mount it and the 2.4.19 one will not? Is this something you have done more than one? If you are mounting readonly, you must also be specifying norecovery, otherwise the first mount will actually have done a recovery on the fs. Probably too late for this, but if not, can you send a complete backtrace, and the xlog printout you have, you might want to get new commands first, there have been changes in logprint I think, we are at 2.3.3 now. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 19 10:10:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 10:10:44 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [212.34.181.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JHAftG028967 for ; Thu, 19 Sep 2002 10:10:42 -0700 Received: (from hch@localhost) by verein.lst.de (8.11.6/8.11.6) id g8JHFms22694 for linux-xfs@oss.sgi.com; Thu, 19 Sep 2002 19:15:48 +0200 Resent-Message-Id: <200209191715.g8JHFms22694@verein.lst.de> Received: from tolkor.sgi.com ([198.149.18.6]) by verein.lst.de (8.11.6/8.11.6) with ESMTP id g8JHECu22548 for ; Thu, 19 Sep 2002 19:14:13 +0200 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g8JHEVS9015846 for ; Thu, 19 Sep 2002 12:14:31 -0500 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA76579 for ; Thu, 19 Sep 2002 12:14:06 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA48823 for ; Thu, 19 Sep 2002 12:14:05 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K0SnQ10513 for hch@lst.de; Thu, 19 Sep 2002 20:28:49 -0400 Date: Thu, 19 Sep 2002 20:28:49 -0400 From: Christoph Hellwig Message-Id: <200209200028.g8K0SnQ10513@dhcp212.munich.sgi.com> Subject: TAKE - Sanitize some function names Resent-From: hch@lst.de Resent-Date: Thu, 19 Sep 2002 19:15:48 +0200 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: linux-xfs Sanitize some names in xfs_aops.c, especially a less offending name for linvfs_pb_bmap Date: Thu Sep 19 10:11:58 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127872a linux/fs/xfs/linux/xfs_aops.c - 1.5 - Sanitize some names, especially a less offending name for linvfs_pb_bmap From owner-linux-xfs@oss.sgi.com Thu Sep 19 10:11:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 10:11:59 -0700 (PDT) Received: from mta3.sucs.soton.ac.uk (mta3.sucs.soton.ac.uk [152.78.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JHButG029127 for ; Thu, 19 Sep 2002 10:11:56 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta3.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8JHH1NG013232; Thu, 19 Sep 2002 18:17:01 +0100 Reply-To: From: "Ian D. Hardy" To: , "'Steve Lord'" Cc: , , "'Russell Cattelan'" Subject: RE: Re-occurance of NFS server panics Date: Thu, 19 Sep 2002 18:17:01 +0100 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, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200209182049.VAA11727544@plum.sucs.soton.ac.uk> X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-6.5, required 5, IN_REP_TO, OUTLOOK_FWD, DOUBLE_CAPSWORD, SIGNATURE_DELIM, WEIRD_PORT) X-archive-position: 486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve, + I'm not sure if this provides any more info but I've just had another crash on this server, again caught by 'slab.c', this time from an 'nfsd' process: Reading Oops report from the terminal kernel BUG at slab.c:1218! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010002 eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 856, stackpage=f381f000) Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc ebdfe000 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a c1c0e060 f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 000003a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid operand due to oops @ 0xc0132aeb eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 xds = 0xc0250018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf381fe58 [0]kdb> kernel BUG at slab.c:1218! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 856, stackpage=f381f000) Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc ebdfe000 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a c1c0e060 f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 000003a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 >>EIP; c0132aea <===== Trace; c0132e32 Trace; c013360a Trace; c010cef8 Trace; c02558a2 Trace; c02558bc Trace; c0255a36 <__kfree_skb+116/120> Trace; c02557ea Trace; c0255898 Trace; c0255e10 Trace; f89d0488 <[sunrpc]svc_udp_recvfrom+128/380> Trace; f89d1820 <[sunrpc]svc_send+70/1a0> Trace; f89d14d8 <[sunrpc]svc_recv+2c8/470> Trace; f8a252b4 <[nfsd]nfsd+114/350> Trace; c0107296 Trace; f8a251a0 <[nfsd]nfsd+0/350> Code; c0132aea 00000000 <_EIP>: Code; c0132aea <===== 0: 0f 0b ud2a <===== Code; c0132aec 2: c2 04 a0 ret $0xa004 Code; c0132aee 5: 54 push %esp Code; c0132af0 6: 2b c0 sub %eax,%eax Code; c0132af2 8: 89 d8 mov %ebx,%eax Code; c0132af4 a: 0f af c1 imul %ecx,%eax Code; c0132af6 d: 8d 04 30 lea (%eax,%esi,1),%eax Code; c0132afa 10: 39 c5 cmp %eax,%ebp Code; c0132afc 12: 74 08 je 1c <_EIP+0x1c> c0132b06 Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid operand eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 -----Original Message----- From: I.D.Hardy@soton.ac.uk [mailto:I.D.Hardy@soton.ac.uk] Sent: 18 September 2002 21:49 Steve +, > > On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > > Steve, > > > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > > >> Steve, > > >> > > >> Thanks for the quick response. I don't always get a Oops output > > >> (sometimes the server just hangs and requires a reboot). However as > > it > > >> happens the server has just crashed again with the following Oops > > >> (through 'ksymoops'): > > > > > >This one suggests heap corruption more than anything else. > > > > > >Steve > > > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of > > Monday 16th Sept.) today and got a very similar looking Ooops to the > > one I reported on Monday, see below. I guess it is very difficult to > > know what would have caused any heap corruption. As I understand it > > there's nothing in these latest panics to directly link them with > > XFS? I need to do some more thinking on this. Any pointers would be > > very welcome. > > > > Regards Ian Hardy > > > > > > kernel BUG at slab.c:1439! > > > OK, so you have slab debugging turned on, which I was going to ask you > to do. Looks like someone walked off the end of an allocation here, > that is progress. > > So, the question is what did it, thats the really hard part! Is this > machine just running XFS via NFS, or is it doing anything else? Also, > which options do you have turned on in XFS, in fact, sending the whole > kernel config might be an idea. > > Steve > Thanks for your continued help/interest, it is much appreciated. The server (dual 1Ghz PIII, with 1Gbyte memory) is a dedicated NFS fileserver (no users have direct access to it). It is serving ~260 NFS clients (part of a computational/Beowulf system). The server has a 40Gbyte IDE system disk and 2 FC-IDE connected RAID units (each with ~500Gbytes usable storage - RAID 5 configuration). The RAID units are connected via a Qlogic QLA2200 HBA and a FC switch. The 2 RAID units are stripped together(RAID 0) using the kernel 'md' RAID driver. Below is the kernel configuration file: -- Regards and thanks Ian -- Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Information Systems Services email: i.d.hardy@soton.ac.uk Southampton University Southampton S017 1BJ, UK. From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:18:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:18:51 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIImtG031267 for ; Thu, 19 Sep 2002 11:18:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA77528 for ; Thu, 19 Sep 2002 13:23:47 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA57545 for ; Thu, 19 Sep 2002 13:23:45 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K1chX12214 for linux-xfs@oss.sgi.com; Thu, 19 Sep 2002 21:38:43 -0400 Resent-Message-Id: <200209200138.g8K1chX12214@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA98236 for ; Thu, 19 Sep 2002 13:20:52 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K1ZoB12204 for hch@sgi.com; Thu, 19 Sep 2002 21:35:50 -0400 Date: Thu, 19 Sep 2002 21:35:50 -0400 From: Christoph Hellwig Message-Id: <200209200135.g8K1ZoB12204@dhcp212.munich.sgi.com> Subject: TAKE - Simplify xfs_dir_lookup_int Resent-Date: Thu, 19 Sep 2002 21:38:43 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 19 11:19:37 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127879a linux/fs/xfs/xfs_vnodeops.c - 1.564 - Adopt for new xfs_dir_lookup_int prototype linux/fs/xfs/xfs_utils.c - 1.52 - Remove flags argument from xfs_dir_lookup_int. DLF_IGET is always set and now implied. DLF_LOCK_SHARED is replaced by passing in the lock flags directly. linux/fs/xfs/xfs_utils.h - 1.26 linux/fs/xfs/xfs_rename.c - 1.41 - Adopt for new xfs_dir_lookup_int prototype From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:43:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:43:41 -0700 (PDT) Received: from mbi.ufl.edu (mbi-00.mbi.ufl.edu [159.178.51.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIhctG031950 for ; Thu, 19 Sep 2002 11:43:39 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: Status of 2.5.x CVS now Date: Thu, 19 Sep 2002 14:48:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of 2.5.x CVS now Thread-Index: AcJgAJJznz3wm4ZNRFeGtqeXAU50hQAC+ugA From: "Jon K. Akers" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8JIhdtG031951 X-archive-position: 488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jka@ufbi.ufl.edu Precedence: bulk X-list: linux-xfs I was just wondering what is going to happen to the status of the 2.5.x CVS tree now that XFS has been put into the actually 2.5.x tree by Linus. From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:44:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:44:10 -0700 (PDT) Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIi8tG032004 for ; Thu, 19 Sep 2002 11:44:08 -0700 Received: from [192.168.168.25] (gabe-g4.clubphoto.local [192.168.168.25]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id LAA25681 for ; Thu, 19 Sep 2002 11:49:16 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 19 Sep 2002 11:49:43 -0700 Subject: {evil tone} is it safe? From: "Gabe E. Nydick" To: linux-xfs Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-archive-position: 489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gnydick@clubphoto.com Precedence: bulk X-list: linux-xfs So, I was a pilot user of XFS 1.0 and it caused all sorts of problems and corruptions, but I stuck with it until about 2.4.17, which was around when ext3 was ready, give or take some time. I would like to get the performance and scalability back of XFS, so here is the question. Is it finally ready? What are the outstanding bugs that need to be fixed. - Gabe From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:50:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:50:21 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIoFtG000510 for ; Thu, 19 Sep 2002 11:50:15 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA77363; Thu, 19 Sep 2002 13:55:18 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA98754; Thu, 19 Sep 2002 13:55:17 -0500 (CDT) Subject: Re: Status of 2.5.x CVS now From: Eric Sandeen To: "Jon K. Akers" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Sep 2002 13:49:59 -0500 Message-Id: <1032461399.2159.79.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Jon - A few things to note... DMAPI and ACLS are not in 2.5, so if you need those, you'll still need CVS. I think I'll keep pushing weekly snapshot patches against 2.5, to make it easy to get those things. CVS is really just our internal source control system exported to the outside, and of course development will continue, so we'll probably keep pushing CVS. In short, you can get most of XFS in 2.5 from Linus now, but we'll keep the CVS archive available as well. -Eric On Thu, 2002-09-19 at 13:48, Jon K. Akers wrote: > I was just wondering what is going to happen to the status of the 2.5.x > CVS tree now that XFS has been put into the actually 2.5.x tree by > Linus. > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:51:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:51:43 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIpetG000689 for ; Thu, 19 Sep 2002 11:51:41 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 46A661DA51C; Thu, 19 Sep 2002 11:56:49 -0700 (PDT) Date: Thu, 19 Sep 2002 11:56:49 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: [PATCH] 2.4.19-xfs EFSCORRUPTED redefine to EIO Message-ID: <20020919185649.GA32227@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs For corrupted filesystem right now, XFS can return EFSCORRUPTED (presently set to 990) to userspace. This is pointless as (almost) no user-space code knows that this mean, it's inherently not portable, and rather ugly not to mention completely unmanageable if every filesystem and/or driver decides to invent their own error codes. I suggest this trivial patch (2.4.x tree) to redefine it as EIO. Obviously, a similar fix should also go into 2.5.x. --cw diff -u -u -r1.84 xfs_linux.h --- fs/xfs/linux/xfs_linux.h 2002/09/05 05:37:11 1.84 +++ fs/xfs/linux/xfs_linux.h 2002/09/19 18:42:21 @@ -133,17 +133,11 @@ #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ /* - * XXX EFSCORRUPTED needs a real value in errno.h. asm-i386/errno.h won't - * return codes out of its known range in errno. - * XXX Also note: needs to be < 1000 and fairly unique on Linux (mustn't - * conflict with any code we use already or any code a driver may use) - * XXX Some options (currently we do #2): - * 1/ New error code ["Filesystem is corrupted", _after_ glibc updated] - * 2/ 990 ["Unknown error 990"] - * 3/ EUCLEAN ["Structure needs cleaning"] - * 4/ Convert EFSCORRUPTED to EIO [just prior to return into userspace] + * EFSCORRUPTED previously returned 990 which is a rather meaningless + * error code. Rather than invent new error codes every picosecond or + * so, lets just pick something appropriate and stick with it. */ -#define EFSCORRUPTED 990 /* Filesystem is corrupted */ +#define EFSCORRUPTED EIO /* Filesystem is corrupted */ #define SYNCHRONIZE() barrier() #define lbolt jiffies From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:00:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:01:00 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJ0wtG001509 for ; Thu, 19 Sep 2002 12:00:58 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA76386; Thu, 19 Sep 2002 14:06:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA00703; Thu, 19 Sep 2002 14:06:00 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8JJ2Ad32738; Thu, 19 Sep 2002 14:02:10 -0500 Subject: Re: [PATCH] 2.4.19-xfs EFSCORRUPTED redefine to EIO From: Steve Lord To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020919185649.GA32227@tapu.f00f.org> References: <20020919185649.GA32227@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 14:02:10 -0500 Message-Id: <1032462130.29705.339.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 13:56, Chris Wedgwood wrote: > For corrupted filesystem right now, XFS can return EFSCORRUPTED > (presently set to 990) to userspace. > > This is pointless as (almost) no user-space code knows that this mean, > it's inherently not portable, and rather ugly not to mention > completely unmanageable if every filesystem and/or driver decides to > invent their own error codes. > > I suggest this trivial patch (2.4.x tree) to redefine it as EIO. > Obviously, a similar fix should also go into 2.5.x. Except that the filesystem internally needs to be able to tell the difference between the two. There are actions taken upon EFSCORRUPTED which we may not want to take on EIO. Having said that in most cases where we get EIO from underneath we would probably map it to EFSCORRUPTED anyway. So, I think this would need some major auditing before putting it in, we reference EFSCORRUPTED in about 100 places. Steve > > > --cw > > > > > > diff -u -u -r1.84 xfs_linux.h > --- fs/xfs/linux/xfs_linux.h 2002/09/05 05:37:11 1.84 > +++ fs/xfs/linux/xfs_linux.h 2002/09/19 18:42:21 > @@ -133,17 +133,11 @@ > #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ > > /* > - * XXX EFSCORRUPTED needs a real value in errno.h. asm-i386/errno.h won't > - * return codes out of its known range in errno. > - * XXX Also note: needs to be < 1000 and fairly unique on Linux (mustn't > - * conflict with any code we use already or any code a driver may use) > - * XXX Some options (currently we do #2): > - * 1/ New error code ["Filesystem is corrupted", _after_ glibc updated] > - * 2/ 990 ["Unknown error 990"] > - * 3/ EUCLEAN ["Structure needs cleaning"] > - * 4/ Convert EFSCORRUPTED to EIO [just prior to return into userspace] > + * EFSCORRUPTED previously returned 990 which is a rather meaningless > + * error code. Rather than invent new error codes every picosecond or > + * so, lets just pick something appropriate and stick with it. > */ > -#define EFSCORRUPTED 990 /* Filesystem is corrupted */ > +#define EFSCORRUPTED EIO /* Filesystem is corrupted */ > > #define SYNCHRONIZE() barrier() > #define lbolt jiffies > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:13:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:13:06 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJD2tG002153 for ; Thu, 19 Sep 2002 12:13:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA76309; Thu, 19 Sep 2002 14:18:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA80097; Thu, 19 Sep 2002 14:18:05 -0500 (CDT) Subject: Re: Status of 2.5.x CVS now From: Eric Sandeen To: Jens Axboe Cc: "Jon K. Akers" , linux-xfs@oss.sgi.com In-Reply-To: <20020919191454.GF936@suse.de> References: <1032461399.2159.79.camel@stout.americas.sgi.com> <20020919191454.GF936@suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Sep 2002 14:12:46 -0500 Message-Id: <1032462766.1541.81.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Yep :) On Thu, 2002-09-19 at 14:14, Jens Axboe wrote: > And pulling I hope, at least you'll need to pull the bio_add_page() > changes from bk-current into cvs to have a working xfs. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:20:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:21:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJKstG002963 for ; Thu, 19 Sep 2002 12:20:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA75715; Thu, 19 Sep 2002 14:25:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA57775; Thu, 19 Sep 2002 14:25:54 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8JJM5c00464; Thu, 19 Sep 2002 14:22:05 -0500 Subject: RE: Re-occurance of NFS server panics From: Steve Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk, "'Russell Cattelan'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 14:22:05 -0500 Message-Id: <1032463325.29705.398.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 12:17, Ian D. Hardy wrote: > Steve, + > > I'm not sure if this provides any more info but I've just had another > crash on this server, again caught by 'slab.c', this time from an 'nfsd' > process: Well, either someone trampled on some memory allocation headers they should not have and confused the code in a precise direction, or, the pointer passed into the free was a little out of the range it should have been. I do not suppose there is anyway you can remove the binary only modules from your kernel. From the sound of it they are pretty fundamental to your setup - the disk driver and the network driver. If the free really is a bogus address of some form, then it is a network packet, and we definitely do not do those. Also, the fact that this corruption seems specific to your setup says investigating those drivers some more might be beneficial. Steve > > Reading Oops report from the terminal > kernel BUG at slab.c:1218! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010002 > eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 > esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 856, stackpage=f381f000) > Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc > ebdfe000 > 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a > c1c0e060 > f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 > 000003a0 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] > > Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 > > Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid > operand > due to oops @ 0xc0132aeb > eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 > esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb > ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 > xds = 0xc0250018 xes = 0x00000018 origeax = 0xffffffff ®s = > 0xf381fe58 > [0]kdb> > kernel BUG at slab.c:1218! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010002 > eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 > esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 856, stackpage=f381f000) > Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc > ebdfe000 > 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a > c1c0e060 > f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 > 000003a0 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] > Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 > > >>EIP; c0132aea <===== > Trace; c0132e32 > Trace; c013360a > Trace; c010cef8 > Trace; c02558a2 > Trace; c02558bc > Trace; c0255a36 <__kfree_skb+116/120> > Trace; c02557ea > Trace; c0255898 > Trace; c0255e10 > Trace; f89d0488 <[sunrpc]svc_udp_recvfrom+128/380> > Trace; f89d1820 <[sunrpc]svc_send+70/1a0> > Trace; f89d14d8 <[sunrpc]svc_recv+2c8/470> > Trace; f8a252b4 <[nfsd]nfsd+114/350> > Trace; c0107296 > Trace; f8a251a0 <[nfsd]nfsd+0/350> > Code; c0132aea > 00000000 <_EIP>: > Code; c0132aea <===== > 0: 0f 0b ud2a <===== > Code; c0132aec > 2: c2 04 a0 ret $0xa004 > Code; c0132aee > 5: 54 push %esp > Code; c0132af0 > 6: 2b c0 sub %eax,%eax > Code; c0132af2 > 8: 89 d8 mov %ebx,%eax > Code; c0132af4 > a: 0f af c1 imul %ecx,%eax > Code; c0132af6 > d: 8d 04 30 lea (%eax,%esi,1),%eax > Code; c0132afa > 10: 39 c5 cmp %eax,%ebp > Code; c0132afc > 12: 74 08 je 1c <_EIP+0x1c> c0132b06 > > > Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid > operand > eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 > esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb > ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 > > > -----Original Message----- > From: I.D.Hardy@soton.ac.uk [mailto:I.D.Hardy@soton.ac.uk] > Sent: 18 September 2002 21:49 > > Steve +, > > > > > On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > > > Steve, > > > > > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > > > >> Steve, > > > >> > > > >> Thanks for the quick response. I don't always get a Oops output > > > >> (sometimes the server just hangs and requires a reboot). However > as > > > it > > > >> happens the server has just crashed again with the following Oops > > > >> (through 'ksymoops'): > > > > > > > >This one suggests heap corruption more than anything else. > > > > > > > >Steve > > > > > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of > > > Monday 16th Sept.) today and got a very similar looking Ooops to the > > > > one I reported on Monday, see below. I guess it is very difficult to > > > > know what would have caused any heap corruption. As I understand it > > > there's nothing in these latest panics to directly link them with > > > XFS? I need to do some more thinking on this. Any pointers would be > > > very welcome. > > > > > > Regards Ian Hardy > > > > > > > > > kernel BUG at slab.c:1439! > > > > > > OK, so you have slab debugging turned on, which I was going to ask you > > > to do. Looks like someone walked off the end of an allocation here, > > that is progress. > > > > So, the question is what did it, thats the really hard part! Is this > > machine just running XFS via NFS, or is it doing anything else? Also, > > which options do you have turned on in XFS, in fact, sending the whole > > > kernel config might be an idea. > > > > Steve > > > > Thanks for your continued help/interest, it is much appreciated. > > The server (dual 1Ghz PIII, with 1Gbyte memory) is a dedicated NFS > fileserver (no users have direct access to it). It is serving ~260 NFS > clients (part of a computational/Beowulf system). The server has a > 40Gbyte IDE system disk and 2 FC-IDE connected RAID units (each with > ~500Gbytes usable storage - RAID 5 configuration). The RAID units are > connected via a Qlogic QLA2200 HBA and a FC switch. The 2 RAID units are > stripped together(RAID 0) using the kernel 'md' RAID driver. > > Below is the kernel configuration file: > > > -- > > Regards and thanks > > Ian > > -- > Ian Hardy Tel: 023 80593577 > Research Services Fax: 023 80593131 > Information Systems Services email: i.d.hardy@soton.ac.uk > > Southampton University > Southampton S017 1BJ, UK. > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:22:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:22:30 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJMStG003155 for ; Thu, 19 Sep 2002 12:22:28 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.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 MAA03857 for ; Thu, 19 Sep 2002 12:24:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA77941; Thu, 19 Sep 2002 14:23:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA47511; Thu, 19 Sep 2002 14:23:16 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8JJJRR00455; Thu, 19 Sep 2002 14:19:27 -0500 Subject: Re: Status of 2.5.x CVS now From: Steve Lord To: Eric Sandeen Cc: Jens Axboe , "Jon K. Akers" , linux-xfs@oss.sgi.com In-Reply-To: <1032462766.1541.81.camel@stout.americas.sgi.com> References: <1032461399.2159.79.camel@stout.americas.sgi.com> <20020919191454.GF936@suse.de> <1032462766.1541.81.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 14:19:26 -0500 Message-Id: <1032463166.8022.387.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 14:12, Eric Sandeen wrote: > Yep :) > > On Thu, 2002-09-19 at 14:14, Jens Axboe wrote: > > And pulling I hope, at least you'll need to pull the bio_add_page() > > changes from bk-current into cvs to have a working xfs. I have a built 2.5.36 tree here, but other work is keeping me from testing it. I have conference calls until 7:30 this evening, unless I can find a victim, it may take a while. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:10:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:10:33 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKATtG005483 for ; Thu, 19 Sep 2002 13:10:30 -0700 Received: from brick.kernel.dk ([195.249.94.204] helo=burns.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.35 #1) id 17s6lk-0002qB-00; Thu, 19 Sep 2002 21:15:20 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 4.10) id 17s6lK-0008U7-00; Thu, 19 Sep 2002 21:14:54 +0200 Date: Thu, 19 Sep 2002 21:14:54 +0200 From: Jens Axboe To: Eric Sandeen Cc: "Jon K. Akers" , linux-xfs@oss.sgi.com Subject: Re: Status of 2.5.x CVS now Message-ID: <20020919191454.GF936@suse.de> References: <1032461399.2159.79.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032461399.2159.79.camel@stout.americas.sgi.com> X-archive-position: 496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 19 2002, Eric Sandeen wrote: > Hi Jon - > > A few things to note... > > DMAPI and ACLS are not in 2.5, so if you need those, you'll still need > CVS. I think I'll keep pushing weekly snapshot patches against 2.5, to > make it easy to get those things. > > CVS is really just our internal source control system exported to the > outside, and of course development will continue, so we'll probably keep > pushing CVS. > > In short, you can get most of XFS in 2.5 from Linus now, but we'll keep > the CVS archive available as well. And pulling I hope, at least you'll need to pull the bio_add_page() changes from bk-current into cvs to have a working xfs. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:25:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:25:40 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKPbtG006564 for ; Thu, 19 Sep 2002 13:25:38 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id AFC0D1DA55F; Thu, 19 Sep 2002 13:30:46 -0700 (PDT) Date: Thu, 19 Sep 2002 13:30:46 -0700 From: Chris Wedgwood To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: [PATCH] (take #2) 2.4.19-xfs -EFSCORRUPTED expose as -EIO Message-ID: <20020919203046.GA357@tapu.f00f.org> References: <20020919185649.GA32227@tapu.f00f.org> <1032462130.29705.339.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032462130.29705.339.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Sep 19, 2002 at 02:02:10PM -0500, Steve Lord wrote: So, I think this would need some major auditing before putting it in, we reference EFSCORRUPTED in about 100 places. Yes, I was just talking to hch and sandeen about this. Attached is another *suggestion* (ie. it needs to be verified carefully and a couple of minor changes). --cw -- -- snip snip -- ouch ouch -- -- xfs_aops.c | 18 ++++++++--------- xfs_iops.c | 63 ++++++++++++++++++++++++++++++------------------------------ xfs_linux.h | 22 ++++++++++++-------- xfs_super.c | 4 +-- 4 files changed, 56 insertions(+), 51 deletions(-) Index: linux/xfs_aops.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_aops.c,v retrieving revision 1.5 diff -u -w -b -B -r1.5 xfs_aops.c --- linux/xfs_aops.c 2002/09/19 17:11:58 1.5 +++ linux/xfs_aops.c 2002/09/19 20:21:07 @@ -150,16 +150,14 @@ /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); - if ((page->index >= end_index+1) || !offset) { - ret = -EIO; - goto out; + if ((page->index >= end_index+1) || !offset) + goto out_flush; } - } ret = delalloc_convert(inode, page, 0, 0); -out: if (ret < 0) { +out_flush: block_flushpage(page, 0); ClearPageUptodate(page); @@ -558,6 +556,8 @@ return err; } +/* maybe be called (indirectly) from Linux so we may have to fix error + codes */ STATIC int linvfs_get_block_core( struct inode *inode, @@ -586,7 +586,7 @@ create ? flags : PBF_READ, NULL, (struct page_buf_bmap_s *)&pbmap, &retpbbm, error); if (error) - return -error; + return linux_err_code(-error); if (retpbbm == 0) return 0; @@ -690,7 +689,7 @@ struct file *unused, struct page *page) { - return block_read_full_page(page, linvfs_get_block); + return linux_err_code(block_read_full_page(page, linvfs_get_block)); } STATIC int @@ -747,7 +746,7 @@ if (flagset) current->flags &= ~PF_NOIO; - return error; + return linux_err_code(error); out_fail: SetPageDirty(page); @@ -873,7 +872,7 @@ length -= size; } - return (error ? error : (int)(total - length)); + return (error ? linux_err_code(error) : (int)(total - length)); } /* Index: linux/xfs_iops.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c,v retrieving revision 1.174 diff -u -w -b -B -r1.174 xfs_iops.c --- linux/xfs_iops.c 2002/09/11 14:29:13 1.174 +++ linux/xfs_iops.c 2002/09/19 20:21:07 @@ -143,7 +142,7 @@ _ACL_FREE(pdacl); } } - return -error; + return linux_err_code(-error); } STATIC int @@ -152,7 +151,7 @@ struct dentry *dentry, int mode) { - return linvfs_mknod(dir, dentry, mode, 0); + return linux_err_code(linvfs_mknod(dir, dentry, mode, 0)); } STATIC int @@ -161,7 +160,7 @@ struct dentry *dentry, int mode) { - return linvfs_mknod(dir, dentry, mode|S_IFDIR, 0); + return linux_err_code(linvfs_mknod(dir, dentry, mode|S_IFDIR, 0)); } @@ -189,6 +188,7 @@ } error = -linvfs_revalidate_core(ip, ATTR_COMM); } + /* XXX linux_err_code required here? */ if (error && (error != ENOENT)) return ERR_PTR(-error); d_add(dentry, ip); /* Negative entry goes in if ip is NULL */ @@ -222,7 +222,7 @@ d_instantiate(dentry, ip); mark_inode_dirty_sync(ip); } - return -error; + return linux_err_code(-error); } STATIC int @@ -247,7 +247,7 @@ mark_inode_dirty_sync(dir); } - return -error; + return linux_err_code(-error); } STATIC int @@ -288,7 +288,7 @@ mark_inode_dirty_sync(dir); } } - return -error; + return linux_err_code(-error); } STATIC int @@ -307,7 +307,7 @@ mark_inode_dirty_sync(inode); mark_inode_dirty_sync(dir); } - return -error; + return linux_err_code(-error); } STATIC int @@ -329,7 +329,7 @@ VOP_RENAME(fvp, odentry, tvp, ndentry, NULL, error); if (error) - return -error; + return linux_err_code(-error); if (new_inode) { validate_fields(new_inode); @@ -365,7 +365,7 @@ VOP_READLINK(vp, &uio, NULL, error); if (error) - return -error; + return linux_err_code(-error); return (size - uio.uio_resid); } @@ -414,7 +414,7 @@ if (error) { kfree(uio); kfree(link); - return -error; + return linux_err_code(-error); } link[MAXNAMELEN - uio->uio_resid] = '\0'; @@ -423,7 +423,7 @@ /* vfs_follow_link returns (-) errors */ error = vfs_follow_link(nd, link); kfree(link); - return error; + return linux_err_code(error); } STATIC int @@ -436,7 +436,7 @@ mode <<= 6; /* convert from linux to vnode access bits */ VOP_ACCESS(vp, mode, NULL, error); - return -error; + return linux_err_code(-error); } /* Brute force approach for now - copy data into linux inode @@ -461,7 +461,7 @@ vnode_t *vp = LINVFS_GET_VP(dentry->d_inode); if (unlikely(vp->v_flag & VMODIFIED)) { - return linvfs_revalidate_core(dentry->d_inode, 0); + return linux_err_code(linvfs_revalidate_core(dentry->d_inode, 0)); } return 0; } @@ -518,7 +518,7 @@ VOP_SETATTR(vp, &vattr, flags, NULL, error); if (error) - return(-error); /* Positive error up from XFS */ + return linux_err_code(-error); /* Positive error up from XFS */ if (ia_valid & ATTR_SIZE) { error = vmtruncate(inode, attr->ia_size); } @@ -527,7 +527,7 @@ vn_revalidate(vp, 0); mark_inode_dirty_sync(inode); } - return error; + return linux_err_code(error); } STATIC void @@ -610,14 +610,14 @@ xfs_namespaces[SYSTEM_NAMES].namelen) == 0) { error = -EINVAL; if (flags & XATTR_CREATE) - return error; + return linux_err_code(error); error = -ENOATTR; p += xfs_namespaces[SYSTEM_NAMES].namelen; if (strcmp(p, POSIXACL_ACCESS) == 0) { if (vp->v_flag & VMODIFIED) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); } error = xfs_acl_vset(vp, data, size, _ACL_TYPE_ACCESS); if (!error) { @@ -628,7 +628,7 @@ else if (strcmp(p, POSIXACL_DEFAULT) == 0) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); error = xfs_acl_vset(vp, data, size, _ACL_TYPE_DEFAULT); if (!error) { VMODIFY(vp); @@ -638,7 +638,7 @@ else if (strcmp(p, POSIXCAP) == 0) { error = xfs_cap_vset(vp, data, size); } - return error; + return linux_err_code(error); } /* Convert Linux syscall to XFS internal ATTR flags */ @@ -650,11 +650,11 @@ if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, xfs_namespaces[ROOT_NAMES].namelen) == 0) { if (!capable(CAP_SYS_ADMIN)) - return -EPERM; + return linux_err_code(-EPERM); xflags |= ATTR_ROOT; p += xfs_namespaces[ROOT_NAMES].namelen; VOP_ATTR_SET(vp, p, data, size, xflags, NULL, error); - return -error; + return linux_err_code(-error); } if (strncmp(name, xfs_namespaces[USER_NAMES].name, xfs_namespaces[USER_NAMES].namelen) == 0) { @@ -662,7 +662,7 @@ return -EPERM; p += xfs_namespaces[USER_NAMES].namelen; VOP_ATTR_SET(vp, p, data, size, xflags, NULL, error); - return -error; + return linux_err_code(-error); } return -ENOATTR; } @@ -688,7 +688,7 @@ if (vp->v_flag & VMODIFIED) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); } error = xfs_acl_vget(vp, data, size, _ACL_TYPE_ACCESS); } @@ -696,14 +696,14 @@ if (vp->v_flag & VMODIFIED) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); } error = xfs_acl_vget(vp, data, size, _ACL_TYPE_DEFAULT); } else if (strcmp(p, POSIXCAP) == 0) { error = xfs_cap_vget(vp, data, size); } - return error; + return linux_err_code(error); } /* Convert Linux syscall to XFS internal ATTR flags */ @@ -719,7 +719,7 @@ VOP_ATTR_GET(vp, p, data, (int *)&size, xflags, NULL, error); if (!error) error = -size; - return -error; + return linux_err_code(-error); } if (strncmp(name, xfs_namespaces[USER_NAMES].name, xfs_namespaces[USER_NAMES].namelen) == 0) { @@ -729,7 +729,7 @@ VOP_ATTR_GET(vp, p, data, (int *)&size, xflags, NULL, error); if (!error) error = -size; - return -error; + return linux_err_code(-error); } return -ENOATTR; } @@ -759,7 +759,7 @@ memset(&cursor, 0, sizeof(cursor)); VOP_ATTR_LIST(vp, data, size, xflags, &cursor, NULL, error); if (error > 0) - return -error; + return linux_err_code(-error); result += -error; k += result; /* advance start of our buffer */ @@ -801,7 +801,7 @@ error = xfs_acl_vremove(vp, _ACL_TYPE_DEFAULT); else if (strcmp(p, POSIXCAP) == 0) error = xfs_cap_vremove(vp); - return error; + return linux_err_code(error); } if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, @@ -811,7 +811,7 @@ xflags |= ATTR_ROOT; p += xfs_namespaces[ROOT_NAMES].namelen; VOP_ATTR_REMOVE(vp, p, xflags, NULL, error); - return -error; + return linux_err_code(-error); } if (strncmp(name, xfs_namespaces[USER_NAMES].name, xfs_namespaces[USER_NAMES].namelen) == 0) { @@ -819,7 +819,7 @@ if (!capable_user_xattr(inode)) return -EPERM; VOP_ATTR_REMOVE(vp, p, xflags, NULL, error); - return -error; + return linux_err_code(-error); } return -ENOATTR; } Index: linux/xfs_linux.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_linux.h,v retrieving revision 1.84 diff -u -w -b -B -r1.84 xfs_linux.h --- linux/xfs_linux.h 2002/09/05 05:37:11 1.84 +++ linux/xfs_linux.h 2002/09/19 20:21:07 @@ -133,17 +133,21 @@ #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ /* - * XXX EFSCORRUPTED needs a real value in errno.h. asm-i386/errno.h won't - * return codes out of its known range in errno. - * XXX Also note: needs to be < 1000 and fairly unique on Linux (mustn't - * conflict with any code we use already or any code a driver may use) - * XXX Some options (currently we do #2): - * 1/ New error code ["Filesystem is corrupted", _after_ glibc updated] - * 2/ 990 ["Unknown error 990"] - * 3/ EUCLEAN ["Structure needs cleaning"] - * 4/ Convert EFSCORRUPTED to EIO [just prior to return into userspace] + * EFSCORRUPTED needs to be distinct from other errors internally to + * the filesystem. + * + * Linux error codes are return as negative values, so externally we + * need to expose -EFSCORRUPTED with EIO. + * + * This however means whatever value we choose must be unique from + * other error codes. The present value of 990 more than suffices at + * present. */ #define EFSCORRUPTED 990 /* Filesystem is corrupted */ +/* xlate to linux error code */ +#define linux_err_code(x) (((x) == (-EFSCORRUPTED))?(-EIO):(x)) + + #define SYNCHRONIZE() barrier() #define lbolt jiffies Index: linux/xfs_super.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c,v retrieving revision 1.213 diff -u -w -b -B -r1.213 xfs_super.c --- linux/xfs_super.c 2002/09/13 02:01:06 1.213 +++ linux/xfs_super.c 2002/09/19 20:21:07 @@ -621,7 +621,7 @@ VFS_STATVFS(vfsp, statp, NULL, error); - return error; + return linux_err_code(error); } int @@ -669,7 +669,7 @@ out: kfree(args); - return error; + return linux_err_code(error); } void From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:41:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:41:19 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKfFtG007228 for ; Thu, 19 Sep 2002 13:41:15 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 028C01DA566; Thu, 19 Sep 2002 13:46:23 -0700 (PDT) Date: Thu, 19 Sep 2002 13:46:23 -0700 From: Chris Wedgwood To: "Gabe E. Nydick" Cc: linux-xfs Subject: Re: {evil tone} is it safe? Message-ID: <20020919204623.GA470@tapu.f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Sep 19, 2002 at 11:49:43AM -0700, Gabe E. Nydick wrote: > I would like to get the performance and scalability back of XFS, so > here is the question. Is it finally ready? What are the > outstanding bugs that need to be fixed. For many people it works very well. A small number of people seem to have has recent problems but most of those seem to be either hardware, proprietary-driver or clue related. I would suggest if you can to try it out once again on a test machine and see how it works for you. If it doesn't, then by all means provide a bug report! --cw From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:57:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:57:54 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKvmtG008530 for ; Thu, 19 Sep 2002 13:57:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA77230 for ; Thu, 19 Sep 2002 16:02:52 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA87868 for ; Thu, 19 Sep 2002 16:02:51 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K4HmQ18342 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 00:17:48 -0400 Resent-Message-Id: <200209200417.g8K4HmQ18342@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA72562 for ; Thu, 19 Sep 2002 15:54:44 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K49f916736 for hch@sgi.com; Fri, 20 Sep 2002 00:09:41 -0400 Date: Fri, 20 Sep 2002 00:09:41 -0400 From: Christoph Hellwig Message-Id: <200209200409.g8K49f916736@dhcp212.munich.sgi.com> Subject: TAKE - Remove some dead prototypes in pagebuf Resent-Date: Fri, 20 Sep 2002 00:17:46 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 19 13:54:05 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.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:127896a linux/fs/xfs/pagebuf/page_buf.h - 1.40 - Remove some dead prototypes From owner-linux-xfs@oss.sgi.com Thu Sep 19 17:04:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 17:04:09 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K042tG013990 for ; Thu, 19 Sep 2002 17:04:02 -0700 Received: from yew.sucs.soton.ac.uk (yew.sucs.soton.ac.uk [152.78.128.19]) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8K095Vc009680 for ; Fri, 20 Sep 2002 01:09:05 +0100 Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id BAA19753 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 01:09:05 +0100 From: To: Seth Mos Subject: Re: Re-occurance of NFS server panics Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id BAA19747; Fri, 20 Sep 2002 01:06:32 +0100 X-Authentication-Warning: yew.sucs.soton.ac.uk: nobody set sender to idh@soton.ac.uk using -f Message-ID: <1032480392.3d8a668823dd1@webmail.soton.ac.uk> Date: Fri, 20 Sep 2002 01:06:32 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, O.G.Parchment@soton.ac.uk, linx-xfs@oss.sgi.com References: <4.3.2.7.2.20020918223708.03a58ef0@pop.xs4all.nl> <4.3.2.7.2.20020919082538.02c86680@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20020919082538.02c86680@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.182.156.27 X-MailScanner: Believed to be clean, Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.6, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME) Resent-Date: Fri, 20 Sep 2002 01:09:05 +0100 (BST) Resent-From: I.D.Hardy@soton.ac.uk Resent-To: linux-xfs@oss.sgi.com Resent-Message-ID: <1032480545.3d8a6721c13c1@webmail.soton.ac.uk> X-Originating-IP: 172.182.156.27 X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.6, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME, FORGED_RCVD_FOUND) X-archive-position: 500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Seth, Steve + Thanks for the suggestions (Steve Lord has also suggested changing these drivers). I've not had sufficient time to look into RedHat Qlogic driver, however, I have now found that the 'qlogicfc' driver that is part of the standard kernel will work with my HBA (I'm sure last time I tried it with an earlier kernel it would not initialize/see my RAID units) - so I'll give this a try. I've also updated to the latest 4.3.15 version of the e1000.o driver from Intel's website. Will see if these help. Regards and Thanks Ian Quoting Seth Mos : > At 22:06 18-9-2002 +0100, I.D.Hardy@soton.ac.uk wrote: > >Seth, > > > >I fairly certain its the Qlogic driver for the QLA2200 HBA (driver > >version 4.27b (I've tried but so far failed to get the more recent > >5.38.9 driver to work). > > That might well be the case. Have you tried backporting or fetching the > > Qlogic driver found in the Red Hat kernels? The drivers in there are > heavily cleaned up and fixed. Fixes that are not yet in the opensource > driver. > > >The only other possibility (well the only other driver not in the > >base/XFS kernel) is an intel driver for a e1000 PRO Gigabit Ethernet > >card (version 3.6.8). > > The e1000 driver does not taint the kernel since it has a GPL license. > Well, at least the 4.3 drivers do. Maybe check in a newer driver. > You can find them on the intel site. I use 4.3.2 > The performance is about 400Mbps on a PIII450 and 32bit pci slot. > > [root@lsautom root]# lsmod > Module Size Used by Not tainted > nfsd 67840 16 (autoclean) > nfs 74684 2 (autoclean) > lockd 47808 1 (autoclean) [nfsd nfs] > sunrpc 62068 1 (autoclean) [nfsd nfs lockd] > tg3 40960 1 > e1000 66828 1 > st 27284 0 > usbcore 57632 1 > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > From owner-linux-xfs@oss.sgi.com Thu Sep 19 18:32:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 18:32:43 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K1WdtG016299 for ; Thu, 19 Sep 2002 18:32:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 SAA04093 for ; Thu, 19 Sep 2002 18:37:47 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA50065 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 11:36:30 +1000 (EST) Date: Fri, 20 Sep 2002 11:36:30 +1000 (EST) From: Nathan Scott Message-Id: <200209200136.LAA50065@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA X-archive-position: 501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Additional refinements for the auto-bench stuff. Date: Thu Sep 19 18:35:55 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127936a cmd/xfstests/tools/auto-qa - 1.37 - Fix up the mailing of results to an owner. cmd/xfstests/bench - 1.4 - Fix up producing the results files. From owner-linux-xfs@oss.sgi.com Thu Sep 19 20:35:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 20:35:39 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K3ZYtG018174 for ; Thu, 19 Sep 2002 20:35:34 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 UAA05044 for ; Thu, 19 Sep 2002 20:40:43 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA65302 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:39:26 +1000 (EST) Date: Fri, 20 Sep 2002 13:39:26 +1000 (EST) From: Nathan Scott Message-Id: <200209200339.NAA65302@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - tidy mount option handling X-archive-position: 502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Cleanup mount argument manipulation, sanitize xfs_cmountfs and move the check for a mount with IRIX project quota enabled much earlier on in the piece. Date: Thu Sep 19 20:36:14 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127944a linux/fs/xfs/xfs_vfsops.c - 1.382 - Split xfs_cmountfs into manageable chunks - separating out those arguments we can validate before reading the superblock from those which happen only afterward. The IRIX project quota mount check moves in here too (earlier on in the piece now). linux/fs/xfs/xfs_mount.c - 1.301 - Move the check for a mount with IRIX project quota enabled in line with other superblock flags checks (much earlier). From owner-linux-xfs@oss.sgi.com Thu Sep 19 22:07:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 22:07:34 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K57VtG019332 for ; Thu, 19 Sep 2002 22:07:31 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 WAA07754 for ; Thu, 19 Sep 2002 22:12:40 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA79540 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 15:11:23 +1000 (EST) Date: Fri, 20 Sep 2002 15:11:23 +1000 (EST) From: Nathan Scott Message-Id: <200209200511.PAA79540@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dabuf btree split bug X-archive-position: 503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix xfs_da_node_split handling of dir/attr buffers for filesystems built with a directory block size larger than the filesystem (and hence attr) blocksize. This does not affect filesystems built with default mkfs.xfs parameters, and only hits when a large number of attributes are set on an inode. Date: Thu Sep 19 22:03:21 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127949a linux/fs/xfs/xfsidbg.c - 1.197 linux/fs/xfs/xfs_macros.c - 1.44 linux/fs/xfs/xfs_da_btree.c - 1.132 linux/fs/xfs/xfs_da_btree.h - 1.48 linux/fs/xfs/xfs_dir.c - 1.140 linux/fs/xfs/xfs_mount.h - 1.156 linux/fs/xfs/xfs_dir2_node.c - 1.25 linux/fs/xfs/xfs_attr.c - 1.95 linux/fs/xfs/xfs_dir2.c - 1.37 - Fix a problem in the dabuf (dir/attr buffer) layer which deals with calculating when a block should be split in two. Previously there was only one constant used in the test. When V2 directories have a block size larger than the fs block size, the constant is too large for extended attributes. So, replace this constant with two, and make the dabuf code use the correct one based upon being used for attributes or directories. From owner-linux-xfs@oss.sgi.com Thu Sep 19 23:09:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 23:09:14 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K69AtG020326 for ; Thu, 19 Sep 2002 23:09:10 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 XAA00838 for ; Thu, 19 Sep 2002 23:14:19 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA78800 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 16:13:01 +1000 (EST) Date: Fri, 20 Sep 2002 16:13:01 +1000 (EST) From: Nathan Scott Message-Id: <200209200613.QAA78800@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - user/kernel sync up X-archive-position: 504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync up userspace with some recent kernel changes, no functional change for the user tools. Date: Thu Sep 19 23:12:16 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127952a cmd/xfsprogs/include/xfs_da_btree.h - 1.11 cmd/xfsprogs/include/libxfs.h - 1.17 cmd/xfsprogs/include/xfs_mount.h - 1.27 cmd/xfsprogs/repair/dir2.c - 1.9 cmd/xfsprogs/repair/dir.c - 1.8 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.16 cmd/xfsprogs/libxfs/xfs_dir.c - 1.8 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.9 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.8 From owner-linux-xfs@oss.sgi.com Fri Sep 20 00:01:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 00:01:59 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K71utG023433 for ; Fri, 20 Sep 2002 00:01:57 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8K76rqo036734; Fri, 20 Sep 2002 09:07:03 +0200 (CEST) Message-Id: <4.3.2.7.2.20020920085756.033e2070@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Sep 2002 09:05:42 +0200 To: "Gabe E. Nydick" , linux-xfs From: Seth Mos Subject: Re: {evil tone} is it safe? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:49 19-9-2002 -0700, Gabe E. Nydick wrote: >So, I was a pilot user of XFS 1.0 and it caused all sorts of problems and >corruptions, but I stuck with it until about 2.4.17, which was around when >ext3 was ready, give or take some time. I would like to get the performance >and scalability back of XFS, so here is the question. Is it finally ready? >What are the outstanding bugs that need to be fixed. I have used XFS longer then this without too much hassle. It is good enough for me. I can not speak for others to determine of XFS is ready. You need to test it before putting it into production at your site. I'd say that the official release tend to keep working reasonably well. But even the original XFS 1.0 (2.4.2!) was not good enough for the oss.sgi.com at that time and died rather quickly in just under a day. If you compare this to the 1.1 (2.4.9 or 2.4.18) release a lot has changed in between. And even now the gap between 2.4.19 and the 1.1 release is 5 months! Don't forget that the stability of XFS is also determined by the system it is running on and depends on the rest of the kernel to cooperate. I couldn't get a box stable with a faulty memory dimm and I don't expect that a filesystem would be able to work around that. Thus I experienced all sorts of corruptions and problems, but hardly XFS specific. I just wasn't trying hard enough using another filesystem. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 20 01:21:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 01:21:47 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K8LhtG003521 for ; Fri, 20 Sep 2002 01:21:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.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 BAA04577 for ; Fri, 20 Sep 2002 01:26:52 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA99791 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 18:25:35 +1000 (EST) Date: Fri, 20 Sep 2002 18:25:35 +1000 (EST) From: Nathan Scott Message-Id: <200209200825.SAA99791@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Undo block splitting change X-archive-position: 506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Ugh - isn't that always the way? - 5pm on Friday and then you run one more test... For some reason I don't get yet, this block splitting change is causing a livelock in dbench with the new benchmarking harness, though all the QA tests are passing with it. So, I've backed it out for now, will have to investigate this some more next week. cheers. Date: Fri Sep 20 01:20:25 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Undoes mod: 2.4.x-xfs:slinx:127949a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127958a linux/fs/xfs/xfsidbg.c - 1.198 linux/fs/xfs/xfs_macros.c - 1.45 linux/fs/xfs/xfs_da_btree.c - 1.133 linux/fs/xfs/xfs_da_btree.h - 1.49 linux/fs/xfs/xfs_dir.c - 1.141 linux/fs/xfs/xfs_mount.h - 1.157 linux/fs/xfs/xfs_dir2_node.c - 1.26 linux/fs/xfs/xfs_attr.c - 1.96 linux/fs/xfs/xfs_dir2.c - 1.38 - Undo extended attribute/directory block splitting change. From owner-linux-xfs@oss.sgi.com Fri Sep 20 02:54:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 02:54:34 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K9sTtG008651 for ; Fri, 20 Sep 2002 02:54:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA81047 for ; Fri, 20 Sep 2002 04:59:35 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA41390 for ; Fri, 20 Sep 2002 04:59:34 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8KHEVq22517 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:14:31 -0400 Resent-Message-Id: <200209201714.g8KHEVq22517@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA07916 for ; Fri, 20 Sep 2002 04:58:04 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8KHD0t22507 for hch@sgi.com; Fri, 20 Sep 2002 13:13:00 -0400 Date: Fri, 20 Sep 2002 13:13:00 -0400 From: Christoph Hellwig Message-Id: <200209201713.g8KHD0t22507@dhcp212.munich.sgi.com> Subject: TAKE - Use min_t in linvfs_get_block_core Resent-Date: Fri, 20 Sep 2002 13:14:31 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Patch from DaveM Date: Fri Sep 20 02:56:28 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127966a linux/fs/xfs/linux/xfs_aops.c - 1.7 - Use min_t in linvfs_get_block_core to avoid a compiler warning on sparc64 From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:09:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:09:14 -0700 (PDT) Received: from mailscanout256k.tataelxsi.co.in ([203.197.168.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KB95tG010344 for ; Fri, 20 Sep 2002 04:09:08 -0700 Message-ID: <3D8B03F4.497B7EE4@tataelxsi.co.in> Date: Fri, 20 Sep 2002 16:48:12 +0530 From: "N.C. Sunil" MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Clarification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncsunil@tataelxsi.co.in Precedence: bulk X-list: linux-xfs Hi ! This is Sunil frm India. We are looking for a solution for the problem of fragmentation caused during I/O transactions on the RAID file system i.e.TP9400. We need to know if : 1. SGI - XFS file system can do an on-fly defragmentation of the data ? 2. Is it unique to only SGI - XFS file system ? 3. If so how will this happen? regards Sunil From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:17:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:17:57 -0700 (PDT) Received: from bingo.yes.lt (mail@bingo.yes.lt [194.176.33.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBHptG010835 for ; Fri, 20 Sep 2002 04:17:52 -0700 Received: from tm (helo=localhost) by bingo.yes.lt with local-esmtp (Exim 3.35 #2 (Debian)) id 17sLRh-0008Vm-00; Fri, 20 Sep 2002 12:55:37 +0200 Date: Fri, 20 Sep 2002 12:55:37 +0200 (EET) From: =?windows-1257?Q?Tadas_=DEelionis?= To: Simon Matter , Seth Mos cc: Linux XFS List Subject: Re: md + xfs (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1257 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g8KBHrtG010836 X-archive-position: 509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tm@arti.lt Precedence: bulk X-list: linux-xfs i have just experienced kernel crash/panic when tried to 'sync' disks when md reconstruction was running. (no logs :/) system was debian woody 2.4.20-pre7, md raid1 autodetect, 2 scsi disks on aic7xxx, SMP, filesystem btw was ext3 - not xfs there goes the strange part... when booting next time md started reconstructing arrays as it should, but filesystems seemed clean... then there was a lot of input/output errors etc, i fsck'ed manually, but system turned out unusable, ALL fs's were corrupted. had to reinstall. i don't know why all the fs's were corrupted - now testing that system with 2.4.19. wonder if those 'Warning - running *really* short on DMA buffers' have anything todo with this. > > I must add that the system is Slackware 8.0 based. The MD support is > > compiled in kernel (no modules support). The partitions are of type > RAID > > autodetect so linux can detect them at boot time. Also the / and /home > > partitions are NOT on the md0 divice. Only /var is. > > > > I do not really have any suggestions for you as to why the log appeared > clean, maybe you really were not mounted when the power was pulled. > As for the filesystem, all you can do is run xfs_check when you get a > chance. > > Steve -- Tadas Þelionis +370-687-14478 tm@arti.lt http://www.arti.lt From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:24:58 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBOstG011316 for ; Fri, 20 Sep 2002 04:24:54 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0F-0000PP-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:19 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKue-0000vU-0F for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 12:21:28 +0200 From: Juergen Sauer Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: MosiX Cluster with XFS - Tried anyone ? Date: Sat, 18 May 2002 10:53:25 +0200 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200205181053.25654.jojo@automatix.de> X-KMail-EncryptionState: X-KMail-SignatureState: X-archive-position: 511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, did anyone successfully tried to build a mosix cluster with XFS ? Reffer to http://www.mosix.org http://www.openmosix.org mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmFoUACgkQW7UKI9EqarHgGQCgoOrvqCVetsUkLsxHlAFNRP1Y klsAn0IgIozy/ae2yuhwEGWkgXjYXszX =kRis -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:24:58 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBOrtG011315 for ; Fri, 20 Sep 2002 04:24:54 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0I-0000RA-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:22 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKug-0000vU-04; Fri, 20 Sep 2002 12:21:30 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: Henri Aanstoot , linux-xfs@oss.sgi.com Subject: Re: RH 7.3 and XFS Date: Mon, 27 May 2002 14:09:52 +0200 User-Agent: KMail/1.4.1 References: <20020527113432.C1230@ao-dai.interaccess.nl> In-Reply-To: <20020527113432.C1230@ao-dai.interaccess.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200205271409.52910.juergen.sauer@automatix.de> X-archive-position: 510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 27. Mai 2002 14:34 schrieb Henri Aanstoot: > I'm waiting for you guys to release RH7.3 install iso .. :) > Any release date known yet? > (how long do i have to wait with formatting my laptop drive? ;) This is a job of the RedHat distributor. > Love the work y'all do ... > keep it up .. mfG J. Sauer - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzyIhAACgkQW7UKI9EqarHZ4gCgoqTFRKx5iZ0gbHYvVTKkxcsp 6HYAniOS2RlEjRJPBmLyDPbgNEF5RjYS =SuFR -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:24:59 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBOstG011317 for ; Fri, 20 Sep 2002 04:24:55 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0F-0000PT-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:19 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKue-0000vU-0G; Fri, 20 Sep 2002 12:21:28 +0200 From: Juergen Sauer Organization: AutomatiX GmbH To: Chris Tooley Subject: Re: MosiX Cluster with XFS - Tried anyone ? Date: Sat, 18 May 2002 16:32:41 +0200 User-Agent: KMail/1.4.5 Cc: linux-xfs@oss.sgi.com References: <200205181053.25654.jojo@automatix.de> <1021724097.2378.1.camel@christooley.cjb.net> In-Reply-To: <1021724097.2378.1.camel@christooley.cjb.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200205181632.46109.jojo@automatix.de> X-KMail-EncryptionState: X-KMail-SignatureState: X-archive-position: 512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 18. Mai 2002 14:14 schrieb Chris Tooley: > Moshe Bar, who develops openMosix explicitly supports XFS as he thinks > it is a higher performance filesystem than most of the other offerings > for linux. There is a lot of information about it on the openMosix > website. Or at least their used to be. Yes, I did know this before. But it is not usable. 1. Getting CVS Version of openmosix [does not contain XFS] 2. getting the XFS-Patch for 2.4.17 3. Installing the patch works with some linefuzzes, configuring, works, builing the xfs-mosix-kernel definitley not: pc2:/usr/src/linux-openmosix # make gcc -D__KERNEL__ -I/usr/src/linux-openmosix/include -Wall - -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer - -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 - -march=i686 -c -o init/main.o init/main.c In file included from /usr/src/linux-openmosix/include/linux/capability.h:17, from /usr/src/linux-openmosix/include/linux/binfmts.h:5, from /usr/src/linux-openmosix/include/linux/sched.h:9, from /usr/src/linux-openmosix/include/linux/mm.h:4, from /usr/src/linux-openmosix/include/linux/slab.h:14, from /usr/src/linux-openmosix/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux-openmosix/include/linux/fs.h:530: field `xfs_i' has incomplete type make: *** [init/main.o] Fehler 1 pc2:/usr/src/linux-openmosix # That's why I asked, if somewhere a XFS-Mosix ist already installed and working. Any ideas here ? mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmZgwACgkQW7UKI9EqarFVxwCcCY6P613hm3G9lSPUWFg8/efk r3YAn3feDtyKK0HalKEji3eLrJ3P5CxP =ST5H -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:39:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:39:14 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBd8tG012676 for ; Fri, 20 Sep 2002 04:39:08 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8KBiGCA085784; Fri, 20 Sep 2002 13:44:18 +0200 (CEST) Message-Id: <4.3.2.7.2.20020920134142.02df57e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Sep 2002 13:43:03 +0200 To: "N.C. Sunil" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Clarification In-Reply-To: <3D8B03F4.497B7EE4@tataelxsi.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 16:48 20-9-2002 +0530, N.C. Sunil wrote: >Hi ! > >This is Sunil frm India. We are looking for a solution for the problem >of fragmentation caused during I/O transactions on the RAID file system >i.e.TP9400. > >We need to know if : >1. SGI - XFS file system can do an on-fly defragmentation of the data ? Yes >2. Is it unique to only SGI - XFS file system ? The defragmentation utility is. Other filesystems can do it as well. But I am not familiar with those. >3. If so how will this happen? Run the xfs_fsr utility to defragment your harddrive. Some people run this overnight in cron every day or week. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:55:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:55:19 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBtGtG013355 for ; Fri, 20 Sep 2002 04:55:17 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0h-0000cs-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:47 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKvD-0000vU-03; Fri, 20 Sep 2002 12:22:03 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Who's using XFS? (again) Date: Wed, 24 Jul 2002 22:58:07 +0200 User-Agent: KMail/1.4.2 References: <1027117051.12810.74.camel@stout.americas.sgi.com> In-Reply-To: <1027117051.12810.74.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207242258.12989.jojo@automatix.de> X-archive-position: 514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 20. Juli 2002 00:17 schrieb Eric Sandeen: > Hi all - > I've been asked to take another pulse of the XFS user community; we did > this a while ago, and the results are at > http://oss.sgi.com/projects/xfs/xfs_users.html > If you're using XFS in an interesting/large/impressive/unique > installation, or your company is shipping a product using XFS (and you > can go on the record about it*) I'd like to know, so I can update the > information in the above web page. We use XFS exlusively on about 15 production servers. The biggest is called 'goliath', which is a fileserver >4 TeraByte. We run XFS 1.1 in Kernel 2.4.18-xfs, CVS from 1,5 month ago. XFS seems to us the most reliable an most usable filesystem in the Linux world. My production test on goliath was Power-off without any shutdown, more than 10 times. The system (XFS is root fs) came up in a glance. Later a SapDB Server was added on extra hdd space. XFS succeeded our hard-core crash/power down crash tests also very fine. SapDB (see: http://www.sapdb.org, http://sapdb.automatix.de, GPLed enterprise class RDBMS, compareable to Oracle, successor and anchestor of Adabas D) runns very fin on XFS in Linux. We were heavyly disapointed in reiserfs. Sure the theretical specs are impressive, but there was missing realiabilit. We say only: NFS+disapearing files until next boot. We can not recommend ext2/ext3 due extensive filesystem checks. Ext3 is a journaled fs for starter. We hate IBM jfs due big instability. JFS is not usable for a stable, reliable system. Needs manually repair filesystem after powerloss, jfs looses data during this 'repair filesystem'. My opinion: forget jfs. As JFS was designated by SuSE as IBM partner, it was included jfs in 7.3 distribution, so we took in in a IBM friendly customer's server. We earned Only troubles. The support exchanged it against XFS on month later, now this server runns 137 days up without any further troubles. To Linus: You may forward this eMail to Linus. PErhaps he recognizes the fine work of the XFS staff. To XFS staff: GREAT WORK. KEEP ON. mfG J. Sauer CEO AutomatiX Ltd. Germany - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0/FOMACgkQW7UKI9EqarE0qgCghVZSJS8zGpl8ulQUYhtqSTkl RUQAni7p7EjTB9b1EtejkoBaABOt2sYI =uOE4 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 07:13:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 07:13:05 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KED0tG022614 for ; Fri, 20 Sep 2002 07:13:01 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sOcz-0002Jy-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 16:19:29 +0200 Received: from [192.168.11.12] (helo=pc2) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sOVm-0003Cd-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 16:12:02 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: Double Posts Date: Fri, 20 Sep 2002 16:12:01 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209201612.01137.jojo@automatix.de> X-archive-position: 515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, Please ignore my eMailys from today. Those were created by an old backup-restore on one of our servers. Sorry for any inconvienience. mfG J. Sauer - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2LLLEACgkQW7UKI9EqarF1cACfUt9BCDEQgChyigfzQM2DeuIz nBEAn0FN0eSnsPMa5ZG3vBcvetwnTWIF =1UA1 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 07:46:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 07:47:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KEkvtG023568 for ; Fri, 20 Sep 2002 07:46:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA82507 for ; Fri, 20 Sep 2002 09:52:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA03408 for ; Fri, 20 Sep 2002 09:52:03 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8KEm6e18287; Fri, 20 Sep 2002 09:48:06 -0500 Message-Id: <200209201448.g8KEm6e18287@jen.americas.sgi.com> Date: Fri, 20 Sep 2002 09:48:06 -0500 Subject: TAKE - Merge up to 2.5.36 To: linux-xfs@oss.sgi.com X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs This brings the xfs 2.5 cvs tree in line with Linus's 2.5.36. The only differences between this tree and 2.5.36 should be the parts of xfs which were not submitted to Linus, changes made to xfs since then and kdb. Steve Date: Fri Sep 20 07:35:02 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127971a linux/arch/m68k/vmlinux-std.lds - 1.1 linux/drivers/char/vt_ioctl.c - 1.1 linux/arch/ppc64/vmlinux.lds.S - 1.1 linux/arch/x86_64/vmlinux.lds.S - 1.1 linux/lib/dump_stack.c - 1.1 linux/arch/m68k/vmlinux.lds.S - 1.1 linux/arch/arm/vmlinux.lds.S - 1.1 linux/arch/sparc64/vmlinux.lds.S - 1.1 linux/arch/sparc/vmlinux.lds.S - 1.1 linux/arch/s390x/vmlinux.lds.S - 1.1 linux/arch/cris/vmlinux.lds.S - 1.1 linux/arch/ppc/vmlinux.lds.S - 1.1 linux/arch/s390/vmlinux.lds.S - 1.1 linux/arch/mips/vmlinux.lds.S - 1.1 linux/arch/parisc/vmlinux.lds.S - 1.1 linux/arch/i386/mm/hugetlbpage.c - 1.1 linux/mm/vmscan.c - 1.112 linux/mm/vmalloc.c - 1.44 linux/mm/slab.c - 1.39 linux/mm/page_alloc.c - 1.91 linux/mm/mremap.c - 1.33 linux/mm/mprotect.c - 1.32 linux/mm/mmap.c - 1.59 linux/mm/memory.c - 1.91 linux/mm/filemap.c - 1.134 linux/lib/Makefile - 1.13 linux/kernel/sysctl.c - 1.57 linux/kernel/ksyms.c - 1.164 linux/kernel/exit.c - 1.54 linux/include/linux/sysctl.h - 1.61 linux/include/linux/sched.h - 1.83 linux/include/linux/mm.h - 1.100 linux/include/linux/kernel.h - 1.36 linux/include/linux/blkdev.h - 1.68 linux/include/asm-i386/page.h - 1.30 linux/include/asm-i386/hardirq.h - 1.23 linux/fs/proc/array.c - 1.47 linux/fs/exec.c - 1.65 linux/fs/buffer.c - 1.134 linux/fs/block_dev.c - 1.59 linux/drivers/char/vt.c - 1.27 linux/drivers/char/tty_ioctl.c - 1.8 linux/drivers/char/misc.c - 1.31 linux/drivers/char/console.c - 1.32 linux/drivers/char/Makefile - 1.73 linux/drivers/block/ll_rw_blk.c - 1.113 linux/arch/sparc64/vmlinux.lds - 1.14 linux/arch/sparc64/Makefile - 1.20 linux/arch/sparc/vmlinux.lds - 1.13 linux/arch/sparc/Makefile - 1.14 linux/arch/ppc/vmlinux.lds - 1.17 linux/arch/ppc/Makefile - 1.27 linux/arch/ppc/8xx_io/uart.c - 1.22 linux/arch/mips/Makefile - 1.13 linux/arch/m68k/vmlinux.lds - 1.14 linux/arch/m68k/Makefile - 1.10 linux/arch/i386/mm/init.c - 1.42 linux/arch/i386/mm/Makefile - 1.9 linux/arch/i386/kernel/traps.c - 1.59 linux/arch/i386/kernel/sys_i386.c - 1.9 linux/arch/i386/kernel/entry.S - 1.63 linux/arch/i386/config.in - 1.90 linux/arch/i386/Makefile - 1.31 linux/arch/arm/Makefile - 1.33 linux/arch/alpha/kernel/traps.c - 1.23 linux/arch/alpha/Makefile - 1.20 linux/Makefile - 1.217 linux/include/linux/ide.h - 1.63 linux/kernel/ptrace.c - 1.26 linux/arch/sh/Makefile - 1.13 linux/fs/proc/proc_misc.c - 1.41 linux/include/linux/mmzone.h - 1.26 linux/Documentation/usb/usb-serial.txt - 1.21 linux/Documentation/usb/ov511.txt - 1.19 linux/drivers/ieee1394/raw1394.c - 1.19 linux/drivers/ieee1394/ieee1394_core.h - 1.13 linux/drivers/ieee1394/pcilynx.h - 1.10 linux/drivers/ieee1394/pcilynx.c - 1.22 linux/drivers/ieee1394/ieee1394_core.c - 1.22 linux/drivers/ieee1394/ohci1394.h - 1.16 linux/drivers/ieee1394/ohci1394.c - 1.23 linux/drivers/ieee1394/hosts.h - 1.11 linux/drivers/ieee1394/hosts.c - 1.13 linux/drivers/ieee1394/csr.c - 1.8 linux/drivers/ieee1394/highlevel.c - 1.8 linux/arch/ia64/Makefile - 1.19 linux/arch/ia64/kernel/perfmon.c - 1.16 linux/arch/mips64/Makefile - 1.13 linux/include/linux/usb.h - 1.46 linux/drivers/usb/serial/usb-serial.h - 1.22 linux/drivers/ide/ide_modes.h - 1.9 linux/drivers/ide/ide.c - 1.66 linux/drivers/ide/ide-probe.c - 1.37 linux/drivers/ide/ide-dma.c - 1.30 linux/drivers/ide/Makefile - 1.29 linux/drivers/ide/Config.in - 1.33 linux/drivers/block/elevator.c - 1.22 linux/include/linux/elevator.h - 1.12 linux/drivers/usb/serial/keyspan_pda.c - 1.30 linux/drivers/usb/serial/ftdi_sio.c - 1.40 linux/drivers/usb/serial/usbserial.c - 1.41 linux/drivers/usb/serial/whiteheat.c - 1.29 linux/drivers/usb/serial/visor.c - 1.39 linux/drivers/usb/serial/omninet.c - 1.28 linux/drivers/usb/serial/digi_acceleport.c - 1.31 linux/arch/s390/Makefile - 1.10 linux/kdb/kdb_bt.c - 1.12 linux/kdb/kdbmain.c - 1.34 linux/drivers/usb/storage/usb.h - 1.17 linux/drivers/usb/storage/usb.c - 1.29 linux/drivers/usb/storage/transport.c - 1.27 linux/drivers/usb/storage/scsiglue.c - 1.26 linux/drivers/usb/storage/protocol.c - 1.11 linux/drivers/usb/storage/debug.h - 1.7 linux/drivers/usb/storage/debug.c - 1.10 linux/drivers/usb/serial/keyspan.h - 1.13 linux/drivers/usb/serial/keyspan.c - 1.32 linux/drivers/ieee1394/video1394.c - 1.21 linux/drivers/usb/storage/shuttle_usbat.c - 1.11 linux/drivers/usb/storage/sddr09.c - 1.18 linux/drivers/usb/storage/freecom.c - 1.14 linux/drivers/media/video/cpia_usb.c - 1.12 linux/drivers/usb/serial/belkin_sa.c - 1.24 linux/drivers/usb/serial/mct_u232.c - 1.23 linux/arch/parisc/vmlinux.lds - 1.5 linux/drivers/usb/serial/empeg.c - 1.28 linux/arch/parisc/Makefile - 1.6 linux/arch/cris/Makefile - 1.13 linux/arch/cris/cris.ld - 1.10 linux/arch/cris/kernel/traps.c - 1.10 linux/arch/s390x/Makefile - 1.10 linux/drivers/usb/serial/io_tables.h - 1.7 linux/drivers/usb/serial/io_edgeport.c - 1.28 linux/drivers/bluetooth/hci_usb.c - 1.10 linux/drivers/usb/serial/cyberjack.c - 1.17 linux/drivers/usb/serial/pl2303.c - 1.19 linux/arch/mips/ld.script.in - 1.3 linux/drivers/message/fusion/mptscsih.h - 1.5 linux/drivers/message/fusion/mptscsih.c - 1.9 linux/drivers/message/fusion/mptctl.c - 1.9 linux/drivers/message/fusion/mptbase.h - 1.6 linux/drivers/message/fusion/mptbase.c - 1.6 linux/drivers/message/fusion/lsi/mpi_type.h - 1.3 linux/drivers/message/fusion/lsi/mpi_targ.h - 1.4 linux/drivers/message/fusion/lsi/mpi_lan.h - 1.4 linux/drivers/message/fusion/lsi/mpi_ioc.h - 1.4 linux/drivers/message/fusion/lsi/mpi_init.h - 1.4 linux/drivers/message/fusion/lsi/mpi_fc.h - 1.4 linux/drivers/message/fusion/lsi/mpi_cnfg.h - 1.4 linux/drivers/message/fusion/lsi/mpi.h - 1.4 linux/drivers/message/fusion/Makefile - 1.7 linux/drivers/message/fusion/linux_compat.h - 1.3 linux/drivers/ieee1394/sbp2.c - 1.11 linux/drivers/ieee1394/sbp2.h - 1.9 linux/drivers/ieee1394/nodemgr.c - 1.11 linux/drivers/usb/storage/isd200.c - 1.9 linux/arch/mips/au1000/common/serial.c - 1.4 linux/drivers/isdn/hisax/st5481_init.c - 1.5 linux/lib/rbtree.c - 1.3 linux/include/linux/rbtree.h - 1.2 linux/include/asm-generic/tlb.h - 1.10 linux/drivers/usb/serial/ir-usb.c - 1.19 linux/fs/ext3/ialloc.c - 1.14 linux/fs/ext3/inode.c - 1.20 linux/fs/ext3/ioctl.c - 1.6 linux/fs/ext3/namei.c - 1.11 linux/fs/ext3/super.c - 1.23 linux/include/linux/ext3_fs.h - 1.8 linux/fs/ext3/balloc.c - 1.9 linux/fs/ext3/dir.c - 1.5 linux/fs/bio.c - 1.17 linux/include/linux/device.h - 1.16 linux/mm/mempool.c - 1.9 linux/drivers/usb/serial/ipaq.c - 1.13 linux/drivers/usb/serial/kl5kusb105.c - 1.12 linux/drivers/ieee1394/dv1394-private.h - 1.4 linux/drivers/ieee1394/dv1394.c - 1.6 linux/arch/i386/Config.help - 1.12 linux/drivers/base/core.c - 1.13 linux/arch/ppc/4xx_io/serial_sicc.c - 1.3 linux/arch/x86_64/Makefile - 1.8 linux/arch/x86_64/vmlinux.lds - 1.5 linux/arch/ppc64/Makefile - 1.8 linux/arch/ppc64/vmlinux.lds - 1.5 linux/drivers/ieee1394/eth1394.c - 1.2 linux/drivers/usb/image/microtek.c - 1.4 linux/drivers/usb/class/audio.c - 1.6 linux/drivers/usb/class/bluetty.c - 1.8 linux/drivers/usb/class/cdc-acm.c - 1.7 linux/drivers/usb/core/devices.c - 1.4 linux/drivers/usb/core/devio.c - 1.8 linux/drivers/usb/core/hcd.c - 1.11 linux/drivers/usb/core/hcd.h - 1.8 linux/drivers/usb/core/hub.c - 1.10 linux/drivers/usb/core/hub.h - 1.5 linux/drivers/usb/input/hid-core.c - 1.8 linux/drivers/usb/core/usb.c - 1.15 linux/drivers/usb/media/konicawc.c - 1.6 linux/drivers/usb/media/stv680.c - 1.7 linux/drivers/usb/media/usbvideo.c - 1.8 linux/drivers/usb/image/hpusbscsi.c - 1.6 linux/drivers/usb/image/mdc800.c - 1.7 linux/drivers/ieee1394/cmp.c - 1.2 linux/drivers/usb/image/microtek.h - 1.2 linux/drivers/usb/image/scanner.c - 1.10 linux/drivers/ieee1394/amdtp.h - 1.2 linux/drivers/ieee1394/amdtp.c - 1.3 linux/drivers/usb/input/hiddev.c - 1.9 linux/drivers/usb/input/usbkbd.c - 1.4 linux/drivers/usb/input/usbmouse.c - 1.4 linux/drivers/usb/input/wacom.c - 1.4 linux/drivers/usb/media/dabusb.c - 1.9 linux/drivers/usb/media/dsbr100.c - 1.4 linux/drivers/usb/media/ibmcam.c - 1.5 linux/drivers/usb/media/ov511.c - 1.7 linux/drivers/usb/media/ov511.h - 1.4 linux/drivers/usb/media/pwc-if.c - 1.5 linux/drivers/usb/serial/safe_serial.c - 1.7 linux/drivers/usb/media/se401.c - 1.9 linux/drivers/usb/net/usbnet.c - 1.10 linux/drivers/usb/net/rtl8150.c - 1.7 linux/drivers/usb/media/ultracam.c - 1.5 linux/drivers/usb/media/usbvideo.h - 1.6 linux/drivers/usb/net/pegasus.c - 1.8 linux/drivers/usb/media/vicam.c - 1.4 linux/drivers/usb/net/kaweth.c - 1.9 linux/drivers/usb/net/cdc-ether.c - 1.7 linux/drivers/usb/net/catc.c - 1.4 linux/mm/readahead.c - 1.9 linux/drivers/usb/misc/uss720.c - 1.3 linux/drivers/usb/misc/auerswald.c - 1.8 linux/drivers/usb/misc/emi26.c - 1.5 linux/drivers/usb/misc/rio500.c - 1.5 linux/drivers/usb/misc/tiglusb.c - 1.8 linux/drivers/usb/misc/brlvger.c - 1.7 linux/fs/ntfs/aops.c - 1.10 linux/include/linux/page-flags.h - 1.9 linux/drivers/usb/storage/raw_bulk.c - 1.3 linux/drivers/usb/class/usb-midi.c - 1.5 linux/arch/i386/kernel/cpu/transmeta.c - 1.3 linux/arch/i386/kernel/cpu/intel.c - 1.6 linux/arch/i386/kernel/cpu/amd.c - 1.3 linux/arch/i386/kernel/cpu/common.c - 1.6 linux/drivers/usb/input/aiptek.c - 1.6 linux/drivers/message/fusion/lsi/mpi_raid.h - 1.2 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.4 linux/drivers/usb/input/powermate.c - 1.4 linux/drivers/usb/input/xpad.c - 1.4 linux/drivers/usb/serial/io_ti.c - 1.3 linux/mm/rmap.c - 1.7 linux/net/sched/sch_htb.c - 1.2 linux/drivers/usb/misc/speedtouch.c - 1.2 linux/drivers/usb/class/usblp.c - 1.2 linux/drivers/usb/misc/usblcd.c - 1.2 linux/drivers/ide/pci/pdc202xx.c - 1.2 linux/drivers/ide/setup-pci.c - 1.2 linux/drivers/ide/pci/via82cxxx.h - 1.2 linux/drivers/ide/pci/via82cxxx.c - 1.2 linux/drivers/ide/pci/trm290.h - 1.2 linux/drivers/ide/pci/trm290.c - 1.2 linux/drivers/ide/pci/slc90e66.h - 1.2 linux/drivers/ide/pci/slc90e66.c - 1.2 linux/drivers/ide/pci/sl82c105.h - 1.2 linux/drivers/ide/pci/sl82c105.c - 1.2 linux/drivers/ide/pci/sis5513.h - 1.2 linux/drivers/ide/pci/sis5513.c - 1.2 linux/drivers/ide/pci/siimage.h - 1.2 linux/drivers/ide/pci/siimage.c - 1.2 linux/drivers/ide/pci/serverworks.h - 1.2 linux/drivers/ide/pci/serverworks.c - 1.2 linux/drivers/ide/pci/rz1000.h - 1.2 linux/drivers/ide/pci/rz1000.c - 1.2 linux/drivers/ide/pci/piix.h - 1.2 linux/drivers/ide/pci/piix.c - 1.2 linux/drivers/ide/pci/pdcadma.h - 1.2 linux/drivers/ide/pci/pdcadma.c - 1.2 linux/drivers/ide/pci/pdc202xx_old.h - 1.2 linux/drivers/ide/pci/pdc202xx_old.c - 1.2 linux/drivers/ide/pci/pdc202xx_new.h - 1.2 linux/drivers/ide/pci/pdc202xx_new.c - 1.2 linux/drivers/ide/pci/pdc202xx.h - 1.2 linux/drivers/ide/pci/opti621.h - 1.2 linux/drivers/ide/pci/opti621.c - 1.2 linux/drivers/ide/pci/nvidia.h - 1.2 linux/drivers/ide/pci/nvidia.c - 1.2 linux/drivers/ide/pci/ns87415.h - 1.2 linux/drivers/ide/pci/ns87415.c - 1.2 linux/drivers/ide/pci/it8172.h - 1.2 linux/drivers/ide/pci/it8172.c - 1.2 linux/drivers/ide/pci/hpt366.h - 1.2 linux/drivers/ide/pci/hpt366.c - 1.2 linux/drivers/ide/pci/hpt34x.h - 1.2 linux/drivers/ide/pci/hpt34x.c - 1.2 linux/drivers/ide/pci/generic.h - 1.2 linux/drivers/ide/pci/generic.c - 1.2 linux/drivers/ide/pci/cy82c693.h - 1.2 linux/drivers/ide/pci/cy82c693.c - 1.2 linux/drivers/ide/pci/cs5530.h - 1.2 linux/drivers/ide/pci/cs5530.c - 1.2 linux/drivers/ide/pci/cmd64x.h - 1.2 linux/drivers/ide/pci/cmd64x.c - 1.2 linux/drivers/ide/pci/amd74xx.h - 1.2 linux/drivers/ide/pci/amd74xx.c - 1.2 linux/drivers/ide/pci/alim15x3.h - 1.2 linux/drivers/ide/pci/alim15x3.c - 1.2 linux/drivers/ide/pci/aec62xx.h - 1.2 linux/drivers/ide/pci/aec62xx.c - 1.2 linux/drivers/ide/pci/Makefile - 1.2 linux/drivers/ide/legacy/hd.c - 1.2 linux/drivers/ide/legacy/Makefile - 1.2 linux/drivers/ide/ide-lib.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Sep 20 09:30:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 09:30:36 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KGUVtG030574 for ; Fri, 20 Sep 2002 09:30:31 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 09:35:58 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B01015A02@nasexs1.meridian-data.com> From: Marc Kaplan To: "'Gabe E. Nydick'" , linux-xfs Subject: RE: {evil tone} is it safe? Date: Fri, 20 Sep 2002 09:35:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc.kaplan@quantum.com Precedence: bulk X-list: linux-xfs Many companies are using XFS in products currently shipping to customers. Quantum for example, uses XFS on each Guardian network attached storage box we sell. The Guardian is an enterprise class product, and I've not heard of any customer who's ever had any sort of file system corruption problems. For a list of other companies using xfs see http://oss.sgi.com/projects/xfs/xfs_users.html >So, I was a pilot user of XFS 1.0 and it caused all sorts of problems and >corruptions, but I stuck with it until about 2.4.17, which was around when >ext3 was ready, give or take some time. I would like to get the performance >and scalability back of XFS, so here is the question. Is it finally ready? >What are the outstanding bugs that need to be fixed. > >- Gabe From owner-linux-xfs@oss.sgi.com Fri Sep 20 11:35:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 11:35:13 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KIZ8tG032567 for ; Fri, 20 Sep 2002 11:35:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA85442 for ; Fri, 20 Sep 2002 13:40:13 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA41008 for ; Fri, 20 Sep 2002 13:40:12 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8L1t8B01983 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 21:55:08 -0400 Resent-Message-Id: <200209210155.g8L1t8B01983@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA12429 for ; Fri, 20 Sep 2002 13:14:32 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8L1TSr01963 for hch@sgi.com; Fri, 20 Sep 2002 21:29:28 -0400 Date: Fri, 20 Sep 2002 21:29:28 -0400 From: Christoph Hellwig Message-Id: <200209210129.g8L1TSr01963@dhcp212.munich.sgi.com> Subject: TAKE - Avoid buffer_heads in linvfs_readpage if possible Resent-Date: Fri, 20 Sep 2002 21:55:08 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Sep 20 11:13:52 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127994a linux/fs/xfs/linux/xfs_aops.c - 1.8 - Switch from block_read_full_page to mpage_readpage From owner-linux-xfs@oss.sgi.com Fri Sep 20 12:02:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 12:02:44 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KJ2btG000787 for ; Fri, 20 Sep 2002 12:02:39 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id D5A911DAD48; Fri, 20 Sep 2002 12:07:49 -0700 (PDT) Date: Fri, 20 Sep 2002 12:07:49 -0700 From: Chris Wedgwood To: "N.C. Sunil" Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020920190749.GB10692@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B03F4.497B7EE4@tataelxsi.co.in> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 20, 2002 at 04:48:12PM +0530, N.C. Sunil wrote: > This is Sunil frm India. We are looking for a solution for the > problem of fragmentation caused during I/O transactions on the RAID > file system i.e.TP9400. Fragmentation is normal and will *always* occur at times. I assume what you really want is sufficiently low levels of fragmentation and high-performance in the face of fragments? XFS seems to do pretty well here, arguably better than anything else in the Linux world. Outside the Linux work it's a different story :) > We need to know if : > 1. SGI - XFS file system can do an on-fly defragmentation of the > data ? Sort of. There is a userspace utility which can in many cases defragment files, but there are some caveats here. > 2. Is it unique to only SGI - XFS file system ? Nothing is unique to XFS :) --cw From owner-linux-xfs@oss.sgi.com Fri Sep 20 12:38:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 12:38:19 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KJcDtG002119 for ; Fri, 20 Sep 2002 12:38:13 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 301841DAD40; Fri, 20 Sep 2002 12:43:26 -0700 (PDT) Date: Fri, 20 Sep 2002 12:43:26 -0700 From: Chris Wedgwood To: Juri Haberland Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020920194326.GB15065@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B75DC.1010305@koschikode.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 20, 2002 at 09:24:12PM +0200, Juri Haberland wrote: > Out of curiosity, could you elaborate on this a little bit? Sure. xfs_fsr defragments file be looking at which files are fragmented, create a new file preallocating space for a defragmented version of that file an copying the old file to the new file. However, xfs_fsr doesn't always know reliably when it can and cannot further defragment files. I mad fixed to my local version here when I saw it was trying to defragment files that *must* span multiple AGs because of their size (technically it's not the file size, but aggregated size of adjacent extents as holes don't count). Whe the file is copied, it tests to see if the original has changed and then 'swaps' the extents from the old to the new. Because xfs_fsr 'copies' the data, it's actually rather slow and can (usually) does slow access to the fs noticeably. It also means you cannot defragment files which are in use. The other things to consider is that it defagments *files* not filesystems, so potentially as you defragment files, you fragment free space. (I'm not sure in reality of this is a problem though, in practise if your filesystem is large compared to you average file size then probaby not). On last this to consider, a recent minor security fix means xfs_fsr cannot defragment non-root owned files... --cw From owner-linux-xfs@oss.sgi.com Fri Sep 20 12:46:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 12:46:05 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KJjqtG002593 for ; Fri, 20 Sep 2002 12:45:53 -0700 Received: from localhost (unknown [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 2DEE1101024; Fri, 20 Sep 2002 21:24:19 +0200 (CEST) Received: from warp9.sapienti-sat.org (pD9EB13C2.dip.t-dialin.net [217.235.19.194]) by batleth.sapienti-sat.org (Postfix) with ESMTP id DA8A710071E; Fri, 20 Sep 2002 21:24:18 +0200 (CEST) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id 6EA52D16; Fri, 20 Sep 2002 21:24:14 +0200 (CEST) Received: from koschikode.com (kaplah.sapienti-sat.org [192.168.200.15]) by warp9.sapienti-sat.org (Postfix) with ESMTP id ABD1A533; Fri, 20 Sep 2002 21:24:13 +0200 (CEST) Message-ID: <3D8B75DC.1010305@koschikode.com> Date: Fri, 20 Sep 2002 21:24:12 +0200 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > On Fri, Sep 20, 2002 at 04:48:12PM +0530, N.C. Sunil wrote: >> 1. SGI - XFS file system can do an on-fly defragmentation of the >> data ? > > Sort of. There is a userspace utility which can in many cases > defragment files, but there are some caveats here. Out of curiosity, could you elaborate on this a little bit? Thanks, Juri From owner-linux-xfs@oss.sgi.com Fri Sep 20 13:27:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 13:27:43 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KKRZtG003480 for ; Fri, 20 Sep 2002 13:27:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA86958 for ; Fri, 20 Sep 2002 15:32:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA22154 for ; Fri, 20 Sep 2002 15:32:43 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8KKSgw05367; Fri, 20 Sep 2002 15:28:42 -0500 Message-Id: <200209202028.g8KKSgw05367@jen.americas.sgi.com> Date: Fri, 20 Sep 2002 15:28:42 -0500 Subject: TAKE - merge up to 2.5.37 To: linux-xfs@oss.sgi.com X-archive-position: 522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Another merge up with Linus. Steve Part of 2.5.37 merge, Code from Jens Axboe to update pagebuf with new bio infrastructure. axboe@suse.de Date: Fri Sep 20 13:24:47 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128018a linux/fs/xfs/pagebuf/page_buf.c - 1.62 - Start using bio_add_page(), added by Jens Axboe Subject: TAKE - merge up to 2.5.37 Date: Fri Sep 20 13:27:57 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128025a linux/arch/ppc/boot/include/cpc700.h - 1.1 linux/Documentation/driver-model/binding.txt - 1.1 linux/Documentation/driver-model/bus.txt - 1.1 linux/Documentation/driver-model/class.txt - 1.1 linux/Documentation/driver-model/device.txt - 1.1 linux/Documentation/driver-model/driver.txt - 1.1 linux/Documentation/driver-model/interface.txt - 1.1 linux/Documentation/driver-model/overview.txt - 1.1 linux/Documentation/driver-model/platform.txt - 1.1 linux/arch/i386/mach-visws/traps.c - 1.1 linux/arch/i386/mach-visws/smpboot_hooks.h - 1.1 linux/arch/ppc/boot/include/mpc10x.h - 1.1 linux/arch/ppc/boot/include/of1275.h - 1.1 linux/include/asm-i386/numnodes.h - 1.1 linux/arch/ppc/boot/common/mpc10x_memory.c - 1.1 linux/drivers/acpi/blacklist.c - 1.1 linux/arch/sparc64/mm/hugetlbpage.c - 1.1 linux/include/asm-i386/arch_hooks.h - 1.1 linux/include/asm-alpha/numnodes.h - 1.1 linux/arch/ppc/boot/common/cpc700_memory.c - 1.1 linux/arch/i386/mach-visws/irq_vectors.h - 1.1 linux/drivers/acpi/sleep.c - 1.1 linux/drivers/acpi/driverfs.c - 1.1 linux/kernel/pid.c - 1.1 linux/drivers/acpi/debug.c - 1.1 linux/net/bridge/netfilter/ebtables.c - 1.1 linux/net/bridge/netfilter/ebtable_nat.c - 1.1 linux/net/bridge/netfilter/ebtable_filter.c - 1.1 linux/net/bridge/netfilter/ebtable_broute.c - 1.1 linux/arch/ppc/boot/of1275/getprop.c - 1.1 linux/net/bridge/netfilter/ebt_vlan.c - 1.1 linux/arch/i386/kernel/reboot.c - 1.1 linux/arch/ppc64/kernel/asm-offsets.c - 1.1 linux/net/bridge/netfilter/ebt_snat.c - 1.1 linux/net/bridge/netfilter/ebt_redirect.c - 1.1 linux/arch/ppc/boot/of1275/ofinit.c - 1.1 linux/net/bridge/netfilter/ebt_mark_m.c - 1.1 linux/net/bridge/netfilter/ebt_mark.c - 1.1 linux/net/bridge/netfilter/ebt_log.c - 1.1 linux/net/bridge/netfilter/ebt_ip.c - 1.1 linux/arch/i386/mach-generic/Makefile - 1.1 linux/arch/i386/mach-generic/do_timer.h - 1.1 linux/arch/i386/mach-generic/entry_arch.h - 1.1 linux/arch/i386/mach-generic/irq_vectors.h - 1.1 linux/arch/i386/mach-generic/setup.c - 1.1 linux/arch/i386/mach-generic/setup_arch_post.h - 1.1 linux/arch/i386/mach-generic/setup_arch_pre.h - 1.1 linux/arch/i386/mach-generic/smpboot_hooks.h - 1.1 linux/arch/i386/mach-visws/Makefile - 1.1 linux/arch/i386/mach-visws/do_timer.h - 1.1 linux/arch/i386/mach-visws/entry_arch.h - 1.1 linux/arch/i386/mach-visws/setup_arch_post.h - 1.1 linux/arch/i386/mach-visws/mpparse.c - 1.1 linux/arch/i386/mach-visws/pci-visws.c - 1.1 linux/arch/i386/mach-visws/setup.c - 1.1 linux/net/bridge/netfilter/Config.in - 1.1 linux/arch/i386/mach-visws/setup_arch_pre.h - 1.1 linux/drivers/base/platform.c - 1.1 linux/drivers/acpi/event.c - 1.1 linux/arch/i386/mach-visws/visws_apic.c - 1.1 linux/net/bridge/netfilter/ebt_dnat.c - 1.1 linux/net/bridge/netfilter/ebt_arp.c - 1.1 linux/arch/ppc/boot/of1275/Makefile - 1.1 linux/net/ax25/TODO - 1.1 linux/net/bridge/netfilter/Makefile - 1.1 linux/arch/ppc/boot/of1275/claim.c - 1.1 linux/arch/ppc/boot/of1275/enter.c - 1.1 linux/include/linux/pid.h - 1.1 linux/arch/ppc/boot/of1275/exit.c - 1.1 linux/arch/ppc/boot/of1275/finddevice.c - 1.1 linux/mm/madvise.c - 1.1 linux/net/bridge/netfilter/Config.help - 1.1 linux/include/asm-ppc64/ppc_asm.h - 1.1 linux/drivers/acpi/scan.c - 1.1 linux/arch/ppc64/mm/numa.c - 1.1 linux/arch/ppc/boot/openfirmware/start.c - 1.1 linux/arch/ppc/boot/openfirmware/newworldmain.c - 1.1 linux/arch/ppc/boot/openfirmware/misc.S - 1.1 linux/include/asm-ppc64/numnodes.h - 1.1 linux/arch/ppc/boot/openfirmware/common.c - 1.1 linux/arch/ppc/boot/of1275/ofstdio.c - 1.1 linux/arch/ppc/boot/openfirmware/coffmain.c - 1.1 linux/arch/ppc/boot/openfirmware/chrpmain.c - 1.1 linux/arch/ppc/boot/openfirmware/Makefile - 1.1 linux/arch/ppc/boot/of1275/write.c - 1.1 linux/arch/ppc/boot/of1275/release.c - 1.1 linux/arch/ppc/boot/of1275/read.c - 1.1 linux/net/sunrpc/xprt.c - 1.33 linux/net/sunrpc/svcsock.c - 1.22 linux/net/sunrpc/svcauth.c - 1.5 linux/net/sunrpc/svc.c - 1.13 linux/net/sunrpc/clnt.c - 1.22 linux/net/sunrpc/auth_unix.c - 1.8 linux/net/sunrpc/auth_null.c - 1.8 linux/net/sunrpc/auth.c - 1.11 linux/net/rose/sysctl_net_rose.c - 1.4 linux/net/rose/rose_timer.c - 1.7 linux/net/rose/rose_subr.c - 1.7 linux/net/rose/rose_route.c - 1.10 linux/net/rose/rose_out.c - 1.6 linux/net/rose/rose_loopback.c - 1.6 linux/net/rose/rose_link.c - 1.8 linux/net/rose/rose_in.c - 1.6 linux/net/rose/rose_dev.c - 1.10 linux/net/rose/af_rose.c - 1.27 linux/net/netrom/sysctl_net_netrom.c - 1.4 linux/net/netrom/nr_timer.c - 1.7 linux/net/netrom/nr_subr.c - 1.6 linux/net/netrom/nr_route.c - 1.8 linux/net/netrom/nr_out.c - 1.6 linux/net/netrom/nr_loopback.c - 1.8 linux/net/netrom/nr_in.c - 1.5 linux/net/netrom/nr_dev.c - 1.9 linux/net/netrom/af_netrom.c - 1.26 linux/net/irda/irttp.c - 1.19 linux/net/irda/irqueue.c - 1.10 linux/net/irda/irlmp_frame.c - 1.12 linux/net/irda/irlmp_event.c - 1.18 linux/net/irda/irlmp.c - 1.21 linux/net/irda/irlap.c - 1.20 linux/net/irda/irlan/irlan_common.c - 1.19 linux/net/irda/irias_object.c - 1.14 linux/net/irda/iriap.c - 1.17 linux/net/irda/irda_device.c - 1.28 linux/net/irda/discovery.c - 1.8 linux/net/core/dev.c - 1.60 linux/net/bridge/br.c - 1.23 linux/net/bridge/Makefile - 1.6 linux/net/ax25/sysctl_net_ax25.c - 1.5 linux/net/ax25/ax25_uid.c - 1.7 linux/net/ax25/ax25_timer.c - 1.7 linux/net/ax25/ax25_subr.c - 1.8 linux/net/ax25/ax25_std_timer.c - 1.5 linux/net/ax25/ax25_std_subr.c - 1.4 linux/net/ax25/ax25_std_in.c - 1.5 linux/net/ax25/ax25_route.c - 1.8 linux/net/ax25/ax25_out.c - 1.8 linux/net/ax25/ax25_ip.c - 1.9 linux/net/ax25/ax25_in.c - 1.12 linux/net/ax25/ax25_iface.c - 1.5 linux/net/ax25/ax25_ds_timer.c - 1.6 linux/net/ax25/ax25_ds_subr.c - 1.5 linux/net/ax25/ax25_ds_in.c - 1.6 linux/net/ax25/ax25_dev.c - 1.5 linux/net/ax25/ax25_addr.c - 1.4 linux/net/ax25/af_ax25.c - 1.27 linux/net/ax25/Config.in - 1.6 linux/net/Makefile - 1.25 linux/net/Config.in - 1.28 linux/mm/vmscan.c - 1.113 linux/mm/swapfile.c - 1.64 linux/mm/swap_state.c - 1.49 linux/mm/swap.c - 1.26 linux/mm/slab.c - 1.40 linux/mm/page_io.c - 1.30 linux/mm/page_alloc.c - 1.92 linux/mm/mremap.c - 1.34 linux/mm/mprotect.c - 1.33 linux/mm/mmap.c - 1.60 linux/mm/mlock.c - 1.16 linux/mm/memory.c - 1.92 linux/mm/filemap.c - 1.135 linux/mm/Makefile - 1.17 linux/kernel/sysctl.c - 1.58 linux/kernel/sys.c - 1.40 linux/kernel/signal.c - 1.41 linux/kernel/printk.c - 1.24 linux/kernel/ksyms.c - 1.165 linux/kernel/fork.c - 1.70 linux/kernel/exit.c - 1.55 linux/kernel/Makefile - 1.34 linux/ipc/Makefile - 1.4 linux/init/main.c - 1.91 linux/include/net/irda/w83977af_ir.h - 1.6 linux/include/net/irda/irtty.h - 1.9 linux/include/net/irda/irqueue.h - 1.8 linux/include/net/irda/irlmp.h - 1.14 linux/include/net/ax25.h - 1.9 linux/include/linux/wireless.h - 1.10 linux/include/linux/uio.h - 1.4 linux/include/linux/sysctl.h - 1.62 linux/include/linux/sunrpc/xprt.h - 1.15 linux/include/linux/sunrpc/svcauth.h - 1.3 linux/include/linux/sunrpc/svc.h - 1.8 linux/include/linux/sunrpc/msg_prot.h - 1.3 linux/include/linux/sunrpc/clnt.h - 1.11 linux/include/linux/sunrpc/auth.h - 1.7 linux/include/linux/sched.h - 1.84 linux/include/linux/netdevice.h - 1.37 linux/include/linux/nbd.h - 1.16 linux/include/linux/mm.h - 1.101 linux/include/linux/lockd/lockd.h - 1.9 linux/include/linux/list.h - 1.19 linux/include/linux/fs.h - 1.191 linux/include/linux/cyclades.h - 1.8 linux/include/linux/blkdev.h - 1.69 linux/include/asm-sparc64/unistd.h - 1.25 linux/include/asm-sparc64/system.h - 1.23 linux/include/asm-sparc64/page.h - 1.19 linux/include/asm-sparc/unistd.h - 1.23 linux/include/asm-sparc/io.h - 1.11 linux/include/asm-ppc/vga.h - 1.8 linux/include/asm-ppc/user.h - 1.5 linux/include/asm-ppc/unistd.h - 1.26 linux/include/asm-ppc/unaligned.h - 1.5 linux/include/asm-ppc/ucontext.h - 1.5 linux/include/asm-ppc/uaccess.h - 1.12 linux/include/asm-ppc/types.h - 1.12 linux/include/asm-ppc/traps.h - 1.4 linux/include/asm-ppc/timex.h - 1.7 linux/include/asm-ppc/termios.h - 1.9 linux/include/asm-ppc/termbits.h - 1.6 linux/include/asm-ppc/system.h - 1.25 linux/include/asm-ppc/string.h - 1.6 linux/include/asm-ppc/statfs.h - 1.4 linux/include/asm-ppc/stat.h - 1.8 linux/include/asm-ppc/spinlock.h - 1.17 linux/include/asm-ppc/softirq.h - 1.17 linux/include/asm-ppc/sockios.h - 1.4 linux/include/asm-ppc/socket.h - 1.9 linux/include/asm-ppc/smp.h - 1.18 linux/include/asm-ppc/signal.h - 1.6 linux/include/asm-ppc/siginfo.h - 1.11 linux/include/asm-ppc/sigcontext.h - 1.4 linux/include/asm-ppc/shmparam.h - 1.6 linux/include/asm-ppc/setup.h - 1.5 linux/include/asm-ppc/serial.h - 1.13 linux/include/asm-ppc/semaphore.h - 1.10 linux/include/asm-ppc/segment.h - 1.5 linux/include/asm-ppc/scatterlist.h - 1.9 linux/include/asm-ppc/resource.h - 1.10 linux/include/asm-ppc/residual.h - 1.6 linux/include/asm-ppc/raven.h - 1.6 linux/include/asm-ppc/ptrace.h - 1.11 linux/include/asm-ppc/prom.h - 1.15 linux/include/asm-ppc/processor.h - 1.35 linux/include/asm-ppc/prep_nvram.h - 1.6 linux/include/asm-ppc/posix_types.h - 1.9 linux/include/asm-ppc/poll.h - 1.4 linux/include/asm-ppc/pnp.h - 1.5 linux/include/asm-ppc/pgtable.h - 1.39 linux/include/asm-ppc/pci-bridge.h - 1.11 linux/include/asm-ppc/param.h - 1.7 linux/include/asm-ppc/page.h - 1.17 linux/include/asm-ppc/ohare.h - 1.7 linux/include/asm-ppc/nvram.h - 1.7 linux/include/asm-ppc/namei.h - 1.6 linux/include/asm-ppc/mmu_context.h - 1.15 linux/include/asm-ppc/mmu.h - 1.11 linux/include/asm-ppc/mman.h - 1.8 linux/include/asm-ppc/mk48t59.h - 1.4 linux/include/asm-ppc/mediabay.h - 1.8 linux/include/asm-ppc/md.h - 1.5 linux/include/asm-ppc/machdep.h - 1.25 linux/include/asm-ppc/linux_logo.h - 1.9 linux/include/asm-ppc/kgdb.h - 1.6 linux/include/asm-ppc/irq.h - 1.17 linux/include/asm-ppc/ipc.h - 1.4 linux/include/asm-ppc/ioctls.h - 1.5 linux/include/asm-ppc/ioctl.h - 1.4 linux/include/asm-ppc/io.h - 1.19 linux/include/asm-ppc/ide.h - 1.22 linux/include/asm-ppc/hydra.h - 1.5 linux/include/asm-ppc/hardirq.h - 1.21 linux/include/asm-ppc/gg2.h - 1.5 linux/include/asm-ppc/floppy.h - 1.6 linux/include/asm-ppc/fcntl.h - 1.10 linux/include/asm-ppc/errno.h - 1.5 linux/include/asm-ppc/elf.h - 1.13 linux/include/asm-ppc/dma.h - 1.10 linux/include/asm-ppc/delay.h - 1.7 linux/include/asm-ppc/dbdma.h - 1.6 linux/include/asm-ppc/current.h - 1.5 linux/include/asm-ppc/checksum.h - 1.5 linux/include/asm-ppc/cache.h - 1.13 linux/include/asm-ppc/byteorder.h - 1.9 linux/include/asm-ppc/bugs.h - 1.4 linux/include/asm-ppc/bootx.h - 1.6 linux/include/asm-ppc/bootinfo.h - 1.11 linux/include/asm-ppc/bitops.h - 1.17 linux/include/asm-ppc/atomic.h - 1.12 linux/include/asm-ppc/amipcmcia.h - 1.5 linux/include/asm-ppc/amigayle.h - 1.5 linux/include/asm-ppc/amigappc.h - 1.6 linux/include/asm-ppc/amigaints.h - 1.7 linux/include/asm-ppc/amigahw.h - 1.6 linux/include/asm-ppc/a.out.h - 1.4 linux/include/asm-ppc/8xx_immap.h - 1.6 linux/include/asm-i386/page.h - 1.31 linux/include/asm-i386/irq.h - 1.7 linux/fs/smbfs/proc.c - 1.22 linux/fs/smbfs/inode.c - 1.40 linux/fs/smbfs/file.c - 1.33 linux/fs/smbfs/dir.c - 1.24 linux/fs/read_write.c - 1.25 linux/fs/proc/array.c - 1.48 linux/fs/pipe.c - 1.33 linux/fs/nfsd/nfssvc.c - 1.24 linux/fs/nfsd/nfscache.c - 1.11 linux/fs/nfs/nfs3xdr.c - 1.15 linux/fs/nfs/nfs2xdr.c - 1.18 linux/fs/nfs/inode.c - 1.53 linux/fs/namei.c - 1.61 linux/fs/fifo.c - 1.16 linux/fs/fcntl.c - 1.26 linux/fs/ext2/inode.c - 1.54 linux/fs/exec.c - 1.66 linux/fs/dquot.c - 1.60 linux/fs/devices.c - 1.21 linux/fs/buffer.c - 1.135 linux/fs/block_dev.c - 1.60 linux/fs/binfmt_script.c - 1.16 linux/fs/binfmt_misc.c - 1.26 linux/fs/binfmt_em86.c - 1.17 linux/fs/binfmt_elf.c - 1.47 linux/fs/binfmt_aout.c - 1.28 linux/fs/bad_inode.c - 1.14 linux/fs/Makefile - 1.69 linux/drivers/video/clgenfb.c - 1.29 linux/drivers/scsi/sg.c - 1.37 linux/drivers/scsi/sd.c - 1.69 linux/drivers/scsi/scsi_queue.c - 1.14 linux/drivers/scsi/scsi.h - 1.32 linux/drivers/scsi/scsi.c - 1.58 linux/drivers/scsi/Makefile - 1.39 linux/drivers/sbus/char/envctrl.c - 1.17 linux/drivers/sbus/char/Config.in - 1.10 linux/drivers/pci/proc.c - 1.30 linux/drivers/net/yellowfin.c - 1.33 linux/drivers/net/irda/w83977af_ir.c - 1.25 linux/drivers/net/irda/tekram.c - 1.10 linux/drivers/net/irda/irtty.c - 1.29 linux/drivers/net/irda/irport.c - 1.26 linux/drivers/net/irda/girbil.c - 1.12 linux/drivers/net/irda/actisys.c - 1.11 linux/drivers/net/hp100.c - 1.22 linux/drivers/net/epic100.c - 1.32 linux/drivers/net/eepro100.c - 1.49 linux/drivers/net/acenic.h - 1.21 linux/drivers/net/acenic.c - 1.42 linux/drivers/net/Makefile - 1.61 linux/drivers/net/Config.in - 1.65 linux/drivers/net/3c59x.c - 1.37 linux/drivers/net/3c509.c - 1.33 linux/drivers/char/tty_io.c - 1.52 linux/drivers/char/rtc.c - 1.31 linux/drivers/char/random.c - 1.30 linux/drivers/block/rd.c - 1.58 linux/drivers/block/loop.c - 1.65 linux/drivers/block/ll_rw_blk.c - 1.114 linux/drivers/block/floppy.c - 1.49 linux/arch/sparc64/prom/Makefile - 1.11 linux/arch/sparc64/mm/init.c - 1.50 linux/arch/sparc64/mm/fault.c - 1.24 linux/arch/sparc64/mm/Makefile - 1.9 linux/arch/sparc64/kernel/traps.c - 1.23 linux/arch/sparc64/kernel/systbls.S - 1.33 linux/arch/sparc64/kernel/sys_sparc.c - 1.26 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.48 linux/arch/sparc64/kernel/setup.c - 1.35 linux/arch/sparc64/defconfig - 1.76 linux/arch/sparc64/config.in - 1.61 linux/arch/sparc64/Makefile - 1.21 linux/arch/sparc/prom/Makefile - 1.6 linux/arch/sparc/mm/srmmu.c - 1.38 linux/arch/sparc/kernel/sparc_ksyms.c - 1.30 linux/arch/sparc/kernel/setup.c - 1.26 linux/arch/sparc/config.in - 1.44 linux/arch/sparc/Makefile - 1.15 linux/arch/ppc/mm/init.c - 1.45 linux/arch/ppc/mm/fault.c - 1.23 linux/arch/ppc/mm/extable.c - 1.6 linux/arch/ppc/mm/Makefile - 1.11 linux/arch/ppc/lib/string.S - 1.10 linux/arch/ppc/lib/strcase.c - 1.4 linux/arch/ppc/lib/locks.c - 1.13 linux/arch/ppc/lib/checksum.S - 1.8 linux/arch/ppc/lib/Makefile - 1.10 linux/arch/ppc/kernel/traps.c - 1.27 linux/arch/ppc/kernel/time.c - 1.22 linux/arch/ppc/kernel/syscalls.c - 1.15 linux/arch/ppc/kernel/softemu8xx.c - 1.8 linux/arch/ppc/kernel/smp.c - 1.44 linux/arch/ppc/kernel/signal.c - 1.19 linux/arch/ppc/kernel/setup.c - 1.51 linux/arch/ppc/kernel/ptrace.c - 1.15 linux/arch/ppc/kernel/prom.c - 1.31 linux/arch/ppc/kernel/process.c - 1.43 linux/arch/ppc/kernel/prep_nvram.c - 1.11 linux/arch/ppc/kernel/ppc_ksyms.c - 1.50 linux/arch/ppc/kernel/ppc_htab.c - 1.20 linux/arch/ppc/kernel/ppc8xx_pic.h - 1.7 linux/arch/ppc/kernel/ppc8xx_pic.c - 1.10 linux/arch/ppc/kernel/ppc-stub.c - 1.11 linux/arch/ppc/kernel/pci.c - 1.30 linux/arch/ppc/kernel/open_pic.c - 1.29 linux/arch/ppc/kernel/mk_defs.c - 1.19 linux/arch/ppc/kernel/misc.S - 1.47 linux/arch/ppc/kernel/irq.c - 1.40 linux/arch/ppc/kernel/indirect_pci.c - 1.9 linux/arch/ppc/kernel/idle.c - 1.26 linux/arch/ppc/kernel/i8259.c - 1.13 linux/arch/ppc/kernel/head.S - 1.35 linux/arch/ppc/kernel/find_name.c - 1.4 linux/arch/ppc/kernel/bitops.c - 1.6 linux/arch/ppc/kernel/align.c - 1.11 linux/arch/ppc/kernel/Makefile - 1.31 linux/arch/ppc/config.in - 1.59 linux/arch/ppc/boot/Makefile - 1.18 linux/arch/ppc/amiga/time.c - 1.6 linux/arch/ppc/amiga/ints.c - 1.8 linux/arch/ppc/amiga/config.c - 1.20 linux/arch/ppc/amiga/cia.c - 1.8 linux/arch/ppc/amiga/chipram.c - 1.6 linux/arch/ppc/amiga/bootinfo.c - 1.6 linux/arch/ppc/amiga/amisound.c - 1.4 linux/arch/ppc/amiga/amiints.c - 1.13 linux/arch/ppc/amiga/amiga_ksyms.c - 1.4 linux/arch/ppc/amiga/Makefile - 1.9 linux/arch/ppc/Makefile - 1.28 linux/arch/ppc/8xx_io/uart.c - 1.23 linux/arch/ppc/8xx_io/fec.c - 1.18 linux/arch/ppc/8xx_io/enet.c - 1.18 linux/arch/ppc/8xx_io/commproc.c - 1.13 linux/arch/ppc/8xx_io/Makefile - 1.9 linux/arch/mips/Makefile - 1.14 linux/arch/i386/mm/init.c - 1.43 linux/arch/i386/mm/Makefile - 1.10 linux/arch/i386/math-emu/Makefile - 1.8 linux/arch/i386/lib/checksum.S - 1.6 linux/arch/i386/kernel/visws_apic.c - 1.10 linux/arch/i386/kernel/traps.c - 1.60 linux/arch/i386/kernel/time.c - 1.26 linux/arch/i386/kernel/setup.c - 1.83 linux/arch/i386/kernel/process.c - 1.56 linux/arch/i386/kernel/mca.c - 1.14 linux/arch/i386/kernel/io_apic.c - 1.45 linux/arch/i386/kernel/i386_ksyms.c - 1.55 linux/arch/i386/kernel/entry.S - 1.64 linux/arch/i386/kernel/Makefile - 1.35 linux/arch/i386/config.in - 1.91 linux/arch/i386/Makefile - 1.32 linux/Makefile - 1.218 linux/MAINTAINERS - 1.117 linux/Documentation/sysctl/vm.txt - 1.9 linux/include/net/irda/smc-ircc.h - 1.8 linux/include/linux/ide.h - 1.64 linux/include/asm-ppc/hdreg.h - 1.4 linux/drivers/net/irda/toshoboe.c - 1.30 linux/drivers/net/irda/smc-ircc.c - 1.26 linux/arch/ppc/xmon/xmon.c - 1.21 linux/arch/ppc/xmon/subr_prf.c - 1.5 linux/arch/ppc/xmon/start.c - 1.21 linux/arch/ppc/xmon/setjmp.c - 1.3 linux/arch/ppc/xmon/privinst.h - 1.5 linux/arch/ppc/xmon/ppc.h - 1.3 linux/arch/ppc/xmon/ppc-opc.c - 1.4 linux/arch/ppc/xmon/ppc-dis.c - 1.3 linux/arch/ppc/xmon/nonstdio.h - 1.4 linux/arch/ppc/xmon/ansidecl.h - 1.3 linux/arch/ppc/xmon/adb.c - 1.3 linux/arch/ppc/xmon/Makefile - 1.6 linux/arch/mips/dec/prom/Makefile - 1.7 linux/arch/mips/baget/prom/Makefile - 1.5 linux/arch/mips/arc/Makefile - 1.6 linux/drivers/block/cpqarray.c - 1.55 linux/include/linux/threads.h - 1.6 linux/drivers/char/raw.c - 1.29 linux/drivers/net/ppp_generic.c - 1.31 linux/arch/i386/kernel/i8259.c - 1.33 linux/arch/ppc/math-emu/fdivs.c - 1.3 linux/arch/ppc/math-emu/fdiv.c - 1.3 linux/arch/ppc/math-emu/fctiwz.c - 1.3 linux/arch/ppc/math-emu/fctiw.c - 1.3 linux/arch/ppc/math-emu/fcmpu.c - 1.3 linux/arch/ppc/math-emu/fcmpo.c - 1.3 linux/arch/ppc/math-emu/fadds.c - 1.3 linux/arch/ppc/math-emu/fadd.c - 1.3 linux/arch/ppc/math-emu/fabs.c - 1.3 linux/arch/ppc/math-emu/double.h - 1.3 linux/arch/ppc/math-emu/Makefile - 1.4 linux/arch/ppc/kernel/semaphore.c - 1.8 linux/arch/ppc/kernel/head_8xx.S - 1.18 linux/arch/ppc/kernel/entry.S - 1.29 linux/drivers/block/DAC960.c - 1.54 linux/arch/ppc/math-emu/udivmodti4.c - 1.3 linux/arch/ppc/math-emu/types.c - 1.3 linux/arch/ppc/math-emu/stfs.c - 1.3 linux/arch/ppc/math-emu/stfiwx.c - 1.3 linux/arch/ppc/math-emu/stfd.c - 1.3 linux/arch/ppc/math-emu/soft-fp.h - 1.3 linux/arch/ppc/math-emu/single.h - 1.3 linux/arch/ppc/math-emu/sfp-machine.h - 1.4 linux/arch/ppc/math-emu/op-common.h - 1.3 linux/arch/ppc/math-emu/op-4.h - 1.4 linux/arch/ppc/math-emu/op-2.h - 1.3 linux/arch/ppc/math-emu/op-1.h - 1.3 linux/arch/ppc/math-emu/mtfsfi.c - 1.3 linux/arch/ppc/math-emu/mtfsf.c - 1.3 linux/arch/ppc/math-emu/mtfsb1.c - 1.3 linux/arch/ppc/math-emu/mtfsb0.c - 1.3 linux/arch/ppc/math-emu/mffs.c - 1.3 linux/arch/ppc/math-emu/mcrfs.c - 1.3 linux/arch/ppc/math-emu/math.c - 1.4 linux/arch/ppc/math-emu/lfs.c - 1.3 linux/arch/ppc/math-emu/lfd.c - 1.3 linux/arch/ppc/math-emu/fsubs.c - 1.3 linux/arch/ppc/math-emu/fsub.c - 1.3 linux/arch/ppc/math-emu/fsqrts.c - 1.3 linux/arch/ppc/math-emu/fsqrt.c - 1.3 linux/arch/ppc/math-emu/fsel.c - 1.3 linux/arch/ppc/math-emu/frsqrte.c - 1.3 linux/arch/ppc/math-emu/frsp.c - 1.3 linux/arch/ppc/math-emu/fres.c - 1.3 linux/arch/ppc/math-emu/fnmsubs.c - 1.3 linux/arch/ppc/math-emu/fnmsub.c - 1.3 linux/arch/ppc/math-emu/fnmadds.c - 1.3 linux/arch/ppc/math-emu/fnmadd.c - 1.3 linux/arch/ppc/math-emu/fneg.c - 1.3 linux/arch/ppc/math-emu/fnabs.c - 1.3 linux/arch/ppc/math-emu/fmuls.c - 1.3 linux/arch/ppc/math-emu/fmul.c - 1.3 linux/arch/ppc/math-emu/fmsubs.c - 1.3 linux/arch/ppc/math-emu/fmsub.c - 1.3 linux/arch/ppc/math-emu/fmr.c - 1.3 linux/arch/ppc/math-emu/fmadds.c - 1.3 linux/arch/ppc/math-emu/fmadd.c - 1.3 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.10 linux/net/irda/ircomm/ircomm_tty.c - 1.21 linux/net/irda/ircomm/ircomm_param.c - 1.9 linux/net/irda/ircomm/ircomm_lmp.c - 1.7 linux/net/irda/ircomm/ircomm_core.c - 1.16 linux/include/net/irda/ircomm_tty.h - 1.10 linux/include/asm-ppc/m48t35.h - 1.4 linux/include/asm-ppc/pci.h - 1.17 linux/drivers/net/pcmcia/pcnet_cs.c - 1.20 linux/include/linux/acpi.h - 1.29 linux/Documentation/filesystems/proc.txt - 1.10 linux/arch/ppc/kernel/qspan_pci.c - 1.7 linux/arch/ppc/kernel/m8xx_setup.c - 1.25 linux/arch/ppc/amiga/pcmcia.c - 1.3 linux/arch/i386/kernel/smpboot.c - 1.47 linux/include/asm-ppc/bseip.h - 1.4 linux/include/asm-ppc/mpc8xx.h - 1.9 linux/mm/highmem.c - 1.43 linux/fs/proc/proc_misc.c - 1.42 linux/include/asm-ppc/div64.h - 1.3 linux/include/asm-ppc/pgalloc.h - 1.13 linux/arch/ppc/mm/mem_pieces.h - 1.4 linux/arch/ppc/mm/mem_pieces.c - 1.7 linux/mm/numa.c - 1.13 linux/include/linux/mmzone.h - 1.27 linux/drivers/scsi/scsi_lib.c - 1.49 linux/drivers/i2c/i2c-philips-par.c - 1.8 linux/arch/i386/kernel/acpi.c - 1.30 linux/include/asm-ppc/hw_irq.h - 1.10 linux/arch/i386/kernel/apic.c - 1.34 linux/arch/i386/kernel/mpparse.c - 1.25 linux/drivers/ieee1394/Makefile - 1.16 linux/include/asm-ppc/shmbuf.h - 1.4 linux/include/asm-ppc/sembuf.h - 1.4 linux/include/asm-ppc/msgbuf.h - 1.4 linux/include/asm-ppc/ipcbuf.h - 1.4 linux/include/asm-i386/mpspec.h - 1.10 linux/drivers/net/irda/nsc-ircc.c - 1.23 linux/arch/ppc/kernel/pci-dma.c - 1.5 linux/include/asm-ppc/heathrow.h - 1.8 linux/drivers/net/8139too.c - 1.43 linux/net/bridge/br_forward.c - 1.6 linux/include/linux/if_bridge.h - 1.2 linux/net/bridge/br_private.h - 1.8 linux/net/bridge/br_input.c - 1.11 linux/drivers/net/tulip/tulip_core.c - 1.42 linux/drivers/net/tulip/tulip.h - 1.16 linux/drivers/net/tulip/interrupt.c - 1.16 linux/drivers/net/tulip/eeprom.c - 1.13 linux/include/asm-mips64/pgtable.h - 1.16 linux/include/asm-mips64/mmzone.h - 1.9 linux/arch/mips64/sgi-ip22/Makefile - 1.6 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.11 linux/arch/mips64/Makefile - 1.14 linux/arch/mips64/arc/Makefile - 1.6 linux/drivers/ide/ide.c - 1.67 linux/drivers/ide/ide-proc.c - 1.23 linux/drivers/ide/ide-probe.c - 1.38 linux/drivers/ide/ide-dma.c - 1.31 linux/drivers/ide/Makefile - 1.30 linux/drivers/usb/serial/visor.c - 1.40 linux/include/asm-ppc/mpc8260.h - 1.5 linux/include/asm-ppc/immap_8260.h - 1.6 linux/include/asm-ppc/cpm_8260.h - 1.7 linux/arch/ppc/xmon/start_8xx.c - 1.4 linux/arch/ppc/kernel/ppc8260_pic.h - 1.4 linux/arch/ppc/kernel/ppc8260_pic.c - 1.6 linux/arch/ppc/kernel/m8260_setup.c - 1.16 linux/arch/ppc/8260_io/uart.c - 1.13 linux/arch/ppc/8260_io/enet.c - 1.9 linux/arch/ppc/8260_io/commproc.c - 1.5 linux/arch/ppc/8260_io/Makefile - 1.5 linux/drivers/s390/net/iucv.c - 1.10 linux/arch/i386/kdb/Makefile - 1.11 linux/include/asm-ppc/backlight.h - 1.5 linux/include/asm-ppc/mc146818rtc.h - 1.4 linux/include/asm-ppc/time.h - 1.11 linux/drivers/acpi/tables/tbget.c - 1.13 linux/drivers/acpi/tables.c - 1.7 linux/drivers/acpi/resources/rsdump.c - 1.11 linux/drivers/acpi/parser/psxface.c - 1.12 linux/drivers/acpi/namespace/nsload.c - 1.13 linux/drivers/acpi/include/actypes.h - 1.14 linux/drivers/acpi/include/acpiosxf.h - 1.12 linux/drivers/acpi/include/acexcep.h - 1.10 linux/drivers/acpi/ec.c - 1.11 linux/drivers/acpi/dispatcher/dswload.c - 1.15 linux/drivers/acpi/dispatcher/dsobject.c - 1.16 linux/drivers/acpi/dispatcher/dsfield.c - 1.10 linux/drivers/acpi/Makefile - 1.19 linux/drivers/net/tun.c - 1.17 linux/kernel/user.c - 1.6 linux/drivers/net/natsemi.c - 1.23 linux/drivers/md/raid1.c - 1.25 linux/drivers/md/raid5.c - 1.34 linux/arch/ppc/8260_io/fcc_enet.c - 1.6 linux/drivers/acpi/include/acconfig.h - 1.17 linux/drivers/acpi/include/acdebug.h - 1.13 linux/drivers/acpi/include/acinterp.h - 1.12 linux/drivers/acpi/namespace/nsdump.c - 1.11 linux/drivers/block/cciss.c - 1.42 linux/drivers/md/linear.c - 1.13 linux/drivers/md/md.c - 1.55 linux/drivers/md/raid0.c - 1.12 linux/drivers/net/sundance.c - 1.18 linux/include/asm-ppc/highmem.h - 1.11 linux/include/asm-ppc/keylargo.h - 1.6 linux/include/asm-ppc/kmap_types.h - 1.12 linux/include/asm-ppc/uninorth.h - 1.6 linux/drivers/net/tulip/ChangeLog - 1.15 linux/net/irda/irsyms.c - 1.7 linux/include/asm-ppc/module.h - 1.4 linux/include/asm-ppc/xor.h - 1.3 linux/drivers/net/lasi_82596.c - 1.11 linux/mm/shmem.c - 1.46 linux/drivers/acpi/power.c - 1.7 linux/include/asm-ppc/parport.h - 1.3 linux/drivers/acpi/acpi_ksyms.c - 1.11 linux/arch/ppc/kernel/open_pic_defs.h - 1.6 linux/drivers/net/pci-skeleton.c - 1.13 linux/include/linux/hdlc.h - 1.4 l