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