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

 

------=_NextPart_000_00A9_01C25374.E825D360-- ------=_NextPartTM-000-97e7ffa6-b4c0-11d6-ba7c-006067005148-- From owner-linux-xfs@oss.sgi.com Tue Sep 3 06:38:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 06:38:28 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83DcNtG024076 for ; Tue, 3 Sep 2002 06:38:23 -0700 Received: from dialup-63.214.121.72.dial1.boston1.level3.net ([63.214.121.72] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17mDwa-0006Ic-00 by VAauthid with fixed_plain; Tue, 03 Sep 2002 06:42:12 -0700 Message-ID: <3D74BC27.7080304@osdn.com> Date: Tue, 03 Sep 2002 09:41:59 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup References: <3D74023E.1010208@osdn.com> <20020903095458.A551@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs > > >The return cleanups make sense, that was inconsisten even inside XFS. >I'm not entirely sure wheter the int->uint stuff makes sense. Have >you seen differences in the generated assembly? > I'll leave out the int->uint stuff for now. If it's proved correct in the future, then I'll do it at that time. So you can disregard the previous patch and I'll make a new one without the int->uint changes in it. The return changes are easy to do with a script. Brian From owner-linux-xfs@oss.sgi.com Tue Sep 3 09:13:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 09:14:00 -0700 (PDT) Received: from imf10bis.bellsouth.net (mail110.mail.bellsouth.net [205.152.58.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83GDstG031416 for ; Tue, 3 Sep 2002 09:13:54 -0700 Received: from TAZ2 ([66.156.1.201]) by imf10bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020903161925.ZHTP11348.imf10bis.bellsouth.net@TAZ2>; Tue, 3 Sep 2002 12:19:25 -0400 Date: Tue, 3 Sep 2002 12:16:14 -0400 From: Greg Freemyer Subject: re[2]: snapshot regression test try 3 To: Ethan Benson , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020903161925.ZHTP11348.imf10bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g83GDstG031418 X-archive-position: 229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Ethan, That seems fair, I am putting together a small patch that will include this change. Greg >> On Fri, Aug 30, 2002 at 06:35:39PM -0400, Greg Freemyer wrote: >> > >> > if [ -e "$SCRATCH_SNAP_MNT" ]; then rm -rf "$SCRATCH_SNAP_MNT"; fi >> ummm is $SCRATCH_SNAP_MNT normally an empty mountpoint directory? if >> so please use rmdir and test its exit status (abort if rmdir fails) >> don't use rm -rf since you can't be certain there isn't something >> mounted there, or something stored there (shouldn't be but do you >> really want to chance it? rm -rf'ing data without warning is a good >> way to induce homicidal behavior) >> i recommend: >> if [ -e "$SCRATCH_SNAP_MNT" ]; then >> rmdir "$SCRATCH_SNAP_MNT" || exit 1 >> fi >> -- >> Ethan Benson >> http://www.alaska.net/~erbenson/ >> -- Attached file included as plaintext by Ecartis -- >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.0.6 (GNU/Linux) >> Comment: For info see http://www.gnupg.org >> iEYEARECAAYFAj1wdngACgkQJKx7GixEevxoBQCfahqAivVM3WJXGCKFdg/w1HE1 >> MQAAniwfD9n3fbY6G7PgTLe7/jp+L0NU >> =qMMo >> -----END PGP SIGNATURE----- Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Sep 3 09:42:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 09:42:25 -0700 (PDT) Received: from imf02bis.bellsouth.net (mail002.mail.bellsouth.net [205.152.58.22]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83GgItG032315 for ; Tue, 3 Sep 2002 09:42:19 -0700 Received: from TAZ2 ([66.156.1.201]) by imf02bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020903164750.KTVW8089.imf02bis.bellsouth.net@TAZ2>; Tue, 3 Sep 2002 12:47:50 -0400 Date: Tue, 3 Sep 2002 12:44:38 -0400 From: Greg Freemyer Subject: re: TAKE - snapshot QA To: Nathan Scott , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020903164750.KTVW8089.imf02bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g83GgJtG032317 X-archive-position: 230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs Nathan, I looked over the edits you made, and most of them are fine. I did find a couple small things wrong. Despite there small size, they keep the script from from running correctly. I also made a change recommended by Ethan. "cvs diff 068" output below (is that fine, or do you need a unified diff): Index: 068 =================================================================== RCS file: /cvs/linux-2.4-xfs/cmd/xfstests/068,v retrieving revision 1.2 diff -r1.2 068 49a50 > mkdir "$tmp" 106c107,110 < [ -e "$SCRATCH_SNAP_MNT" ] && rm -rf "$SCRATCH_SNAP_MNT" --- > if [ -e "$SCRATCH_SNAP_MNT" ]; then > rmdir "$SCRATCH_SNAP_MNT" || _notrun "$SCRATCH_SNAP_MNT should be removed prior to running." > fi > 158c162 < dd if=/dev/zero of=$SCRATCH_MNT/dummy bs=64k count=1000 >/dev/null 2>&1 --- > dd if=/dev/zero of="$SCRATCH_MNT/dummy" bs=64k count=1000 >/dev/null 2>&1 210d213 < fi =================================================================== Line 50: The mkdir is required because $tmp is now a directory to place temp files in, not a prefix to add an extent to. Line 107-110: The $SCRATCH_SNAP_MNT change is Ethan's request Line 162: Some missing quotes requested by Ethan that somehow were missed previously. Line 210: An extraneous 'fi' left over from an if statement you converted to boolean logic. (I don't know how to word this one.) Greg ======== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> Date: Sun Sep 1 18:39:23 PDT 2002 >> Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs >> The following file(s) were checked into: >> bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs >> Modid: 2.4.x-xfs:slinx:126546a >> linux/fs/xfs/xfs_vnodeops.c - 1.561 >> - remove local tmp variable "sync_mode" which was accidentally >> left in on previous checkin. >> Date: Sun Sep 1 23:04:01 PDT 2002 >> Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs >> The following file(s) were checked into: >> bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs >> Modid: xfs-cmds:slinx:126551a >> cmd/xfstests/068 - 1.1 >> cmd/xfstests/068.out - 1.1 >> - A LVM snapshot regression test by Greg Freemyer. >> cmd/xfstests/group - 1.23 >> - Add in Greg's snapshot test, 068. Also, added 067 back into the >> auto-qa mix, looks like it wasn't added back after being disabled. From owner-linux-xfs@oss.sgi.com Tue Sep 3 09:51:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 09:51:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83GoxtG000339 for ; Tue, 3 Sep 2002 09:51:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA80464 for ; Tue, 3 Sep 2002 11:54:53 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA29628 for ; Tue, 3 Sep 2002 11:54:53 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g83Gpwv04539; Tue, 3 Sep 2002 11:51:58 -0500 Message-Id: <200209031651.g83Gpwv04539@stout.americas.sgi.com> Date: Tue, 3 Sep 2002 11:51:58 -0500 Subject: TAKE - Allow xfs_db to write negative numbers X-archive-position: 231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Allow xfs_db to write negative numbers. "-1" is often a special value for inode numbers, etc, but xfs_db didn't allow you to write a negative number. Date: Tue Sep 3 09:53:43 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126585a cmd/xfsprogs/db/write.c - 1.6 cmd/xfsprogs/VERSION - 1.56 cmd/xfsprogs/doc/CHANGES - 1.81 From owner-linux-xfs@oss.sgi.com Tue Sep 3 12:56:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 12:56:20 -0700 (PDT) Received: from imf04bis.bellsouth.net (mail104.mail.bellsouth.net [205.152.58.44]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83JuEtG012622 for ; Tue, 3 Sep 2002 12:56:14 -0700 Received: from TAZ2 ([66.156.1.201]) by imf04bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020903200146.XJFZ26924.imf04bis.bellsouth.net@TAZ2> for ; Tue, 3 Sep 2002 16:01:46 -0400 Date: Tue, 3 Sep 2002 15:58:34 -0400 From: Greg Freemyer Subject: Snapshot Status To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020903200146.XJFZ26924.imf04bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g83JuFtG012632 X-archive-position: 232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs All, I have been using the new LVM snapshot regression test extensively over the last couple of business days. (xfstests/068 now in CVS) I have found that the only kernel that can reliable pass the test is an xfs cvs kernel as of today. (Steve Lord put in a fix over the weekend that seems to be the final piece in the puzzle.) I suggest anyone using LVM snapshots with XFS in a production environment should consider this information. Note: if you want to run the snapshot test on your platform, the current CVS version has a couple of small typos that I described in an e-mail earlier today. Hopefully Nathan will get those changes into CVS shortly. Note 2: The kernel lockup listed below has not been reported before by me, but it was apparently resolved by Steve's latest fix. ===== Results of my tests WIth no i/o load: Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) Succesfully ran 20 iterations XFS CVS Aug. 30 kernel Succesfully ran 20 iterations XFS CVS Sept. 2 kernel Succesfully ran 20 iterations WIth a dd based i/o load Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) lvcreate locks up within 20 iterations XFS CVS Aug. 30 kernel Succesfully ran 20 iterations XFS CVS Sept. 2 kernel Succesfully ran 20 iterations WIth a fsstress based i/o load Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) lvcreate locks up within 20 iterations XFS CVS Aug. 30 kernel Not tested XFS CVS Sept. 2 kernel Succesfully ran 20 iterations WIth both a dd and a fsstress based i/o load Kernel 2.4.19pre4aa1with SuSE patches (i.e. XFS 1.1 based) lvcreate locks up within 20 iterations XFS CVS Aug. 30 kernel Kernel locks up within 20 iterations XFS CVS Sept. 2 kernel Succesfully ran 20 iterations Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Sep 3 12:58:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 12:58:07 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83Jw4tG012835 for ; Tue, 3 Sep 2002 12:58:05 -0700 Received: (qmail 190 invoked by uid 500); 3 Sep 2002 20:01:22 -0000 Subject: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: linux-xfs@oss.sgi.com Cc: andrea@suse.de Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031083281.32386.21.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 15:01:22 -0500 X-archive-position: 233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB of disks FC2 disks. (14*69.87GB) I'm using LVM 1.0.3 and associated tools, as well as XFS as my FS of choice. I'm not sure what's happened recently, but after upgrading my disk subsystem to full FC2 (we were just FC2 to the switches before), when mounting any of the volumes on the StorageTek D178 subsystem, I get the following bug message. I was curious if I was hitting an XFS bug, or if it's because of the many LIP resets I get from the Qlogic Driver and the kernel got overflowed or XFS's mount got overflowed or something. Not sure, but it doesn't sound good. TIA scsi1: Topology - (FL_Port), Host Loop address 0x0 Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) kernel BUG at page_buf.c:602! invalid operand: 0000 2.4.19 #2 SMP Sun Aug 25 23:33:55 CDT 2002 CPU: 4 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 esi: c92d5180 edi: 00000001 ebp: 00000000 esp: c92e5720 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 1381, stackpage=c92e5000) Stack: c92d51e0 00000002 000001f0 c78eb28c c92e4000 00000000 00000000 000001f0 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 00000000 00002205 00000000 c01ffc76 c92d5180 c92e9934 00002205 00002000 00002205 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:05:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:05:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83K51tG013624 for ; Tue, 3 Sep 2002 13:05:01 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA83849; Tue, 3 Sep 2002 15:08:53 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-77.corp.sgi.com [134.15.64.77]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA84486; Tue, 3 Sep 2002 15:08:52 -0500 (CDT) Subject: Re: Kernel Opps/panic with 2.4.19 From: Stephen Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031083281.32386.21.camel@UberGeek.coremetrics.com> References: <1031083281.32386.21.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Sep 2002 15:07:26 -0500 Message-Id: <1031083648.1077.70.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB of > disks FC2 disks. (14*69.87GB) > > I'm using LVM 1.0.3 and associated tools, as well as XFS as my FS of > choice. I'm not sure what's happened recently, but after upgrading my > disk subsystem to full FC2 (we were just FC2 to the switches before), > when mounting any of the volumes on the StorageTek D178 subsystem, I get > the following bug message. > > I was curious if I was hitting an XFS bug, or if it's because of the > many LIP resets I get from the Qlogic Driver and the kernel got > overflowed or XFS's mount got overflowed or something. Not sure, but it > doesn't sound good. TIA > > scsi1: Topology - (FL_Port), Host Loop address 0x0 > Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) > kernel BUG at page_buf.c:602! > invalid operand: 0000 2.4.19 #2 SMP Sun Aug 25 23:33:55 CDT 2002 > CPU: 4 > EIP: 0010:[] Not tainted > EFLAGS: 00010246 > eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 > esi: c92d5180 edi: 00000001 ebp: 00000000 esp: c92e5720 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 1381, stackpage=c92e5000) > Stack: c92d51e0 00000002 000001f0 c78eb28c c92e4000 00000000 00000000 > 000001f0 > 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 > 00000000 > 00002205 00000000 c01ffc76 c92d5180 c92e9934 00002205 00002000 > 00002205 > Call Trace: [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] [] > [] [] [] [] > Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 A decoded version of that would help.... Steve > > -- > Austin Gonyou > Coremetrics, Inc. > From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:24:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:24:20 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83KOEtG014231 for ; Tue, 3 Sep 2002 13:24:14 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17mKHi-0001Gm-00 for linux-xfs@oss.sgi.com; Tue, 03 Sep 2002 14:28:26 -0600 Message-ID: <3D751B88.2040507@emergence.com> Date: Tue, 03 Sep 2002 14:28:56 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Kernel Opps/panic with 2.4.19 References: <1031083281.32386.21.camel@UberGeek.coremetrics.com> <1031083648.1077.70.camel@laptop.americas.sgi.com> X-Enigmail-Version: 0.65.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Stephen Lord wrote: > On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > >>I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB of >>disks FC2 disks. (14*69.87GB) Which patch is this? Mainly just out of curiousity. Alan Cox patch-2.4.19-rc5-ac1.gz + XFS? -Mike From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:40:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:41:01 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83KewtG014822 for ; Tue, 3 Sep 2002 13:40:59 -0700 Received: (qmail 818 invoked by uid 500); 3 Sep 2002 20:44:19 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Michael Best Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D751B88.2040507@emergence.com> References: <3D751B88.2040507@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031085859.32386.58.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 15:44:19 -0500 X-archive-position: 236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs No, -RC5-AA1. Andrea Arcangeli. On Tue, 2002-09-03 at 15:28, Michael Best wrote: > Stephen Lord wrote: > > On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > > > >>I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB > of > >>disks FC2 disks. (14*69.87GB) > > Which patch is this? Mainly just out of curiousity. > > Alan Cox patch-2.4.19-rc5-ac1.gz + XFS? > > -Mike -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 13:41:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 13:41:25 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83KfNtG014823 for ; Tue, 3 Sep 2002 13:41:24 -0700 Received: (qmail 827 invoked by uid 500); 3 Sep 2002 20:44:46 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031083648.1077.70.camel@laptop.americas.sgi.com> References: <1031083648.1077.70.camel@laptop.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031085885.32386.62.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 15:44:46 -0500 X-archive-position: 237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Will ksymoops work on this? On Tue, 2002-09-03 at 15:07, Stephen Lord wrote: > On Tue, 2002-09-03 at 15:01, Austin Gonyou wrote: > > I'm using 2.4.19-rc5-aa1 patch on a standard 2.4.19 kernel with ~1TB > of > > disks FC2 disks. (14*69.87GB) > > > > I'm using LVM 1.0.3 and associated tools, as well as XFS as my FS of > > choice. I'm not sure what's happened recently, but after upgrading > my > > disk subsystem to full FC2 (we were just FC2 to the switches > before), > > when mounting any of the volumes on the StorageTek D178 subsystem, I > get > > the following bug message. > > > > I was curious if I was hitting an XFS bug, or if it's because of the > > many LIP resets I get from the Qlogic Driver and the kernel got > > overflowed or XFS's mount got overflowed or something. Not sure, but > it > > doesn't sound good. TIA > > > > scsi1: Topology - (FL_Port), Host Loop address 0x0 > > Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) > > kernel BUG at page_buf.c:602! > > invalid operand: 0000 2.4.19 #2 SMP Sun Aug 25 23:33:55 CDT 2002 > > CPU: 4 > > EIP: 0010:[] Not tainted > > EFLAGS: 00010246 > > eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 > > esi: c92d5180 edi: 00000001 ebp: 00000000 esp: c92e5720 > > ds: 0018 es: 0018 ss: 0018 > > Process mount (pid: 1381, stackpage=c92e5000) > > Stack: c92d51e0 00000002 000001f0 c78eb28c c92e4000 00000000 > 00000000 > > 000001f0 > > 00000000 00000001 0010000c 00000002 00000000 00000002 > 00800050 > > 00000000 > > 00002205 00000000 c01ffc76 c92d5180 c92e9934 00002205 > 00002000 > > 00002205 > > Call Trace: [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] [] > > [] [] [] [] > > Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 > > A decoded version of that would help.... > > Steve > > > > > -- > > Austin Gonyou > > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 14:21:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 14:21:43 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83LLZtG016117 for ; Tue, 3 Sep 2002 14:21:35 -0700 Received: (qmail 1337 invoked by uid 500); 3 Sep 2002 21:25:01 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031083648.1077.70.camel@laptop.americas.sgi.com> References: <1031083648.1077.70.camel@laptop.americas.sgi.com> Content-Type: multipart/mixed; boundary="=-6Am2j39O1Ob7YdPBVNPV" Organization: Coremetrics, Inc. Message-Id: <1031088301.32386.92.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 16:25:01 -0500 X-archive-position: 238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs --=-6Am2j39O1Ob7YdPBVNPV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok, I guess ksymoops will do that. I only had used it for just plain *oopses* before. Sorry about my ignorance.=20 Attatched is the output.=20 =20 --=20 Austin Gonyou Coremetrics, Inc. --=-6Am2j39O1Ob7YdPBVNPV Content-Disposition: attachment; filename=2.4.19-xfs-ksymoops-prod5.txt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=2.4.19-xfs-ksymoops-prod5.txt; charset=ISO-8859-1 kernel BUG at page_buf.c:602! invalid operand: 0000 2.4.19 #2 SMP Mon Aug 26 02:32:04 CDT 2002 CPU: 2 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 esi: c8e7d780 edi: 00000001 ebp: 00000000 esp: d4245720 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 5264, stackpage=3Dd4245000) Stack: c8e7d7e0 00000002 000001f0 c7878864 d4244000 00000000 00000000 00000= 1f0 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 00000= 000 00002205 00000000 c01ffc76 c8e7d780 d3e76db4 00002205 00002000 00002= 205 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] = [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 kernel BUG at page_buf.c:602! invalid operand: 0000 2.4.19 #2 SMP Mon Aug 26 02:32:04 CDT 2002 CPU: 2 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000002 ecx: 00080221 edx: 00000000 esi: c8e7d780 edi: 00000001 ebp: 00000000 esp: d4245720 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 5264, stackpage=3Dd4245000) Stack: c8e7d7e0 00000002 000001f0 c7878864 d4244000 00000000 00000000 00000= 1f0 00000000 00000001 0010000c 00000002 00000000 00000002 00800050 00000= 000 00002205 00000000 c01ffc76 c8e7d780 d3e76db4 00002205 00002000 00002= 205 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [<= c0165780>] [] [] [] Code: 0f 0b 5a 02 a0 4e 2f c0 8b 4c 24 4c 8b 51 58 81 49 08 04 00 >>EIP; c01ff6e4 <_pagebuf_lookup_pages+124/430> <=3D=3D=3D=3D=3D Trace; c01ffc76 Trace; c01e68c7 Trace; c01e7854 Trace; c01e5d97 Trace; c01e792f Trace; c01e7a3e Trace; c01e8544 Trace; c01e89d3 Trace; c01e8a3b Trace; c01e8c53 Trace; c01e13b4 Trace; c01ea0bc Trace; c0201a3c <.text.lock.page_buf+83/127> Trace; c01e95b4 Trace; c01e980b Trace; c01f36be Trace; c01f392f Trace; c01f3977 Trace; c020c753 Trace; c013ed95 <__alloc_pages+65/280> Trace; c01352b5 Trace; c013d02f Trace; c012f57d Trace; c014dd2a Trace; c014e7ac Trace; c014dc7b Trace; c014eb8c Trace; c01652e8 Trace; c0165780 Trace; c01655c9 Trace; c0165d3f Trace; c01095bb Code; c01ff6e4 <_pagebuf_lookup_pages+124/430> 00000000 <_EIP>: Code; c01ff6e4 <_pagebuf_lookup_pages+124/430> <=3D=3D=3D=3D=3D 0: 0f 0b ud2a <=3D=3D=3D=3D=3D Code; c01ff6e6 <_pagebuf_lookup_pages+126/430> 2: 5a pop %edx Code; c01ff6e7 <_pagebuf_lookup_pages+127/430> 3: 02 a0 4e 2f c0 8b add 0x8bc02f4e(%eax),%ah Code; c01ff6ed <_pagebuf_lookup_pages+12d/430> 9: 4c dec %esp Code; c01ff6ee <_pagebuf_lookup_pages+12e/430> a: 24 4c and $0x4c,%al Code; c01ff6f0 <_pagebuf_lookup_pages+130/430> c: 8b 51 58 mov 0x58(%ecx),%edx Code; c01ff6f3 <_pagebuf_lookup_pages+133/430> f: 81 49 08 04 00 00 00 orl $0x4,0x8(%ecx) --=-6Am2j39O1Ob7YdPBVNPV --=-6Am2j39O1Ob7YdPBVNPV-- From owner-linux-xfs@oss.sgi.com Tue Sep 3 14:31:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 14:31:28 -0700 (PDT) Received: from pop.andover.net (pop.andover.net [209.192.217.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83LVNtG016643 for ; Tue, 3 Sep 2002 14:31:23 -0700 Received: from Rodan.osdn.com (vpn-route.osdn.com [209.192.217.2]) by pop.andover.net (8.11.0/8.9.2) with ESMTP id g83LVOu02910 for ; Tue, 3 Sep 2002 17:31:25 -0400 Subject: Re: [PATCH] Kernel janitor cleanup From: Brian Pontz To: linux-xfs@oss.sgi.com In-Reply-To: <20020903095458.A551@infradead.org> References: <3D74023E.1010208@osdn.com> <20020903095458.A551@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 03 Sep 2002 17:35:18 -0400 Message-Id: <1031088918.14660.36.camel@Rodan.osdn.com> Mime-Version: 1.0 X-archive-position: 239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs http://www.axehind.com/xfs/xfs-cleanup-2-linux-2.4.patch return() cleanup partial patch. Brian On Tue, 2002-09-03 at 04:54, Christoph Hellwig wrote: > On Mon, Sep 02, 2002 at 08:28:46PM -0400, Brian Pontz wrote: > > http://www.axehind.com/xfs/xfs-cleanup-1-linux-2.4.patch > > > > The patch is mainly a partial janitor patch. > > The return cleanups make sense, that was inconsisten even inside XFS. > I'm not entirely sure wheter the int->uint stuff makes sense. Have > you seen differences in the generated assembly? > > The set_current_state patch is wrong, it adds another unnessecary test. > But that piece of code is rather wrong anyway and sets the states in > the wrong places. Using wait_event() cleans up the code more and gets > it right: > > > Index: fs/xfs/xfs_inode.c > =================================================================== > RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/xfs_inode.c,v > retrieving revision 1.348 > diff -u -p -r1.348 xfs_inode.c > --- fs/xfs/xfs_inode.c 2002/09/01 12:43:34 1.348 > +++ fs/xfs/xfs_inode.c 2002/09/03 08:49:50 > @@ -2579,7 +2579,6 @@ xfs_iunpin_wait( > { > xfs_inode_log_item_t *iip; > xfs_lsn_t lsn; > - DECLARE_WAITQUEUE(wait, current); > > ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE | MR_ACCESS)); > > @@ -2599,15 +2598,7 @@ xfs_iunpin_wait( > */ > xfs_log_force(ip->i_mount, lsn, XFS_LOG_FORCE); > > - add_wait_queue(&ip->i_ipin_wait, &wait); > -repeat: > - set_current_state(TASK_UNINTERRUPTIBLE); > - if (atomic_read(&ip->i_pincount)) { > - schedule(); > - goto repeat; > - } > - remove_wait_queue(&ip->i_ipin_wait, &wait); > - current->state = TASK_RUNNING; > + wait_event(ip->i_ipin_wait, (atomic_read(&ip->i_pincount) == 0)); > } > > From owner-linux-xfs@oss.sgi.com Tue Sep 3 15:00:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 15:00:41 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83M0ctG017238 for ; Tue, 3 Sep 2002 15:00:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA84805 for ; Tue, 3 Sep 2002 17:04:33 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA73700 for ; Tue, 3 Sep 2002 17:04:33 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g83M1aQ16043; Tue, 3 Sep 2002 17:01:36 -0500 Message-Id: <200209032201.g83M1aQ16043@stout.americas.sgi.com> Date: Tue, 3 Sep 2002 17:01:36 -0500 Subject: TAKE - add show_options sb method X-archive-position: 240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This adds a superblock method so that /proc/mounts will query the xfs mount structs, etc, and tell you what options are really set in the kernel. Currently /etc/mtab can get faked out and list options that didn't really get set. add show_options sb method Date: Tue Sep 3 15:03:09 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126637a linux/fs/xfs/linux/xfs_super.c - 1.210 From owner-linux-xfs@oss.sgi.com Tue Sep 3 15:21:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 15:21:35 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83MLTtG017917 for ; Tue, 3 Sep 2002 15:21:29 -0700 Received: (qmail 1885 invoked by uid 500); 3 Sep 2002 22:25:01 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031088301.32386.92.camel@UberGeek.coremetrics.com> References: <1031088301.32386.92.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031091900.32409.101.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 17:25:01 -0500 X-archive-position: 241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I seemed to have found that after running xfs_repair -L on a fs I knew I could lose the log for, I can now mount the volume properly. Is it because the -RC5-aa1 patch has old XFS code that this is happening? Should I upgrade my mount to support newer XFS code, and thusly, log replays? Please advise. This appears to be the only thing causing any problems on this system at this point. TIA! On Tue, 2002-09-03 at 16:25, Austin Gonyou wrote: > Ok, I guess ksymoops will do that. I only had used it for just plain > *oopses* before. Sorry about my ignorance. > > Attatched is the output. > > -- > Austin Gonyou > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 15:24:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 15:24:17 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g83MOCtG018398 for ; Tue, 3 Sep 2002 15:24:12 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA85153 for ; Tue, 3 Sep 2002 17:28:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA62386 for ; Tue, 3 Sep 2002 17:28:06 -0500 (CDT) Subject: Re: TAKE - add show_options sb method From: Eric Sandeen To: linux-xfs@oss.sgi.com In-Reply-To: <200209032201.g83M1aQ16043@stout.americas.sgi.com> References: <200209032201.g83M1aQ16043@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 03 Sep 2002 17:25:09 -0500 Message-Id: <1031091909.3162.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Oh, I should mention that this is xfs-specific mount options, "generic" vfs mount options already show up in /proc/mounts. On Tue, 2002-09-03 at 17:01, Eric Sandeen wrote: > This adds a superblock method so that /proc/mounts will query the xfs > mount structs, etc, and tell you what options are really set in the kernel. > > Currently /etc/mtab can get faked out and list options that didn't > really get set. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Sep 3 18:58:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 18:58:57 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g841wqtG030340 for ; Tue, 3 Sep 2002 18:58:52 -0700 Received: (qmail 4377 invoked by uid 500); 4 Sep 2002 02:02:27 -0000 Subject: Re: Kernel Opps/panic with 2.4.19 From: Austin Gonyou To: Stephen Lord Cc: linux-xfs@oss.sgi.com, Andrea Arcangeli In-Reply-To: <1031088301.32386.92.camel@UberGeek.coremetrics.com> References: <1031088301.32386.92.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031104946.4344.1.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 03 Sep 2002 21:02:27 -0500 X-archive-position: 243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs I used the 2.4.19 xfs patch set with a stock 2.4.19 kernel, and get the same output as far as the oops is concerned. I can xfs_repair -L on the volumes and then mount them, but I'm not sure why I can't replay the journal at all, and then mount segfaults. Any ideas on what I can do, besides just xfs_repair -L, would be greatly appreciated. TIA On Tue, 2002-09-03 at 16:25, Austin Gonyou wrote: > Ok, I guess ksymoops will do that. I only had used it for just plain > *oopses* before. Sorry about my ignorance. > > Attatched is the output. > > -- > Austin Gonyou > Coremetrics, Inc. > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 3 19:18:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 19:18:54 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g842IqtG030981 for ; Tue, 3 Sep 2002 19:18:52 -0700 Received: from dialup-63.214.67.118.dial1.boston1.level3.net ([63.214.67.118] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17mPoh-00053a-00 by VAauthid with fixed_plain for ; Tue, 03 Sep 2002 19:22:52 -0700 Message-ID: <3D756E6A.30908@osdn.com> Date: Tue, 03 Sep 2002 22:22:34 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [PATCH] Kernel janitor cleanup References: <3D74023E.1010208@osdn.com> <20020903095458.A551@infradead.org> <1031088918.14660.36.camel@Rodan.osdn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs > > >http://www.axehind.com/xfs/xfs-cleanup-2-linux-2.4.patch > >return() cleanup partial patch. > >Brian > Next patch for the return() cleanup http://www.axehind.com/xfs/xfs-cleanup-3-linux-2.4.patch Brian From owner-linux-xfs@oss.sgi.com Tue Sep 3 21:21:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 21:21:26 -0700 (PDT) Received: from mail.aspec.ru (relay1.aspec.ru [217.14.198.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g844LJtG000346 for ; Tue, 3 Sep 2002 21:21:21 -0700 Received: from [192.168.22.111] (HELO belkam.com) by mail.aspec.ru (CommuniGate Pro SMTP 3.5.9) with ESMTP id 697553 for linux-xfs@oss.sgi.com; Wed, 04 Sep 2002 09:25:12 +0500 Message-ID: <3D758B28.9000406@belkam.com> Date: Wed, 04 Sep 2002 09:25:12 +0500 From: Dmitry Melekhov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: ru, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.19- xfs oops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@belkam.com Precedence: bulk X-list: linux-xfs Hello! We had our fileserver died this night. Sorry, I wrote down oops info by hands (so it is possible that there are mistypings) and I can't run ksymoops on 2.4.19, because we switched back to 2.4.18 for now, so most of warinings are skipped here. Hope, anyway, that this info can help. kernel BUG at filemap.c:843 invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: c11b388 ecx: 00000017 edx: c02f60f4 esi: c1580948 edi: cc5b6dc0 ebp: df0e9d40 esp: c4841e4c ds: 0018 es:0018 ss: 0018 Stack: ca0bce00 c11b9388 c01f41cd d4f6d6e0 00000246 00000001 ca0bce00 00000000 c11b9388 c01f4209 ca0bce00 00000001 00000001 c024ebae ca0bce00 00000001 d4f6d6e0 db7077a0 00000001 dfe6ae00 c034ecd0 d4f6d6e0 00000001 dfe6aeb8 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] code: 0f 0b 4b 03 00cb 2a c0 8d 46 04 39 46 04 74 0e 31 c9 ba 03 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops 0.7c on i686 2.4.18-xfs. Options used -v /usr/src/linux-2.4.19-xfs/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-xfs/ (specified) -m /usr/src/linux/System.map (default) Warning (compare_Version): Version mismatch. System.map says 2.4.19, e100 says 2.4.18. Expect lots of address mismatches. [skip] invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: c11b388 ecx: 00000017 edx: c02f60f4 esi: c1580948 edi: cc5b6dc0 ebp: df0e9d40 esp: c4841e4c ds: 0018 es:0018 ss: 0018 Stack: ca0bce00 c11b9388 c01f41cd d4f6d6e0 00000246 00000001 ca0bce00 00000000 c11b9388 c01f4209 ca0bce00 00000001 00000001 c024ebae ca0bce00 00000001 d4f6d6e0 db7077a0 00000001 dfe6ae00 c034ecd0 d4f6d6e0 00000001 dfe6aeb8 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] code: 0f 0b 4b 03 00cb 2a c0 8d 46 04 39 46 04 74 0e 31 c9 ba 03 >>EIP; e012420a <_end+1fda3506/205d735c> <===== Trace; c01f41cd <_end_pagebuf_page_io_multi+e5/110> Trace; c01f4209 <_end_io_multi_full+11/18> Trace; c024ebae Trace; c024ecd0 Trace; c023b738 <__scsi_end_request+74/130> Trace; c023ba96 Trace; c0240c58 Trace; c024529b Trace; c023ad86 Trace; c0243d91 Trace; c010996d Trace; c0109ad7 Trace; c010bd08 Code; e012420a <_end+1fda3506/205d735c> 00000000 <_EIP>: Code; e012420a <_end+1fda3506/205d735c> <===== 0: 0f 0b ud2a <===== Code; e012420c <_end+1fda3508/205d735c> 2: 4b dec %ebx Code; e012420d <_end+1fda3509/205d735c> 3: 03 cb add %ebx,%ecx Code; e012420f <_end+1fda350b/205d735c> 5: 00 2a add %ch,(%edx) Code; e0124211 <_end+1fda350d/205d735c> 7: c0 8d 46 04 39 46 04 rorb $0x4,0x46390446(%ebp) Code; e0124218 <_end+1fda3514/205d735c> e: 74 0e je 1e <_EIP+0x1e> e0124228 <_end+1fda3524/205d735c> Code; e012421a <_end+1fda3516/205d735c> 10: 31 c9 xor %ecx,%ecx Code; e012421c <_end+1fda3518/205d735c> 12: ba 03 00 00 00 mov $0x3,%edx <0>Kernel panic: Aiee, killing interrupt handler! 1167 warnings issued. Results may not be reliable. From owner-linux-xfs@oss.sgi.com Tue Sep 3 23:17:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 23:17:47 -0700 (PDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g846HftG003427 for ; Tue, 3 Sep 2002 23:17:41 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g846LaE26875 for ; Wed, 4 Sep 2002 15:21:36 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g846LZ512670 for ; Wed, 4 Sep 2002 15:21:35 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g846LZh02841 for ; Wed, 4 Sep 2002 15:21:35 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA513 for ; Wed, 4 Sep 2002 15:21:34 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Sep 04 15:21:33 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g846LXA62253 for ; Wed, 4 Sep 2002 15:21:33 +0900 (JST) Received: from TNES007145 (TNES007145.bsd.tnes.nec.co.jp [10.1.104.50]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g846LXY04157 for ; Wed, 4 Sep 2002 15:21:33 +0900 From: "hatakeyama" To: Subject: issue on dual cpu machine Date: Wed, 4 Sep 2002 15:21:33 +0900 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000B_01C25426.C0AB7DF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-archive-position: 246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hatakeyama@bsd.tnes.nec.co.jp Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C25426.C0AB7DF0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi, I found an issue on dual cpu machine. Description: the xfs couldn't follow append-write semantics correctly. After the file was opened with O_APPEND flag, then seek the file position of EOF before each writing. After several seconds, we found that the data was not written one by one, that means some of them have been overwritten. Configuration: VERSION:2.4.17(xfs-0225-all.patch) Dual Intel pentium III 900 2G RAM -------- You can reproduce the issue with the attached files as below: chdir to a xfs, run # test kill this process, the files size exceed 40 MB. and verify as below: # test2 testfile* -------- Regards, hatake ------=_NextPart_000_000B_01C25426.C0AB7DF0 Content-Type: application/octet-stream; name="test2.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test2.c" #include #include #include #include #include #include #include int main(int argc, char **argv) { char *file; int fd, i, rc, d; if (argc < 2) exit(1); file =3D argv[1]; if ((fd =3D open(file, O_RDONLY, 0600)) =3D=3D -1) { perror("couldn't open"); exit(1); } for (i =3D 0; ;i ++) { if ((rc =3D read(fd, &d, sizeof(d))) !=3D sizeof(i)) { if (rc =3D=3D 0) exit(0); perror("couldn't read"); exit(1); } if (d !=3D i) { fprintf(stderr, "bad data, offset =3D %u", i * 4); exit(1); } } exit(0); } ------=_NextPart_000_000B_01C25426.C0AB7DF0 Content-Type: application/octet-stream; name="test.c" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="test.c" #include #include #include #include #include #include int main(int argc, char **argv) { char file[MAXPATHLEN]; int fd, i; sprintf(file, "testfile.%d", getpid()); if ((fd =3D open(file, O_CREAT | O_RDWR | O_APPEND, 0600)) =3D=3D -1) { perror("couldn't open"); exit(1); } for (i =3D 0; ;i ++) { if (write(fd, &i, sizeof(i)) !=3D sizeof(i)) { perror("couldn't write"); exit(1); } } exit(0); } ------=_NextPart_000_000B_01C25426.C0AB7DF0-- From owner-linux-xfs@oss.sgi.com Tue Sep 3 23:54:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Sep 2002 23:54:49 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g846sitG004265 for ; Tue, 3 Sep 2002 23:54:44 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id XAA08223 for ; Tue, 3 Sep 2002 23:58:44 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA13996; Wed, 4 Sep 2002 16:57:24 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) with ESMTP id g846uxKR000575; Wed, 4 Sep 2002 16:56:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.5/8.12.5/Debian-1) id g846uwnH000573; Wed, 4 Sep 2002 16:56:58 +1000 Date: Wed, 4 Sep 2002 16:56:58 +1000 From: Nathan Scott To: hatakeyama Cc: linux-xfs@oss.sgi.com Subject: Re: issue on dual cpu machine Message-ID: <20020904065658.GA518@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-archive-position: 247 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Hi there, This does not fail on my quad CPU test box with CVS code. I seem to remember a problem with append writes from a long time ago, but not the specific fix [ -- there was a specific fix, I just can't remember what it was ;-) ]. You might be able to dredge the CVS logs if you need to stay at that version, otherwise I'd recommend upgrading to more recent kernel code (2.4.17 is already dated). FWIW, I tried these different test sizes: -rw------- 1 root root 2.9M Sep 4 16:33 /mnt/xfs1/testfile.1176 -rw------- 1 root root 20M Sep 4 16:35 /mnt/xfs1/testfile.1183 -rw------- 1 root root 74M Sep 4 16:50 /mnt/xfs1/testfile.1233 cheers. -- Nathan On Wed, Sep 04, 2002 at 03:21:33PM +0900, hatakeyama wrote: > Hi, > > I found an issue on dual cpu machine. > > Description: > the xfs couldn't follow append-write semantics correctly. > After the file was opened with O_APPEND flag, then seek the > file position of EOF before each writing. After several seconds, > we found that the data was not written one by one, that means > some of them have been overwritten. > > Configuration: > VERSION:2.4.17(xfs-0225-all.patch) > Dual Intel pentium III 900 > 2G RAM > > -------- > You can reproduce the issue with the attached files as below: > > chdir to a xfs, run > > # test > > kill this process, the files size exceed 40 MB. > > and verify as below: > > # test2 testfile* > -------- > > Regards, > hatake From owner-linux-xfs@oss.sgi.com Wed Sep 4 01:39:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 01:39:42 -0700 (PDT) Received: from Gateway.bksys.co.in ([61.1.200.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g848dYtG018329 for ; Wed, 4 Sep 2002 01:39:36 -0700 Received: from bksys.co.in (mail.bksys.co.in [192.168.1.1]) by Gateway.bksys.co.in (8.11.6/8.11.6) with ESMTP id g848hSo06992 for ; Wed, 4 Sep 2002 14:13:29 +0530 Received: from Uday.bksys.co.in (IDENT:7w6G4WfSJf11qnE0hg/x0LXAoA2KzdwC@Uday.bksys.co.in [192.168.1.79]) by bksys.co.in (8.11.6/8.8.5) with ESMTP id g848fsK13492 for ; Wed, 4 Sep 2002 14:11:54 +0530 Date: Wed, 4 Sep 2002 14:15:50 +0530 (IST) From: "Udaya Kumar.R" X-X-Sender: uday@Uday.bksys.co.in Reply-To: "Udaya Kumar.R" To: linux-xfs@oss.sgi.com Subject: 2.4.18 not compiling with XFS ! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: itsuday@linuxfreemail.com Precedence: bulk X-list: linux-xfs hi , I m a newbie to Linux & XFS and i m in RedHat 7.3 . I m trying to make my kernel ( 2.4.18 ) , XFS enabled . In the process i downloaded the patch from : ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18/ which is ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18/xfs-2.4. 18-all-i386.bz2 After untaring the kernel and applying the patch , everything patched proprely , i went on to compile him . I enabled the required options in 'make menuconfig' , said 'make dep' and 'make bzImage' . In the last step , 'make bzImage' , i got some errors which i have posted along with this mail . ld -m elf_i386 -T /usr/src/linux-2.4.18/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/pnp/pnp.o drivers/video/video.o drivers/usb/usbdrv.o drivers/input/inputdrv.o net/network.o /usr/src/linux-2.4.18/arch/i386/lib/lib.a /usr/src/linux-2.4.18/lib/lib.a /usr/src/linux-2.4.18/arch/i386/lib/lib.a --end-group -o vmlinux fs/fs.o: In function `xfs_dm_send_data_event': fs/fs.o(.text+0x4a622): undefined reference to `dm_send_data_event' fs/fs.o: In function `xfs_dm_send_create_event': fs/fs.o(.text+0x4a6d6): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_dm_bulkstat_one': fs/fs.o(.text+0x4ab2a): undefined reference to `dm_vp_to_handle' fs/fs.o: In function `xfs_dm_mount': fs/fs.o(.text+0x4d6d6): undefined reference to `dm_send_mount_event' fs/fs.o: In function `xfs_rename': fs/fs.o(.text+0x9b26d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x9bc47): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_unmount': fs/fs.o(.text+0xa14e4): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa15b3): undefined reference to `dm_send_unmount_event' fs/fs.o: In function `xfs_setattr': fs/fs.o(.text+0xa36f5): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_inactive': fs/fs.o(.text+0xa461e): undefined reference to `dm_send_destroy_event' fs/fs.o: In function `xfs_create': fs/fs.o(.text+0xa5551): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_remove': fs/fs.o(.text+0xa5b90): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa6051): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_link': fs/fs.o(.text+0xa619d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa6556): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0xa6b53): more undefined references to `dm_send_namesp_event' follow make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4.18' make: *** [vmlinux] Error 2 Tell me how to go about on getting thru. xfs enabled kernel ! Note : I enabled the XFS as loadable module . bye uday -- Reply To : perl -e 'print pack "H*","69747375646179406c696e7578667265656d61696c2e636f6d";' OR to the above 'From' Address From owner-linux-xfs@oss.sgi.com Wed Sep 4 02:48:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 02:48:51 -0700 (PDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g849mjtG023052 for ; Wed, 4 Sep 2002 02:48:45 -0700 Received: (qmail 41540 invoked from network); 4 Sep 2002 09:52:46 -0000 Received: from unknown (HELO mountainviewdata.com) (210.72.245.13) by relay1.pair.com with SMTP; 4 Sep 2002 09:52:46 -0000 X-pair-Authenticated: 210.72.245.13 Message-ID: <3D75D7A6.7010205@mountainviewdata.com> Date: Wed, 04 Sep 2002 17:51:34 +0800 From: tom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Ask a xfs problem Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-archive-position: 249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: twang@mountainviewdata.com Precedence: bulk X-list: linux-xfs Hi xfs developers. These days when I studied the xfs code, I found that if a process allocats one inode extents, while another process frees its extents which belong to another inode at the meantime, these two processes maybe deadlock. Following is my analysis: when allocating the extents, the process may loop over allocation groups and lock their allocation agf blocks. (the code 2380-2430 in xfs_alloc.c) At the same time, if another process free its extents, then the deadlock of these two process will happen, for it will also lock some allocation agf block, and furthermore the lock sequences of agf in these two process is apparently different.(the code 4040-4056 in fs/xfs/xfs_bmap.c) I really want to figure out it. Your responses is highly appreciated. Best regards. From owner-linux-xfs@oss.sgi.com Wed Sep 4 04:04:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 04:05:03 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84B4utG030039 for ; Wed, 4 Sep 2002 04:04:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id EAA00196 for ; Wed, 4 Sep 2002 04:08:57 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA15360; Wed, 4 Sep 2002 21:07:25 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id VAA95153; Wed, 4 Sep 2002 21:07:23 +1000 (AEDT) Date: Wed, 4 Sep 2002 21:07:23 +1000 From: Nathan Scott To: "Udaya Kumar.R" Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 not compiling with XFS ! Message-ID: <20020904210723.A95165@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from itsuday@linuxfreemail.com on Wed, Sep 04, 2002 at 02:15:50PM +0530 X-archive-position: 250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 02:15:50PM +0530, Udaya Kumar.R wrote: > hi , > > I m a newbie to Linux & XFS and i m in RedHat 7.3 . > > I m trying to make my kernel ( 2.4.18 ) , XFS enabled . > ... > > Tell me how to go about on getting thru. xfs enabled kernel ! > > Note : I enabled the XFS as loadable module . The easiest solution for you would be to disable XFS DMAPI support in your kernel builds. With recent changes in the XFS kernel code (after 2.4.18 I guess) this sort of error cannot happen, but Dean may have some more suggestions for you if you need to enable DMAPI support in that particular kernel version. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 4 08:43:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 08:43:30 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84FhPtG027908 for ; Wed, 4 Sep 2002 08:43:26 -0700 Received: (qmail 6475 invoked by uid 500); 4 Sep 2002 15:47:04 -0000 Subject: What's up with the list? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031154424.6416.10.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Sep 2002 10:47:04 -0500 X-archive-position: 251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Has everything gone crazy, or is there now an xfs-dev list or something, and so bug reports aren't getting noticed as much? -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 4 09:17:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 09:17:44 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84GHbtG029385 for ; Wed, 4 Sep 2002 09:17:37 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA15625; Wed, 4 Sep 2002 11:21:34 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id LAA21204; Wed, 4 Sep 2002 11:21:34 -0500 (CDT) Subject: Re: What's up with the list? From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031154424.6416.10.camel@UberGeek.coremetrics.com> References: <1031154424.6416.10.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Sep 2002 11:18:29 -0500 Message-Id: <1031156310.3056.15.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-04 at 10:47, Austin Gonyou wrote: > Has everything gone crazy, or is there now an xfs-dev list or something, > and so bug reports aren't getting noticed as much? Or choice c) - Steve is out, I'm very busy, and we might not be able to deal with every problem as quickly as we'd like to... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 4 09:25:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 09:25:35 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84GPUtG029907 for ; Wed, 4 Sep 2002 09:25:30 -0700 Received: (qmail 6546 invoked by uid 500); 4 Sep 2002 16:28:59 -0000 Subject: Re: What's up with the list? From: Austin Gonyou To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031156310.3056.15.camel@stout.americas.sgi.com> References: <1031156310.3056.15.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031156939.6421.25.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Sep 2002 11:28:59 -0500 X-archive-position: 253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs :-D I hear ya. I was just curious. Not many mails from others yesterday evening. Used to be that the evening time was very busy. Then as this AM seems slow too, I was a bit worried that people had less interest or something. That's all. I wasn't trying to sound like a jerk, I was more curious than anything. On Wed, 2002-09-04 at 11:18, Eric Sandeen wrote: > On Wed, 2002-09-04 at 10:47, Austin Gonyou wrote: > > Has everything gone crazy, or is there now an xfs-dev list or > something, > > and so bug reports aren't getting noticed as much? > > Or choice c) - Steve is out, I'm very busy, and we might not be able > to > deal with every problem as quickly as we'd like to... > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:27:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:27:31 -0700 (PDT) Received: from imf03bis.bellsouth.net (mail303.mail.bellsouth.net [205.152.58.163]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HROtG016251 for ; Wed, 4 Sep 2002 10:27:25 -0700 Received: from TAZ2 ([66.156.0.36]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> for ; Wed, 4 Sep 2002 13:33:00 -0400 Date: Wed, 4 Sep 2002 13:29:45 -0400 From: Greg Freemyer Subject: mapcheck question To: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g84HRPtG016254 X-archive-position: 254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs I think I have the latest mapcheck which was recently posted. (Thanks to whoever is supporting this.) unfortunately mapcheck -V gives "$Id:$", so I can't say what the version number is. My real question is if the -f or --force option is still valid. mapcheck -aq seems to work fine for me, but since I want to run this at the end of my backup script I assume I need the -f option to keep any interactive questions from occuring. Whenever I try to add a -f or --force, I get a usage statement. Thanks Greg ====== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:36:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:36:06 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84Ha3tG016762 for ; Wed, 4 Sep 2002 10:36:03 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g84HduFZ097329; Wed, 4 Sep 2002 19:40:01 +0200 (CEST) Message-Id: <4.3.2.7.2.20020904193658.03a2a540@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Sep 2002 19:38:32 +0200 To: Dmitry Melekhov , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2.4.19- xfs oops In-Reply-To: <3D758B28.9000406@belkam.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 09:25 4-9-2002 +0500, Dmitry Melekhov wrote: >Hello! > >We had our fileserver died this night. >Sorry, I wrote down oops info by hands (so it is possible >that there are mistypings) and I can't run ksymoops on 2.4.19, >because we switched back to 2.4.18 for now, so most of warinings >are skipped here. Hope, anyway, that this info can help. I personally don't think we can do much with this oops. I don't even see a xfs_ function called anywhere. Not all oopses are a direct result from XFS, I have had a ethernet driver (bcm5700) blowup a box which is totally unrelated to disk io at all. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:41:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:41:25 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HfMtG017287 for ; Wed, 4 Sep 2002 10:41:22 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g84HjNLZ025735; Wed, 4 Sep 2002 19:45:23 +0200 (CEST) Message-Id: <4.3.2.7.2.20020904193939.03a1f278@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Sep 2002 19:43:58 +0200 To: "Egidijus Antanaitis" , From: Seth Mos Subject: Re: In-Reply-To: <002201c2531c$ca1cccf0$4c00000a@lukoil.lt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 09:37 3-9-2002 +0200, Egidijus Antanaitis wrote: >Dear support, > recently I got stuck with such a problem. OS - Linux RedHat 7.3, kernel >2.4.18. Hardware - Intel Desktop Board D845BG motherboard, Pentium 4 >processor, HDD's Maxtor d740x-6l. Because of a bug in motherboard, the >system often freezes. I have found, the Alan's Cox patch 2.4.19-ac3 has the >workaround according to this, but when I do apply it, the xfs patch doesn't >work correctly any more. Also, I cannot apply the xfs patch to newest >RedHat's 2.4.18-10 kernel source. I got a lot of rejects in both cases. XFS >has not a xfs patch to 2.4.19 kernel, hence I am stuck. Is any solution >here? Thanks for any help:) What patch is this? Is is possible for you to use one of the Red Hat Linux based kernels with XFS bolted on? They have lot's fixes and workarounds for known buggy hardware, most of these patches are never integrated into the mainstream kernels or it takes a while. 2.4.18-4 is the latest kernel we have in that form at the moment, it's from the 1.1 release but should do well. I am using it with good results on the main database server at work. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:51:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:51:14 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.mvhi.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HpBtG017827 for ; Wed, 4 Sep 2002 10:51:11 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17meMy-00012K-00; Wed, 04 Sep 2002 18:55:12 +0100 Date: Wed, 4 Sep 2002 18:55:12 +0100 From: Christoph Hellwig To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19- xfs oops Message-ID: <20020904185512.A3903@infradead.org> References: <3D758B28.9000406@belkam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D758B28.9000406@belkam.com>; from dm@belkam.com on Wed, Sep 04, 2002 at 09:25:12AM +0500 X-archive-position: 257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 09:25:12AM +0500, Dmitry Melekhov wrote: > Hello! > > We had our fileserver died this night. > Sorry, I wrote down oops info by hands (so it is possible > that there are mistypings) and I can't run ksymoops on 2.4.19, > because we switched back to 2.4.18 for now, so most of warinings > are skipped here. Hope, anyway, that this info can help. > > kernel BUG at filemap.c:843 mm/filemap.c in a stock kernel does not contain a BUG(). What patches do you use? From owner-linux-xfs@oss.sgi.com Wed Sep 4 10:54:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 10:55:01 -0700 (PDT) Received: from phoenix.infradead.org (carisma.slowglass.com [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84HswtG018332 for ; Wed, 4 Sep 2002 10:54:59 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17meQf-00013F-00; Wed, 04 Sep 2002 18:59:01 +0100 Date: Wed, 4 Sep 2002 18:59:01 +0100 From: Christoph Hellwig To: Dmitry Melekhov Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19- xfs oops Message-ID: <20020904185901.A4028@infradead.org> References: <3D758B28.9000406@belkam.com> <20020904185512.A3903@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020904185512.A3903@infradead.org>; from hch@infradead.org on Wed, Sep 04, 2002 at 06:55:12PM +0100 X-archive-position: 258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 06:55:12PM +0100, Christoph Hellwig wrote: > On Wed, Sep 04, 2002 at 09:25:12AM +0500, Dmitry Melekhov wrote: > > Hello! > > > > We had our fileserver died this night. > > Sorry, I wrote down oops info by hands (so it is possible > > that there are mistypings) and I can't run ksymoops on 2.4.19, > > because we switched back to 2.4.18 for now, so most of warinings > > are skipped here. Hope, anyway, that this info can help. > > > > kernel BUG at filemap.c:843 > > mm/filemap.c in a stock kernel does not contain a BUG(). > What patches do you use? Sorry, I read 943. Of course it does. From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:02:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:02:58 -0700 (PDT) Received: from imf16bis.bellsouth.net (mail116.mail.bellsouth.net [205.152.58.56]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84I2rtG018876 for ; Wed, 4 Sep 2002 11:02:53 -0700 Received: from TAZ2 ([66.156.0.36]) by imf16bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020904180829.NWVS7192.imf16bis.bellsouth.net@TAZ2>; Wed, 4 Sep 2002 14:08:29 -0400 Date: Wed, 4 Sep 2002 14:05:14 -0400 From: Greg Freemyer Subject: re: mapcheck question To: Greg Freemyer , xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020904180829.NWVS7192.imf16bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g84I2stG018878 X-archive-position: 259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> I think I have the latest mapcheck which was recently posted. (Thanks to >> whoever is supporting this.) >> unfortunately mapcheck -V gives "$Id:$", so I can't say what the version >> number is. >> My real question is if the -f or --force option is still valid. >> mapcheck -aq seems to work fine for me, but since I want to run this at >> the end of my backup script I assume I need the -f option to keep any >> interactive questions from occuring. >> Whenever I try to add a -f or --force, I get a usage statement. Replying to self, :o My mistake, mapcheck is always never asks for user input from what I can see in the code. The -f option is apparently to force it to process a filesystem even though it does not look like an XFS filesystem. (This is a guess from a very brief look at the code.) Regardless, the argument processing logic does not handle the -f or --force option, so if this is needed by anyone, the code is broken. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:33:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:33:17 -0700 (PDT) Received: from psygenomics.com (user1.psygenomics.com [66.200.78.178]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IX9tG021062 for ; Wed, 4 Sep 2002 11:33:10 -0700 Received: from localhost (root@localhost) by psygenomics.com (8.9.3/8.9.3) with ESMTP id OAA07568 for ; Wed, 4 Sep 2002 14:36:12 -0400 X-OpenMail-Hops: 1 Date: Wed, 4 Sep 2002 14:36:12 -0400 Message-Id: Subject: XFS bad block recording? MIME-Version: 1.0 From: dbarber@psygenomics.com TO: linux-xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=openmail-part-002387b2-00000002 X-archive-position: 260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dbarber@psygenomics.com Precedence: bulk X-list: linux-xfs --openmail-part-002387b2-00000002 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline; filename="BDY.RTF" ;Creation-Date="Wed, 4 Sep 2002 14:36:11 -0400" Content-Transfer-Encoding: quoted-printable Is there a way mark the bad blocks on the hard drive while mkfs'ing the drive? Or another tool to mark bad blocks on a live filesystem? Just curious. Thanks! Don --openmail-part-002387b2-00000002 Content-Type: application/rtf Content-Disposition: attachment; filename="BDY.RTF" ;Creation-Date="Wed, 4 Sep 2002 14:36:11 -0400" Content-Transfer-Encoding: base64 e1xydGYxXGFuc2lcYW5zaWNwZzEyNTJcZnJvbXRleHQgXGRlZmYwe1xmb250 dGJsDQp7XGYwXGZzd2lzcyBBcmlhbDt9DQp7XGYxXGZtb2Rlcm4gQ291cmll ciBOZXc7fQ0Ke1xmMlxmbmlsXGZjaGFyc2V0MiBTeW1ib2w7fQ0Ke1xmM1xm bW9kZXJuXGZjaGFyc2V0MCBDb3VyaWVyIE5ldzt9fQ0Ke1xjb2xvcnRibFxy ZWQwXGdyZWVuMFxibHVlMDtccmVkMFxncmVlbjBcYmx1ZTI1NTt9DQpcdWMx XHBhcmRccGxhaW5cZGVmdGFiMzYwIFxmMFxmczIwIElzIHRoZXJlIGEgd2F5 IG1hcmsgdGhlIGJhZCBibG9ja3Mgb24gdGhlIGhhcmQgZHJpdmUgd2hpbGUg bWtmcydpbmcgdGhlIGRyaXZlPyAgT3IgYW5vdGhlciB0b29sIHRvIG1hcmsg YmFkIGJsb2NrcyBvbiBhIGxpdmUgZmlsZXN5c3RlbT8gIEp1c3QgY3VyaW91 cy5ccGFyDQpccGFyDQpUaGFua3MhXHBhcg0KXHBhcg0KRG9uXHBhcg0KfQ== --openmail-part-002387b2-00000002-- From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:40:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:40:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84Ie8tG021562 for ; Wed, 4 Sep 2002 11:40:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA17180 for ; Wed, 4 Sep 2002 13:44:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA29807 for ; Wed, 4 Sep 2002 13:44:07 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84If1T20957; Wed, 4 Sep 2002 13:41:01 -0500 Message-Id: <200209041841.g84If1T20957@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 13:41:01 -0500 Subject: TAKE - remove dead members of struct vfs X-archive-position: 261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs From Christoph: "These two are only ever set and never read." remove dead members of struct vfs Date: Wed Sep 4 11:43:38 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126693a linux/fs/xfs/xfs_vfsops.c - 1.378 linux/fs/xfs/xfs_mount.c - 1.300 linux/fs/xfs/linux/xfs_vfs.h - 1.29 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:41:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:41:19 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IfHtG021822 for ; Wed, 4 Sep 2002 11:41:17 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g84IjJBx035736; Wed, 4 Sep 2002 20:45:19 +0200 (CEST) Message-Id: <4.3.2.7.2.20020904204331.02e58070@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Sep 2002 20:44:08 +0200 To: dbarber@psygenomics.com, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS bad block recording? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 14:36 4-9-2002 -0400, dbarber@psygenomics.com wrote: >Is there a way mark the bad blocks on the hard drive while mkfs'ing the >drive? Or another tool to mark bad blocks on a live filesystem? Just >curious. Nope. XFS automatiically bails out on a IO error and umounts the filesystem to prevent further damage. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:41:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:41:26 -0700 (PDT) Received: from imf22bis.bellsouth.net (mail122.mail.bellsouth.net [205.152.58.82]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IfOtG021852 for ; Wed, 4 Sep 2002 11:41:24 -0700 Received: from TAZ2 ([66.156.0.36]) by imf22bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020904184514.YNRW2113.imf22bis.bellsouth.net@TAZ2>; Wed, 4 Sep 2002 14:45:14 -0400 Date: Wed, 4 Sep 2002 14:43:44 -0400 From: Greg Freemyer Subject: re: XFS bad block recording? To: , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020904184514.YNRW2113.imf22bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g84IfOtG021900 X-archive-position: 263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> Is there a way mark the bad blocks on the hard drive while mkfs'ing the >> drive? Or another tool to mark bad blocks on a live filesystem? Just >> curious. >> Thanks! >> Don I think badblocks are handled at the drive level anymore. Both with SCSI and IDE. If you look at a old drive and a new one, you will see on the old one a list of bad sectors as it left the factory. On new drives, they don't show it because the drive internally maps around the bad sectors. AFAIK, if a drive starts having end-user observable bad sectors, it is time to replace it. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:44:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:44:34 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IiWtG022935 for ; Wed, 4 Sep 2002 11:44:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA17329; Wed, 4 Sep 2002 13:48:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA93311; Wed, 4 Sep 2002 13:48:30 -0500 (CDT) Subject: Re: XFS bad block recording? From: Eric Sandeen To: dbarber@psygenomics.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Sep 2002 13:45:25 -0500 Message-Id: <1031165125.3056.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs The short answer is "no," and the longer answer is that by the time a modern drive is showing bad blocks to the user, it's a short trip to the dumpster, IMHO! -Eric On Wed, 2002-09-04 at 13:36, dbarber@psygenomics.com wrote: > Is there a way mark the bad blocks on the hard drive while mkfs'ing the > drive? Or another tool to mark bad blocks on a live filesystem? Just > curious. > > Thanks! > > Don > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:52:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:52:44 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IqftG023551 for ; Wed, 4 Sep 2002 11:52:41 -0700 Received: (qmail 7071 invoked by uid 500); 4 Sep 2002 18:56:12 -0000 Subject: Re: XFS bad block recording? From: Austin Gonyou To: Seth Mos Cc: dbarber@psygenomics.com, linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020904204331.02e58070@pop.xs4all.nl> References: <4.3.2.7.2.20020904204331.02e58070@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031165771.6421.72.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Sep 2002 13:56:11 -0500 X-archive-position: 265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-04 at 13:44, Seth Mos wrote: > At 14:36 4-9-2002 -0400, dbarber@psygenomics.com wrote: > >Is there a way mark the bad blocks on the hard drive while mkfs'ing > the > >drive? Or another tool to mark bad blocks on a live filesystem? > Just > >curious. > > Nope. XFS automatiically bails out on a IO error and umounts the > filesystem > to prevent further damage. Hrrmm....Something really bad happened then with my system. We had/have lots of IO errors on one host, now XFS can't replay the logs, mount segfaults. I don't think there's physical corruption, the disks are really new, but were working fine before, and after dumping the logs, things are good. I've got V1 logs though, dunno if that makes a difference. One of the HBAs or GBICs went bellyup on us, but XFS didn't shut-down. Now I can't mount. I don't want to dump the logs, anyone have any ideas? > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:55:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:55:58 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84ItstG024060 for ; Wed, 4 Sep 2002 11:55:55 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA05982 for ; Wed, 4 Sep 2002 11:59:57 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA16864 for ; Wed, 4 Sep 2002 13:50:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA53394 for ; Wed, 4 Sep 2002 13:50:30 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84IlPu21194; Wed, 4 Sep 2002 13:47:25 -0500 Message-Id: <200209041847.g84IlPu21194@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 13:47:25 -0500 Subject: TAKE - make xfs_aops.c look like XFS source X-archive-position: 266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Again from Christoph: "Remove the misleading comment the refers to page_bufs (I've also removed the written by part as nothing else in XFS has it), use xfs.h insead of page_buf_internal.h, s/static/STATIC/g, use XFS's ASSERT() instead of hand-crafted assert()." make xfs_aops.c look like XFS source Date: Wed Sep 4 11:49:59 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126696a linux/fs/xfs/linux/xfs_aops.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:57:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 11:57:59 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IvttG024489 for ; Wed, 4 Sep 2002 11:57:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA12559 for ; Wed, 4 Sep 2002 14:01:53 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA62964 for ; Wed, 4 Sep 2002 14:01:53 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84IwmU21547; Wed, 4 Sep 2002 13:58:48 -0500 Message-Id: <200209041858.g84IwmU21547@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 13:58:48 -0500 Subject: TAKE - use wait_event in xfs_iunpin_wait X-archive-position: 267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Another one from Christoph. use wait_event in xfs_iunpin_wait Date: Wed Sep 4 12:01:30 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126700a linux/fs/xfs/xfs_inode.c - 1.349 From owner-linux-xfs@oss.sgi.com Wed Sep 4 11:59:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 12:00:05 -0700 (PDT) Received: from fruit.eu.org (qmailr@d4400fd8.cable.wanadoo.nl [212.64.15.216]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84IxvtG025035 for ; Wed, 4 Sep 2002 11:59:58 -0700 Received: (qmail 28935 invoked by uid 500); 4 Sep 2002 19:03:58 -0000 Resent-Message-ID: <20020904190358.28934.qmail@fruit.eu.org> Date: Wed, 4 Sep 2002 21:03:08 +0200 From: Wessel Dankers To: Greg Freemyer Subject: Re: mapcheck question Message-ID: <20020904190308.GO567@fruit.eu.org> References: <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020904173300.YGWW9332.imf03bis.bellsouth.net@TAZ2> User-Agent: Mutt/1.4i X-oi: oi Resent-From: wsl@fruit.eu.org Resent-Date: Wed, 4 Sep 2002 21:03:57 +0200 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-04 13:29:45-0400, Greg Freemyer wrote: > unfortunately mapcheck -V gives "$Id:$", so I can't say what the version number is. Yes, it isn't in CVS yet. I have added a date there instead. > Whenever I try to add a -f or --force, I get a usage statement. Silly bug. The force function was completely implemented but not checked for in the option interpreting part. Fixed too. I also imported Ethan Benson's changes. You can download the result from: URI: http://fruit.eu.org/mapcheck.c md5: 553db9cb32e754b33f0a4aa3151cab96 mapcheck.c sha1: 8be76862923130634471e597f3fbb053de07c92e mapcheck.c HTH, HAND! :) -- Wessel Dankers From owner-linux-xfs@oss.sgi.com Wed Sep 4 12:27:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 12:27:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84JQxtG025760 for ; Wed, 4 Sep 2002 12:27:00 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA17396 for ; Wed, 4 Sep 2002 14:30:58 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA85411 for ; Wed, 4 Sep 2002 14:30:58 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id OAA06009 for linux-xfs@oss.sgi.com; Wed, 4 Sep 2002 14:30:57 -0500 (CDT) Date: Wed, 4 Sep 2002 14:30:57 -0500 (CDT) From: Dean Roehrich Message-Id: <200209041930.OAA06009@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - add mtpt option to xfs.txt X-archive-position: 269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Sep 4 12:30:36 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126702a linux/Documentation/filesystems/xfs.txt - 1.11 - add mtpt option to go with dmapi option. remove xdsm option From owner-linux-xfs@oss.sgi.com Wed Sep 4 13:09:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 13:09:41 -0700 (PDT) Received: from femme.sapphite.org (root@pcp02268182pcs.longhl01.md.comcast.net [68.50.99.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84K9ZtG027465 for ; Wed, 4 Sep 2002 13:09:35 -0700 Received: from localhost (trish@localhost [127.0.0.1]) by femme.sapphite.org (8.12.6/8.12.5) with ESMTP id g84KE8C3001417 for ; Wed, 4 Sep 2002 16:14:09 -0400 (EDT) (envelope-from trish@bsdunix.net) Date: Wed, 4 Sep 2002 16:14:08 -0400 (EDT) From: Trish Lynch X-X-Sender: To: Subject: possible xfs panic? Message-ID: <20020904160646.V426-100000@femme.sapphite.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: trish@bsdunix.net Precedence: bulk X-list: linux-xfs THis is with: Linux www-s1-3 2.4.19-xfs #1 SMP Tue Sep 3 22:45:09 EDT 2002 i686 unknown The XFS patch for 2.4.19 off oss.sgi.com [1]kdb> bt ESP EIP Function (args) 0xd27e5ba8 0xc01f01aa linvfs_follow_link+0x8e (0xeb16e3e0, 0xd27e5c0c,0xe783049c, 0xd27e5c0c) kernel .text 0xc0100000 0xc01f011c 0xc01f0208 0xd27e5bc0 0xc014470d link_path_walk+0x83d kernel .text 0xc0100000 0xc0143ed0 0xc014486c 0xd27e5bf8 0xc0144886 path_walk+0x1a (0xd27e4000, 0xc9659322, 0xc02b0f5e, 0x13) kernel .text 0xc0100000 0xc014486c 0xc0144888 0xd27e5bfc 0xc0141e3e open_exec+0x2e (0xc9659320, 0xc0389958, 0xc01569c4, 0xd27e5e6c, 0x0) kernel .text 0xc0100000 0xc0141e10 0xc0141edc 0xd27e5c2c 0xc0156c6e load_elf_binary+0x2aa (0xd27e5e6c, 0xd27e5fc4, 0xd27e5e6c, 0xd27e5e7c, 0xd27e5da2) kernel .text 0xc0100000 0xc01569c4 0xc015744c 0xd27e5d38 0xc0142786 search_binary_handler+0x7a (0xd27e5e6c, 0xd27e5fc4) kernel .text 0xc0100000 0xc014270c 0xc01428b0 0xd27e5d70 0xc0156262 load_script+0x1a2 (0xd27e5e6c, 0xd27e5fc4, 0xd27e5e6c, 0x0, 0xd27e5eec) kernel .text 0xc0100000 0xc01560c0 0xc01562a0 0xd27e5e18 0xc0142786 search_binary_handler+0x7a (0xd27e5e6c, 0xd27e5fc4) kernel .text 0xc0100000 0xc014270c 0xc01428b0 0xd27e5e50 0xc0142a45 do_execve+0x195 (0xd540a000, 0xbfffa890, 0x871cce4, 0xd27e5fc4, 0xd27e4000) kernel .text 0xc0100000 0xc01428b0 0xc0142aa0 0xd27e5fa4 0xc010758f sys_execve+0x2f (0x86a6b3c, 0xbfffa890, 0x871cce4, 0xbfffa890, 0x86a6b3c) kernel .text 0xc0100000 0xc0107560 0xc01075c0 0xd27e5fc4 0xc0108a3b system_call+0x33 kernel .text 0xc0100000 0xc0108a08 0xc0108a40 [1]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc19de000 00000001 00000000 0 000 stop 0xc19de370 init 0xc19d2000 00000002 00000001 0 000 stop 0xc19d2370 keventd 0xc19de000 00000001 00000000 0 000 stop 0xc19de370 init 0xc19d2000 00000002 00000001 0 000 stop 0xc19d2370 keventd 0xc19d0000 00000003 00000001 0 000 stop 0xc19d0370 ksoftirqd_CPU0 0xc19ce000 00000004 00000001 0 001 stop 0xc19ce370 ksoftirqd_CPU1 0xf7e3e000 00000005 00000001 0 000 run 0xf7e3e370 kswapd 0xf7e3c000 00000006 00000001 0 000 stop 0xf7e3c370 bdflush 0xf7e3a000 00000007 00000001 0 000 stop 0xf7e3a370 kupdated 0xf7e28000 00000008 00000001 0 000 run 0xf7e28370 pagebufd 0xf7e26000 00000009 00000001 0 000 stop 0xf7e26370 pagebuf_io_CPU0 0xf7e24000 00000010 00000001 0 001 stop 0xf7e24370 pagebuf_io_CPU1 0xf76a0000 00000017 00000001 0 001 stop 0xf76a0370 devfsd 0xf7322000 00000084 00000001 0 000 stop 0xf7322370 mdrecoveryd 0xf7658000 00000489 00000001 0 001 stop 0xf7658370 syslogd 0xf6e46000 00000494 00000001 0 001 run 0xf6e46370 klogd 0xf6dfe000 00000508 00000001 0 001 stop 0xf6dfe370 portmap 0xf6c1c000 00000581 00000001 0 001 stop 0xf6c1c370 rpciod 0xf6c0a000 00000582 00000001 0 000 stop 0xf6c0a370 lockd 0xf71b2000 00000597 00000001 0 000 stop 0xf71b2370 ntpd 0xf742e000 00000619 00000001 0 000 stop 0xf742e370 atd 0xf6a00000 00000631 00000001 0 001 stop 0xf6a00370 sshd 0xf69aa000 00000651 00000001 0 000 stop 0xf69aa370 xinetd 0xf687a000 00000663 00000001 0 001 stop 0xf687a370 exim 0xf3106000 00000693 00000001 0 000 stop 0xf3106370 httpd 0xf2f16000 00000694 00000693 0 000 stop 0xf2f16370 httpd 0xf2efe000 00000695 00000693 0 000 stop 0xf2efe370 httpd 0xf2eb6000 00000696 00000693 0 001 run 0xf2eb6370 httpd 0xf2e6c000 00000697 00000693 0 000 stop 0xf2e6c370 httpd 0xf2e22000 00000698 00000693 0 000 stop 0xf2e22370 httpd 0xf2dd8000 00000699 00000693 0 000 stop 0xf2dd8370 httpd 0xf2d8c000 00000700 00000693 0 000 stop 0xf2d8c370 httpd 0xf2d42000 00000701 00000693 0 000 stop 0xf2d42370 httpd 0xf2d8c000 00000700 00000693 0 000 stop 0xf2d8c370 httpd 0xf2d42000 00000701 00000693 0 000 stop 0xf2d42370 httpd 0xf2cfa000 00000702 00000693 0 000 stop 0xf2cfa370 httpd 0xf2cae000 00000703 00000693 0 000 stop 0xf2cae370 httpd 0xf2c66000 00000704 00000693 0 000 stop 0xf2c66370 httpd 0xf2c1a000 00000705 00000693 0 000 stop 0xf2c1a370 httpd 0xf2bd2000 00000706 00000693 0 000 stop 0xf2bd2370 httpd 0xf2b88000 00000707 00000693 0 000 stop 0xf2b88370 httpd 0xf2b40000 00000708 00000693 0 000 stop 0xf2b40370 httpd 0xf1426000 00000709 00000693 0 000 stop 0xf1426370 httpd 0xef76a000 00000710 00000693 0 000 stop 0xef76a370 httpd 0xee9ee000 00000711 00000693 0 000 stop 0xee9ee370 httpd 0xee9cc000 00000712 00000693 0 000 run 0xee9cc370 httpd 0xed832000 00000713 00000693 0 000 run 0xed832370 httpd 0xecff8000 00000714 00000693 0 000 stop 0xecff8370 httpd 0xecfd4000 00000715 00000693 0 000 stop 0xecfd4370 httpd 0xec66c000 00000720 00000001 0 001 run 0xec66c370 httpd 0xf538e000 00000734 00000720 0 001 run 0xf538e370 httpd 0xf5854000 00000747 00000001 0 000 stop 0xf5854370 crond 0xe39bc000 00001159 00000001 0 000 run 0xe39bc370 spread 0xf78e4000 00001179 00000001 0 000 stop 0xf78e4370 mingetty 0xeb096000 00001180 00000001 0 000 stop 0xeb096370 mingetty 0xf5bd8000 00001181 00000001 0 000 stop 0xf5bd8370 mingetty 0xf5c74000 00001182 00000001 0 000 stop 0xf5c74370 mingetty 0xf6806000 00001183 00000001 0 000 stop 0xf6806370 mingetty 0xe5f1a000 00001184 00000001 0 000 stop 0xe5f1a370 mingetty 0xe5e76000 00001185 00000001 0 001 stop 0xe5e76370 agetty 0xcd968000 00005117 00000693 0 000 stop 0xcd968370 httpd 0xcaa9e000 00005884 00000693 0 000 stop 0xcaa9e370 httpd 0xc516e000 00008702 00000693 0 000 stop 0xc516e370 httpd 0xc4966000 00008703 00000693 0 000 run 0xc4966370 httpd 0xc516e000 00008702 00000693 0 000 stop 0xc516e370 httpd 0xc4966000 00008703 00000693 0 000 run 0xc4966370 httpd 0xc582a000 00008704 00000693 0 000 stop 0xc582a370 httpd 0xc4182000 00008705 00000693 0 000 stop 0xc4182370 httpd 0xc4164000 00008706 00000693 0 000 stop 0xc4164370 httpd 0xc411a000 00008707 00000693 0 000 stop 0xc411a370 httpd 0xf548c000 00010519 00000720 0 001 stop 0xf548c370 httpd 0xe972e000 00010521 00000720 0 000 stop 0xe972e370 httpd 0xe73e6000 00010580 00000720 0 001 stop 0xe73e6370 httpd 0xe44ba000 00010742 00000747 0 001 stop 0xe44ba370 crond 0xe44d2000 00010745 00010742 0 001 stop 0xe44d2370 run-parts 0xe452a000 00010751 00010745 0 001 stop 0xe452a370 awk 0xe44a0000 00010752 00000001 0 001 stop 0xe44a0370 sa1 0xe44c2000 00010755 00010752 0 000 stop 0xe44c2370 sadc 0xe44dc000 00010757 00000720 0 000 stop 0xe44dc370 httpd 0xe43de000 00010759 00000720 0 000 stop 0xe43de370 httpd 0xe413c000 00010856 00000720 0 000 stop 0xe413c370 httpd 0xe4f42000 00011497 00000720 0 000 stop 0xe4f42370 httpd 0xf65ec000 00011507 00000720 0 000 stop 0xf65ec370 httpd 0xebe7a000 00011527 00000720 0 000 stop 0xebe7a370 httpd 0xe2ecc000 00011580 00000720 0 000 stop 0xe2ecc370 httpd 0xe30bc000 00011584 00000720 0 001 stop 0xe30bc370 httpd 0xd9a76000 00011585 00000720 0 001 stop 0xd9a76370 httpd 0xe3966000 00011592 00000720 0 001 stop 0xe3966370 httpd 0xe327a000 00011597 00000720 0 001 stop 0xe327a370 httpd 0xd9f0c000 00011605 00000720 0 000 stop 0xd9f0c370 httpd 0xd95bc000 00011626 00000720 0 000 stop 0xd95bc370 httpd 0xd94c0000 00011628 00000720 0 001 stop 0xd94c0370 httpd 0xd958a000 00011629 00000720 0 000 stop 0xd958a370 httpd 0xe3c1c000 00011756 00000631 0 000 stop 0xe3c1c370 sshd 0xe5720000 00011758 00011756 0 001 stop 0xe5720370 bash 0xe3c1c000 00011756 00000631 0 000 stop 0xe3c1c370 sshd 0xe5720000 00011758 00011756 0 001 stop 0xe5720370 bash 0xf2f68000 00011797 00011507 0 000 stop 0xf2f68370 serve.cgi 0xd27e4000 00011804 00011629 1 001 run 0xd27e4370*httpd 0xe2268000 00011807 00011758 0 001 stop 0xe2268370 apachectl 0xcbb78000 00011808 00011807 1 000 run 0xcbb78370 apachectl -- Trish Lynch trish@bsdunix.net Ecartis Core Team trish@listmistress.org Key fingerprint = C44E 8E63 6E3C 18BD 608F E004 9DC7 C2E9 0E24 DFBD From owner-linux-xfs@oss.sgi.com Wed Sep 4 13:19:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 13:20:00 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84KJttG028036 for ; Wed, 4 Sep 2002 13:19:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA17795 for ; Wed, 4 Sep 2002 15:23:54 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA19290 for ; Wed, 4 Sep 2002 15:23:54 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84KKmn23318; Wed, 4 Sep 2002 15:20:48 -0500 Message-Id: <200209042020.g84KKmn23318@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 15:20:48 -0500 Subject: TAKE - remove copyin/copyout X-archive-position: 271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Still more from Christoph. "copyin/copyout is used only six times in the actual XFS code. Also remove an unused member of struct uio and and enum uio_seg members that don't make sense on Linux." remove copyin/copyout Date: Wed Sep 4 13:22:39 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126707a linux/fs/xfs/xfs_itable.c - 1.110 linux/fs/xfs/xfs_dfrag.c - 1.35 linux/fs/xfs/xfs_bmap.c - 1.291 linux/fs/xfs/support/move.h - 1.9 linux/fs/xfs/support/move.c - 1.8 From owner-linux-xfs@oss.sgi.com Wed Sep 4 13:52:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 13:52:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84KqgtG028849 for ; Wed, 4 Sep 2002 13:52:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA17380 for ; Wed, 4 Sep 2002 15:56:41 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA75008 for ; Wed, 4 Sep 2002 15:56:41 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g84KrYr23710; Wed, 4 Sep 2002 15:53:34 -0500 Message-Id: <200209042053.g84KrYr23710@stout.americas.sgi.com> Date: Wed, 4 Sep 2002 15:53:34 -0500 Subject: TAKE - merge xfs_get_vfsmount into it's only caller X-archive-position: 272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Christoph won't let me do any of my own work today! "There wasn't much left of the old IRIX functionality.." merge xfs_get_vfsmount into it's only caller Date: Wed Sep 4 13:54:02 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126715a linux/fs/xfs/xfs_vfsops.c - 1.379 From owner-linux-xfs@oss.sgi.com Wed Sep 4 16:18:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 16:18:28 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g84NIOtG003966 for ; Wed, 4 Sep 2002 16:18:24 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA02025 for ; Wed, 4 Sep 2002 16:22:26 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA72075 for linux-xfs@oss.sgi.com; Thu, 5 Sep 2002 09:21:09 +1000 (EST) Date: Thu, 5 Sep 2002 09:21:09 +1000 (EST) From: Nathan Scott Message-Id: <200209042321.JAA72075@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - attr/acl updates X-archive-position: 273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Some minor updates from AndreasG, see doc/CHANGES for details. cheers. Date: Wed Sep 4 16:19:54 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126729a cmd/acl/VERSION - 1.36 cmd/acl/doc/CHANGES - 1.41 cmd/acl/debian/changelog - 1.30 cmd/attr/VERSION - 1.22 cmd/attr/doc/CHANGES - 1.27 cmd/attr/debian/changelog - 1.23 cmd/attr/test/run - 1.3 cmd/attr/setfattr/setfattr.c - 1.10 cmd/attr/getfattr/getfattr.c - 1.16 cmd/acl/libacl/acl_get_file.c - 1.5 cmd/acl/libacl/acl_get_fd.c - 1.4 cmd/acl/libacl/acl_extended_file.c - 1.3 cmd/acl/libacl/acl_extended_fd.c - 1.3 cmd/acl/libacl/acl_delete_def_file.c - 1.5 cmd/acl/getfacl/getfacl.c - 1.5 cmd/acl/getfacl/user_group.h - 1.2 cmd/acl/getfacl/user_group.c - 1.3 cmd/acl/test/misc.test - 1.2 cmd/acl/test/run - 1.3 - minor updates from Andreas. From owner-linux-xfs@oss.sgi.com Wed Sep 4 20:50:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 20:50:33 -0700 (PDT) Received: from mail.aspec.ru (mail.aspec.ru [217.14.198.4]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g853oPtG011136 for ; Wed, 4 Sep 2002 20:50:26 -0700 Received: from [192.168.22.111] (HELO belkam.com) by mail.aspec.ru (CommuniGate Pro SMTP 3.5.9) with ESMTP id 699802 for linux-xfs@oss.sgi.com; Thu, 05 Sep 2002 08:54:24 +0500 Message-ID: <3D76D542.90104@belkam.com> Date: Thu, 05 Sep 2002 08:53:38 +0500 From: Dmitry Melekhov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: ru, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: 2.4.19- xfs oops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dm@belkam.com Precedence: bulk X-list: linux-xfs >>Sorry, I wrote down oops info by hands (so it is possible >>that there are mistypings) and I can't run ksymoops on 2.4.19, >>because we switched back to 2.4.18 for now, so most of warinings >>are skipped here. Hope, anyway, that this info can help. > > I personally don't think we can do much with this oops. I don't even see a > xfs_ function called anywhere. OK :-) From owner-linux-xfs@oss.sgi.com Wed Sep 4 20:56:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 20:56:24 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g853txtG011512 for ; Wed, 4 Sep 2002 20:56:10 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id AD1885B87B; Wed, 4 Sep 2002 20:59:40 -0700 (PDT) Date: Wed, 4 Sep 2002 20:59:40 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: dbarber@psygenomics.com, linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? Message-ID: <20020905035940.GC6004@tapu.f00f.org> References: <1031165125.3056.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031165125.3056.18.camel@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Sep 04, 2002 at 01:45:25PM -0500, Eric Sandeen wrote: > The short answer is "no," and the longer answer is that by the time > a modern drive is showing bad blocks to the user, it's a short trip > to the dumpster, IMHO! It's a pretty rotten answer really :) I agree that since most (all?) modern drive transparently remap errors until the 'grown' table (or equivalent) is full that if you see errors your disk is in terrible shape and has been for some time, but it doesn't seem unreasonable for someone to want to mark part of the disk bad and have the fs avoid this. Almost ever other fs I can think of allows this kind of thing. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 4 22:39:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 22:39:08 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g855d2tG015058 for ; Wed, 4 Sep 2002 22:39:02 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA02272 for ; Wed, 4 Sep 2002 22:43:05 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA55247 for linux-xfs@oss.sgi.com; Thu, 5 Sep 2002 15:41:45 +1000 (EST) Date: Thu, 5 Sep 2002 15:41:45 +1000 (EST) From: Nathan Scott Message-Id: <200209050541.PAA55247@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_aops.c cleanup (contd). X-archive-position: 276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Help out a bit with the tidyup work - this keeps related aops/iops code together a bit more, and two less files. cheers. Date: Wed Sep 4 22:37:11 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126748a linux/fs/xfs/xfs_dmapi.c - 1.78 linux/fs/xfs/xfs_vfsops.c - 1.380 linux/fs/xfs/xfs_iget.c - 1.170 linux/fs/xfs/linux/xfs_lrw.c - 1.166 linux/fs/xfs/linux/xfs_linux.h - 1.84 linux/fs/xfs/linux/xfs_ioctl.c - 1.76 linux/fs/xfs/linux/xfs_xattr.c - 1.20 linux/fs/xfs/linux/xfs_xattr.h - 1.7 - remove an unneeded #include file. linux/fs/xfs/linux/Makefile - 1.63 linux/fs/xfs/linux/Makefile.in - 1.13 - xfs_xattr.o has been merged in with xfs_iops.o. linux/fs/xfs/linux/xfs_vnode.c - 1.97 linux/fs/xfs/linux/xfs_super.c - 1.211 - remove an unneeded #include file. linux/fs/xfs/linux/xfs_iops.c - 1.172 - move the xattr inode operations into here, move the address_space operations into xfs_aops.c. no functional change, but one less file & a bunch more static functions. linux/fs/xfs/linux/xfs_iops.h - 1.16 - merge xfs_xattr.h in here as the xattr ops are all inode ops. linux/fs/xfs/linux/xfs_aops.c - 1.3 - move the address_space operations from xfs_iops.c into here, make a bunch of stuff static now. remove a few more remnants of the pb/pagebuf naming scheme that remained here too. From owner-linux-xfs@oss.sgi.com Wed Sep 4 23:00:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 23:00:54 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8560qtG016039 for ; Wed, 4 Sep 2002 23:00:52 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17mplO-0000to-00 for linux-xfs@oss.sgi.com; Thu, 05 Sep 2002 00:05:10 -0600 Message-ID: <3D76F3E9.5090808@emergence.com> Date: Thu, 05 Sep 2002 00:04:25 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? References: <1031165125.3056.18.camel@stout.americas.sgi.com> <20020905035940.GC6004@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > It's a pretty rotten answer really :) > > I agree that since most (all?) modern drive transparently remap errors > until the 'grown' table (or equivalent) is full that if you see errors > your disk is in terrible shape and has been for some time, but it > doesn't seem unreasonable for someone to want to mark part of the disk > bad and have the fs avoid this. > > Almost ever other fs I can think of allows this kind of thing. > > --cw You should check out the Bad Block on Disk Drive section at: http://linas.org/linux/raid.html Which then links to this LKML discussion about the issue about bad block capabilities in 2.5: Basically even with ext2/ext3, with the drive failing spectacularly, it's pretty much game over for that drive. EVMS and LVM may have addressed this issue where the LVM/EVMS layer is actually handling the physical disks and can reallocate bad blocks on the fly. As he mentions many drives are using s.m.a.r.t these days, and monitoring your devices for that is probably useful. -Mike From owner-linux-xfs@oss.sgi.com Wed Sep 4 23:58:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Sep 2002 23:58:32 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g856wQtG018083 for ; Wed, 4 Sep 2002 23:58:26 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 580941C2A62; Thu, 5 Sep 2002 00:02:32 -0700 (PDT) Date: Thu, 5 Sep 2002 00:02:32 -0700 From: Chris Wedgwood To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? Message-ID: <20020905070232.GA6430@tapu.f00f.org> References: <1031165125.3056.18.camel@stout.americas.sgi.com> <20020905035940.GC6004@tapu.f00f.org> <3D76F3E9.5090808@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D76F3E9.5090808@emergence.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Sep 05, 2002 at 12:04:25AM -0600, Michael Best wrote: > Basically even with ext2/ext3, with the drive failing spectacularly, > it's pretty much game over for that drive. For gradual failures or "bad blocks in stasis" it would be nice to have the fs avoid these. > EVMS and LVM may have addressed this issue where the LVM/EVMS layer > is actually handling the physical disks and can reallocate bad > blocks on the fly. Arguably, you shouldn't need to use LVM to deal with bad blocks. Anyhow, this is getting rather OT. If XFS cannot deal with bad-blocks (I'm not talking about failing drives), then that is that and other means are required. --cw From owner-linux-xfs@oss.sgi.com Thu Sep 5 00:20:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 00:20:41 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g857KZtG019354 for ; Thu, 5 Sep 2002 00:20:36 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 8A5381431F; Thu, 5 Sep 2002 09:24:36 +0200 (MEST) Date: Thu, 5 Sep 2002 09:24:36 +0200 From: Andi Kleen To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? Message-ID: <20020905092436.A4780@wotan.suse.de> References: <1031165125.3056.18.camel@stout.americas.sgi.com> <20020905035940.GC6004@tapu.f00f.org> <3D76F3E9.5090808@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D76F3E9.5090808@emergence.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs > Basically even with ext2/ext3, with the drive failing spectacularly, > it's pretty much game over for that drive. EVMS and LVM may have > addressed this issue where the LVM/EVMS layer is actually handling the > physical disks and can reallocate bad blocks on the fly. EVMS has a BBR module for this. But I agree with Eric Sandeen on this - when your disk shows bad sectors and ran out of its internal remapping space you should get rid of it ASAP. -Andi From owner-linux-xfs@oss.sgi.com Thu Sep 5 09:40:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 09:41:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85GevtG025576 for ; Thu, 5 Sep 2002 09:40:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA27113 for ; Thu, 5 Sep 2002 11:44:59 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA10461 for ; Thu, 5 Sep 2002 11:44:59 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g85Gfjd05329; Thu, 5 Sep 2002 11:41:45 -0500 Message-Id: <200209051641.g85Gfjd05329@stout.americas.sgi.com> Date: Thu, 5 Sep 2002 11:41:45 -0500 Subject: TAKE - Remove mrquota/QUOTAMAYBE mount option X-archive-position: 280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs There was an undocumented "mrquota" mount option which essentially said "if quota is marked as being on in the superblock, enable quota on mount; don't enable it otherwise." This was really only for the IRIX miniroot environment and is unused in Linux, so take it out. Remove mrquota/QUOTAMAYBE mount option Date: Thu Sep 5 09:43:35 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126776a linux/fs/xfs/xfs_log_recover.c - 1.241 linux/fs/xfs/xfs_vfsops.c - 1.381 linux/fs/xfs/xfs_clnt.h - 1.34 linux/fs/xfs/xfs_qm.c - 1.83 linux/fs/xfs/xfs_quota.h - 1.29 linux/fs/xfs/linux/xfs_super.c - 1.212 From owner-linux-xfs@oss.sgi.com Thu Sep 5 10:57:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 10:57:20 -0700 (PDT) Received: from stumpy.chowhouse.com (root@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85HvGtG027475 for ; Thu, 5 Sep 2002 10:57:16 -0700 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.11.6/8.11.3) with ESMTP id g85I1Nl27737 for ; Thu, 5 Sep 2002 12:01:23 -0600 Date: Thu, 5 Sep 2002 12:01:23 -0600 (MDT) From: James Rich To: XFS mailing list Subject: update summary page Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 281 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@stumpy.chowhouse.com Precedence: bulk X-list: linux-xfs I've updated the CVS summary for August 27 - September 5. Quite a bit of work has been done during that period. If people feel there are some significant issues or important checkins that should be listed in the "Significant issues" section please let me know. The summary page is available at: http://www.chowhouse.com/~james/xfs/checklist.html James Rich From owner-linux-xfs@oss.sgi.com Thu Sep 5 11:52:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 11:52:56 -0700 (PDT) Received: from mailrtr1.mailzone.edeltacom.com (IDENT:mirapoint@mailrtr1.mailzone.edeltacom.com [216.248.176.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85IqntI029069 for ; Thu, 5 Sep 2002 11:52:51 -0700 Received: from Obkgrjd (66-0-27-113.deltacom.net [66.0.27.113]) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id ACQ88038; Thu, 5 Sep 2002 14:56:53 -0400 (EDT) Date: Thu, 5 Sep 2002 14:56:53 -0400 (EDT) Message-Id: <200209051856.ACQ88038@mailrtr1.mailzone.edeltacom.com> From: cbono To: linux-xfs@oss.sgi.com Subject: 980000) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Bq50vA3GEMK X-archive-position: 283 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cbono@protective.com Precedence: bulk X-list: linux-xfs --Bq50vA3GEMK Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on mailrtr1.mailzone.edeltacom.com) Found virus WORM_KLEZ.H in file alt.pif The uncleanable file was deleted. ********************************************************* --Bq50vA3GEMK Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --Bq50vA3GEMK Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ****************** Virus Warning Message (on mailrtr1.mailzone.edeltacom.com) alt.pif was removed from here because it contained a virus. ********************************************************* --Bq50vA3GEMK Content-Type: application/octet-stream; name=sinfest[1].htm Content-Transfer-Encoding: base64 Content-ID: PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50 LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt ZXRhIG5hbWU9IkF1dGhvciIgY29udGVudD0iVGF0c3V5YSBJc2hpZGEiPg0KICAgPG1ldGEg bmFtZT0iR0VORVJBVE9SIiBjb250ZW50PSJNb3ppbGxhLzQuNjEgW2VuXSAoV2luOTU7IEkp IFtOZXRzY2FwZV0iPg0KICAgPHRpdGxlPlNpbmZlc3Q8L3RpdGxlPg0KPC9oZWFkPg0KPGJv ZHkgdGV4dD0iI0ZGRkZGRiIgYmdjb2xvcj0iI0ZGRkZGRiIgbGluaz0iI0ZGRkZGRiIgdmxp bms9IiNGRkZGRkYiIGFsaW5rPSIjRkYwMDAwIiBiYWNrZ3JvdW5kPSJtYXV2ZV90aWxlLmdp ZiIgbGVmdG1hcmdpbj0wICByaWdodG1hcmdpbj0wICBtYXJnaW5oZWlnaHQ9MCAgbWFyZ2lu d2lkdGg9MCAgdG9wbWFyZ2luPTAgPgo8U0NSSVBUIExBTkdVQUdFPSJKYXZhU2NyaXB0Ij4K PCEtLQp2YXIgYXhlbCA9IE1hdGgucmFuZG9tKCkgKyAiIjsKdmFyIG9yZCA9IE1hdGgucm91 bmQoYXhlbCAqIDEwMDAwMDApOwovLyBUaGlzIHBhcnQgb2Ygc2NyaXB0IGFsbGV2aWF0ZXMg YSBOZXRzY2FwZSBkb2N1bWVudC53cml0ZSBidWcKTlM0ID0gZG9jdW1lbnQubGF5ZXJzOwpp ZiAoTlM0KSB7Cm9yaWdXaWR0aCA9IGlubmVyV2lkdGg7Cm9yaWdIZWlnaHQgPSBpbm5lckhl aWdodDsKfQpmdW5jdGlvbiByZURvKCkgewppZiAoaW5uZXJXaWR0aCAhPSBvcmlnV2lkdGgg fHwgaW5uZXJIZWlnaHQgIT0gb3JpZ0hlaWdodCkKbG9jYXRpb24ucmVsb2FkKCk7Cn0KaWYg KE5TNCkgb25yZXNpemUgPSByZURvOwovLy0tPgo8L1NDUklQVD4KICAgIAo8c2NyaXB0IGxh bmd1YWdlPSJqYXZhc2NyaXB0IiB0eXBlPSJ0ZXh0L2phdmFzY3JpcHQiPgo8IS0tCnZhciBh ZGNvb2tpZSA9ICIiOwp2YXIga2VlbmFkc2l6ZSA9ICJub3JtYWwiOwp2YXIgd2FycGVuYWJs ZWQgPSBmYWxzZTsKdmFyIGFkZnZhbGlkID0gZmFsc2U7CnZhciByZXBsYWQgPSAiIjsKdmFy IGFkYmFubG9jID0gIiI7CnZhciB3YXJwYWxpdmUgPSB0cnVlOwp2YXIgZ2F2emFkaWQgPSAi c2luZmVzdCI7Ci8vLS0+Cjwvc2NyaXB0Pgo8U0NSSVBUIExBTkdVQUdFPSJKQVZBU0NSSVBU IiBTUkM9Imh0dHA6Ly93d3cua2VlbnNwb3Qub3JnL3ByZW1pdW0tc2VydmljZXMvZ2V0Y29v a2llLmNnaSI+CjwvU0NSSVBUPgogPFNDUklQVCBMQU5HVUFHRT0iSkFWQVNDUklQVCI+CiA8 IS0tCmlmIChhZGNvb2tpZSAhPSAiIikgewogZG9jdW1lbnQud3JpdGUoIjxTIisiQ1JJUFQg TEFOR1VBR0U9J0pBVkFTQ1JJUFQnIFNSQz0naHR0cDovL3d3dy5rZWVuc3BvdC5vcmcvcHJl bWl1bS1zZXJ2aWNlcy9kZWNvb2tpZS5jZ2k/IitvcmQrIic+PC9TIisiQ1JJUFQ+Iik7CiBk b2N1bWVudC53cml0ZSgiPFMiKyJDUklQVCBMQU5HVUFHRT0nSkFWQVNDUklQVCcgU1JDPSdo dHRwOi8vd3d3LmtlZW5zcG90Lm9yZy9wcmVtaXVtL3dhcnBjaGVjay5qcyc+PC9TIisiQ1JJ UFQ+Iik7Cn0KIC8vLS0+CjwvU0NSSVBUPgogPFNDUklQVCBMQU5HVUFHRT0iSkFWQVNDUklQ VCI+CiA8IS0tCmlmICghYWRmdmFsaWQpIHsKIGRvY3VtZW50LndyaXRlKCI8UyIrIkNSSVBU IExBTkdVQUdFPSdKQVZBU0NSSVBUJyBTUkM9J2h0dHA6Ly9hZC5rZWVuc3BhY2UuY29tL2J1 cnN0Zm4uanMnPjxcL1MiKyJDUklQVD4iKTsKfQogLy8tLT4KPC9TQ1JJUFQ+CjxTQ1JJUFQg TEFOR1VBR0U9SmF2YVNjcmlwdD4KPCEtLQppZiAoYWRmdmFsaWQgIT0gdHJ1ZSkgIHsKICB2 YXIgSW50ZXJuZXRFeHBsb3JlciA9IG5hdmlnYXRvci5hcHBOYW1lLmluZGV4T2YoIk1pY3Jv c29mdCIpICE9IC0xOwogIC8vIEhhbmRsZSBhbGwgdGhlIHRoZSBGU0NvbW1hbmQgbWVzc2Fn ZXMgaW4gYSBGbGFzaCBtb3ZpZQogIGZ1bmN0aW9uIEJhbm5lck1lbnVfRG9GU0NvbW1hbmQo Y29tbWFuZCwgYXJncykgewogICAgdmFyIEJhbm5lck1lbnVPYmogPSBJbnRlcm5ldEV4cGxv cmVyID8gQmFubmVyTWVudSA6IGRvY3VtZW50LkJhbm5lck1lbnU7CiAgICAvLwogICAgaWYg KGNvbW1hbmQgPT0gMjgpIHsKICAgIE1haW5NZW51LnN0eWxlLnZpc2liaWxpdHk9J2hpZGRl bic7CiAgICB9CiAgICAvLwogIH0KICAvLyBIb29rIGZvciBJbnRlcm5ldCBFeHBsb3Jlcgog IGlmIChuYXZpZ2F0b3IuYXBwTmFtZSAmJiBuYXZpZ2F0b3IuYXBwTmFtZS5pbmRleE9mKCJN aWNyb3NvZnQiKSAhPSAtMSAmJgogICAgICAgICAgICBuYXZpZ2F0b3IudXNlckFnZW50Lmlu ZGV4T2YoIldpbmRvd3MiKSAhPSAtMSAmJiBuYXZpZ2F0b3IudXNlckFnZW50LmluZGV4T2Yo IldpbmRvd3MgMy4xIikgPT0gLTEgJiYgbmF2aWdhdG9yLnVzZXJBZ2VudC5pbmRleE9mKCJP cGVyYSIpID09IC0xKSB7CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgnPFMnKydDUklQVCBM QU5HVUFHRT1WQlNjcmlwdD4gXG4nKTsKICAgICAgICAgIGRvY3VtZW50LndyaXRlKCdvbiBl cnJvciByZXN1bWUgbmV4dCBcbicpOwogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJ1N1YiBC YW5uZXJNZW51X0ZTQ29tbWFuZChCeVZhbCBjb21tYW5kLCBCeVZhbCBhcmdzKVxuJyk7CiAg ICAgICAgICBkb2N1bWVudC53cml0ZSgnICBjYWxsIEJhbm5lck1lbnVfRG9GU0NvbW1hbmQo Y29tbWFuZCwgYXJncylcbicpOwogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJ2VuZCBzdWJc bicpOwogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJzxcL1MnKydDUklQVD4gXG4nKTsKICB9 CiAgCiAgdmFyIEludGVybmV0RXhwbG9yZXIgPSBuYXZpZ2F0b3IuYXBwTmFtZS5pbmRleE9m KCJNaWNyb3NvZnQiKSAhPSAtMTsKICAvLyBIYW5kbGUgYWxsIHRoZSB0aGUgRlNDb21tYW5k IG1lc3NhZ2VzIGluIGEgRmxhc2ggbW92aWUKICBmdW5jdGlvbiBCYW5uZXJfRG9GU0NvbW1h bmQoY29tbWFuZCwgYXJncykgewogICAgdmFyIEJhbm5lck9iaiA9IEludGVybmV0RXhwbG9y ZXIgPyBCYW5uZXIgOiBkb2N1bWVudC5CYW5uZXI7CiAgICAvLwogICAgaWYgKGNvbW1hbmQg PT0gMjAwKSB7CiAgCiAgICBNYWluTWVudS5zdHlsZS5waXhlbExlZnQ9MjIwOwogICAgTWFp bk1lbnUuc3R5bGUucGl4ZWxUb3A9MTA7CiAgCiAgICBNYWluTWVudS5zdHlsZS52aXNpYmls aXR5PScnOwogICAgfQogICAgLy8KICB9CiAgLy8gSG9vayBmb3IgSW50ZXJuZXQgRXhwbG9y ZXIKICBpZiAobmF2aWdhdG9yLmFwcE5hbWUgJiYgbmF2aWdhdG9yLmFwcE5hbWUuaW5kZXhP ZigiTWljcm9zb2Z0IikgIT0gLTEgJiYKICAgICAgICAgICAgbmF2aWdhdG9yLnVzZXJBZ2Vu dC5pbmRleE9mKCJXaW5kb3dzIikgIT0gLTEgJiYgbmF2aWdhdG9yLnVzZXJBZ2VudC5pbmRl eE9mKCJXaW5kb3dzIDMuMSIpID09IC0xICYmIG5hdmlnYXRvci51c2VyQWdlbnQuaW5kZXhP ZigiT3BlcmEiKSA9PSAtMSkgewogICAgICAgICAgZG9jdW1lbnQud3JpdGUoJzxTJysnQ1JJ UFQgTEFOR1VBR0U9VkJTY3JpcHQ+IFxuJyk7CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgn b24gZXJyb3IgcmVzdW1lIG5leHQgXG4nKTsKICAgICAgICAgIGRvY3VtZW50LndyaXRlKCdT dWIgQmFubmVyX0ZTQ29tbWFuZChCeVZhbCBjb21tYW5kLCBCeVZhbCBhcmdzKVxuJyk7CiAg ICAgICAgICBkb2N1bWVudC53cml0ZSgnICBjYWxsIEJhbm5lcl9Eb0ZTQ29tbWFuZChjb21t YW5kLCBhcmdzKVxuJyk7CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgnZW5kIHN1YlxuJyk7 CiAgICAgICAgICBkb2N1bWVudC53cml0ZSgnPFwvUycrJ0NSSVBUPiBcbicpOwogIH0KfQov Ly0tPgo8L1NDUklQVD4KPHRhYmxlIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxw YWRkaW5nPTIgd2lkdGg9IjEwMCUiIGJhY2tncm91bmQ9IiIgYmdjb2xvcj0iIzYwNmE2MCIg Ym9yZGVyY29sb3I9IiMwMDAwMDAiIGhlaWdodD0iMzAiIGhzcGFjZT0iMCIgdnNwYWNlPSIw Ij4KIDx0cj4KICAgPHRkIGFsaWduPSJsZWZ0IiB2YWxpZ249Im1pZGRsZSI+CiAgICAgPGEg aHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20iPjxpbWcgIHNyYz0iaHR0cDovL3d3dy5r ZWVuc3BvdC5vcmcvaW1hZ2VzL2hlYWRlci1rZWVuc3BvdGxvZ29fdHIuZ2lmIiBib3JkZXI9 IjAiIGhzcGFjZT0iMCIgd2lkdGg9IjEwMSIgaGVpZ2h0PSIyOCI+PC9hPgogICA8L3RkPjx0 ZD48c2NyaXB0IGxhbmd1YWdlPSJqYXZhc2NyaXB0Ij48IS0tCmlmKGFkZnZhbGlkID09IHRy dWUpIHsKIHZhciB3YXJwaW1hZ2UgPSAid2FycGRpc2FibGVkLmdpZiI7CiBpZighd2FycGFs aXZlKSB2YXIgd2FycGltYWdlID0gIndhcnBvdXQuZ2lmIjsKIGlmKHdhcnBlbmFibGVkICYm IHdhcnBhbGl2ZSkgdmFyIHdhcnBpbWFnZSA9ICJ3YXJwZW5nYWdlZC5naWYiOwogZG9jdW1l bnQud3JpdGUoJzxhIGhyZWY9IicrYWZiYW5sb2MrJyI+PGltZyBib3JkZXI9MCBzcmM9Imh0 dHA6Ly93d3cua2VlbnNwb3Qub3JnL3ByZW1pdW0vaW1hZ2VzLycrd2FycGltYWdlKyciPjwv YT4nKTsKfSBlbHNlIHsKZG9jdW1lbnQud3JpdGUoJyZuYnNwOycpOwp9Ci8vLS0+PC9zY3Jp cHQ+PG5vc2NyaXB0PiZuYnNwOzwvbm9zY3JpcHQ+PC90ZD48dGQgYWxpZ249Y2VudGVyIHZh bGlnbj0ibWlkZGxlIj4KICAgPGNlbnRlcj48aW1nIHNyYz1odHRwOi8vd3d3LmtlZW5zcG90 Lm9yZy9oZWFkZXItY29taWNsaW5raW1hZ2VzL2hlYWRlci10cnl0aGlzc3BvdC5naWY+PFND UklQVCBMQU5HVUFHRT0iSmF2YVNjcmlwdCI+CjwhLS0KdmFyIEtlZW5IZWFkZXJQaXggPSBu ZXcgQXJyYXkoImFsaWNlY29taWNzLmNvbSIsImFzaGZpZWxkb25saW5lLmNvbSIsImF2YWxv bmhpZ2guY29tIiwiYmF5c2lkLmNvbSIsImJvYmJpbnMub3JnIiwiYnJ1bm90aGViYW5kaXQu Y29tIiwiY2hvcHBpbmdibG9jay5vcmciLCJjbGFub2Z0aGVjYXRzLmNvbSIsImNvb2xjYXRz dHVkaW8uY29tIiwiY3JmaC5uZXQiLCJjdXRld2VuZHkuY29tIiwiZWxmbGlmZS5jb20iLCJl dmVyeXRoaW5namFrZS5jb20iLCJleHBsb2l0YXRpb25ub3cuY29tIiwiZmF0LWplc3VzLmNv bSIsImZ1bm55ZmFybWNvbWljcy5jb20iLCJnZW5lY2F0bG93LmNvbSIsImdwZi1jb21pY3Mu Y29tIiwiZ3JleXN0b25laW5uLm5ldCIsImhvdW5kc2hvbWUuY29tIiwiaXRzd2Fsa3kuY29t Iiwiam9lYXZlcmFnZS5vcmciLCJrZWVuc3BvdC5jb20iLCJrcmF6eWxhcnJ5LmNvbSIsImxp dmluZ2luZ3JleXRvd24uY29tIiwibG9va3doYXRpYnJvdWdodGhvbWUuY29tIiwibG9zdGFu ZGZvdW5kY29taWMuY29tIiwibWVsb25wb29sLmNvbSIsIm1yY2h1Y2tzaG93LmNvbSIsIm5l d3Nob3VuZHMuY29tIiwibnVrZWVzLmNvbSIsInBlbnRhc21hbC5jb20iLCJwb2lzb25lZG1p bmRzLmNvbSIsInJhZGNvbWljcy5jb20iLCJyZWFsbGlmZWNvbWljcy5jb20iLCJyb2Fkd2Fm Zmxlcy5jb20iLCJycGd3b3JsZGNvbWljLmNvbSIsInNjaGxvY2ttZXJjZW5hcnkuY29tIiwi c2luZmVzdC5uZXQiLCJzb2Fwcm9wZS5jb20iLCJzdWJ1cmJhbmp1bmdsZS5jb20iLCJzdXBl cm9zaXR5LmNvbSIsInRoZWNsYXNzbS5jb20iLCJ1YmVyc29mdC5uZXQiLCJ3YW5kZXJpbmdv bmVzLmNvbSIsIndoZW5pZ3Jvd3VwLm5ldCIsInlvdWRhbW5raWQuY29tIik7CnJhbmRvbU51 bSA9IE1hdGguZmxvb3IoTWF0aC5yYW5kb20oKSAqIDQ2KTsKZG9jdW1lbnQud3JpdGUoIjxh IGhyZWY9aHR0cDovL3d3dy4iKTsKZG9jdW1lbnQud3JpdGUoS2VlbkhlYWRlclBpeFtyYW5k b21OdW1dKTsKZG9jdW1lbnQud3JpdGUoIj48aW1nIGJvcmRlcj0wIHNyYz1odHRwOi8vd3d3 LmtlZW5zcG90Lm9yZy9oZWFkZXItY29taWNsaW5raW1hZ2VzL2NvbWljbGluay0iKTsKZG9j dW1lbnQud3JpdGUoS2VlbkhlYWRlclBpeFtyYW5kb21OdW1dKTsKZG9jdW1lbnQud3JpdGUo Ii5naWY+PC9hIik7CiAvLyAtLT4KPC9TQ1JJUFQ+PC9jZW50ZXI+PC90ZD48dGQgYWxpZ249 bWlkZGxlPjx0YWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTA+PHRk IHdpZHRoPTQwPjxhIGhyZWY9Imh0dHA6Ly93d3cua2VlbnNwb3QuY29tL2tzbmV3cy9rc25l d3MyMDAyMDcyNy5odG1sIj48aW1nIHdpZHRoPTQwIGhlaWdodD0yOCBib3JkZXI9MCBzcmM9 Imh0dHA6Ly93d3cua2VlbnNwb3QuY29tL2ltYWdlcy9rZWVubmV3c2xvZ28uZ2lmIj48L2E+ PC90ZD48dGQgd2lkdGg9OTA+PGEgaHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20va3Nu ZXdzL2tzbmV3czIwMDIwNzI3Lmh0bWwiPjxpbWcgYm9yZGVyPTAgd2lkdGg9OTAgaGVpZ2h0 PTI4IHNyYz0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20va3NuZXdzL2tlZW5uZXdzMjAwMjA3 MjcuZ2lmIj48L2E+PC90YWJsZT4KPC90ZD48dGQgYWxpZ249InJpZ2h0IiB2YWxpZ249Im1p ZGRsZSI+CjxUQUJMRSBCT1JERVI9IjAiIENFTExTUEFDSU5HPSIwIiBDRUxMUEFERElORz0i MCI+CjxTQ1JJUFQgTEFOR1VBR0U9IkphdmFzY3JpcHQiPgo8IS0tCiAgICAgICAgZnVuY3Rp b24ga2VlblN3aXRjaDIodXJsKSAgICAgICAgewogICAgICAgICAgICAgICAgaWYgKHVybCAh PSAnJykgIHsKICAgICAgICAgICAgICAgICAgICAgICAgdG9wLmxvY2F0aW9uLmhyZWYgPSB1 cmw7CiAgICAgICAgICAgICAgICB9CiAgICAgICAgfQovLy0tPgo8L1NDUklQVD4KPEZPUk0g QUNUSU9OPSJodHRwOi8vd3d3LmtlZW5zcG90LmNvbS9jZ2ktYmluL2Ryb3Bkb3duLmNnaSIg TUVUSE9EPSIiIE5BTUU9ImtlZW5TdHJpcCIgVEFSR0VUPSJjb21pY3dpbmRvdyI+CiAgICAg ICAgPFRSPjxURCBhbGlnbj0iY2VudGVyIj4KPGlucHV0IHR5cGU9aGlkZGVuIG5hbWU9ZG9t YWluIHZhbHVlPXd3dy5zaW5mZXN0Lm5ldD4KPFNFTEVDVCBOQU1FPSJzaXRlSW5kZXgiIG9u Q2hhbmdlPSJrZWVuU3dpdGNoMih0aGlzLm9wdGlvbnNbc2VsZWN0ZWRJbmRleF0udmFsdWUp OyI+CgogICAgICAgICAgICAgICAgPE9QVElPTiBWQUxVRT0iIiBTRUxFQ1RFRD5TZWxlY3Qg YSBTcG90IQo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnNpbmZlc3QubmV0LyI+U2luZmVz dAo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnNvYXByb3BlLmNvbS8iPlNvYXAgb24gYSBS b3BlCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuaG9va2Vkb25jb21pY3MuY29tLyI+U3Bv b25lcgo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnN1YnVyYmFuanVuZ2xlLmNvbS8iPlN1 YnVyYmFuIEp1bmdsZQo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LnN1cGVyb3NpdHkuY29t LyI+U3VwZXJvc2l0eQo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LndhbmRlcmluZ29uZXMu Y29tLyI+V2FuZGVyaW5nIE9uZXMKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy53ZW5keWNv bWljLmNvbS8iPldlbmR5CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cueW91ZGFtbmtpZC5j b20vIj5Zb3UgRGFtbiBLaWQKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5hc2hmaWVsZG9u bGluZS5jb20vIj4/CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuYWxpY2Vjb21pY3MuY29t LyI+QWxpY2UhCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuYXZhbG9uaGlnaC5jb20vIj5B dmFsb24KPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5ibG9vZGxhcmsuY29tLyI+Qmxvb2Rs YXJrCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuYm94amFtc2Rvb2RsZS5jb20vIj5Cb3hK YW0ncyBEb29kbGUKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5icnVub3RoZWJhbmRpdC5j b20vIj5CcnVubyB0aGUgQmFuZGl0CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuY3JmaC5u ZXQvIj5DUkZIISEhCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cuY2hvcHBpbmdibG9jay5v cmcvIj5DaG9wcGluZyBCbG9jawo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LmNsYW5vZnRo ZWNhdHMuY29tLyI+Q2xhbiBvZiB0aGUgQ2F0cwo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3 LnRoZWNsYXNzbS5jb20vIj5DbGFzcyBNZW5hZ2VyaWUKPE9QVElPTiBWQUxVRT0iaHR0cDov L3d3dy5jb29sY2F0c3R1ZGlvLmNvbS8iPkNvb2wgQ2F0IFN0dWRpbwo8T1BUSU9OIFZBTFVF PSJodHRwOi8vd3d3LkVsZkxpZmUuY29tLyI+RWxmIExpZmUKPE9QVElPTiBWQUxVRT0iaHR0 cDovL3d3dy5ldmVyeXRoaW5namFrZS5jb20vIj5FdmVyeXRoaW5nIEpha2UKPE9QVElPTiBW QUxVRT0iaHR0cDovL3d3dy5leHBsb2l0YXRpb25ub3cuY29tLyI+RXhwbG9pdGF0aW9uIE5v dwo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3LmZhYW5zLmNvbS8iPkZhbnMKPE9QVElPTiBW QUxVRT0iaHR0cDovL3d3dy5mYXQtamVzdXMuY29tLyI+RmF0IEplc3VzCjxPUFRJT04gVkFM VUU9Imh0dHA6Ly93d3cuZnVubnlmYXJtY29taWNzLmNvbS8iPkZ1bm55IEZhcm0KPE9QVElP TiBWQUxVRT0iaHR0cDovL3d3dy5ncGYtY29taWNzLmNvbS8iPkdQRgo8T1BUSU9OIFZBTFVF PSJodHRwOi8vd3d3LmdlbmVjYXRsb3cuY29tLyI+R2VuZSBDYXRsb3cKPE9QVElPTiBWQUxV RT0iaHR0cDovL3d3dy5ncmV5c3RvbmVpbm4ubmV0LyI+R3JleXN0b25lIElubgo8T1BUSU9O IFZBTFVFPSJodHRwOi8vd3d3LnViZXJzb2Z0Lm5ldC8iPkhlbHAgRGVzawo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3LmhvdW5kc2hvbWUuY29tLyI+SG91bmQncyBIb21lCjxPUFRJT04g VkFMVUU9Imh0dHA6Ly93d3cuaXRzd2Fsa3kuY29tLyI+SXQncyBXYWxreSEKPE9QVElPTiBW QUxVRT0iaHR0cDovL3d3dy5qdXN0YW5vdGhlcnZpY2UuY29tLyI+SnVzdCBBbm90aGVyIFZp Y2UKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5sb3N0YW5kZm91bmRjb21pYy5jb20vIj5M JkYgSW52ZXN0aWdhdGlvbnMKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5sb29rd2hhdGli cm91Z2h0aG9tZS5jb20vIj5MV0lCSCEKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5yYWRj b21pY3MuY29tLyI+TGlmZSdzIFNvIFJhZAo8T1BUSU9OIFZBTFVFPSJodHRwOi8vd3d3Lmxp emFyZGNvbWljcy5jb20vIj5MaXphcmQKPE9QVElPTiBWQUxVRT0iaHR0cDovL3d3dy5tZWxv bnBvb2wuY29tLyI+TWVsb25wb29sCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cubWVuaW5o YXRzLmNvbS8iPk1lbiBpbiBIYXRzCjxPUFRJT04gVkFMVUU9Imh0dHA6Ly90cmVhc3VyZWh1 bnRlcnMua2VlbnNwb3QuY29tLyI+TWluaS1TZXJpZXMgRXZlbnQKPE9QVElPTiBWQUxVRT0i aHR0cDovL3d3dy5tcmNodWNrc2hvdy5jb20vIj5Nci4gQ2h1Y2sgU2hvdwo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3Lm5ld3Nob3VuZHMuY29tLyI+TmV3c2hvdW5kcwo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3Lm51a2Vlcy5jb20vIj5OdWtlZXMKPE9QVElPTiBWQUxVRT0iaHR0 cDovL3d3dy5venlhbmRtaWxsaWUub3JnLyI+T3p5IGFuZCBNaWxsaWUKPE9QVElPTiBWQUxV RT0iaHR0cDovL3d3dy5ycGd3b3JsZGNvbWljLmNvbS8iPlJQRyBXb3JsZAo8T1BUSU9OIFZB TFVFPSJodHRwOi8vd3d3LnJlYWxsaWZlY29taWNzLmNvbS8iPlJlYWwgTGlmZQo8T1BUSU9O IFZBTFVFPSJodHRwOi8vd3d3LnBvaXNvbmVkbWluZHMuY29tLyI+Uy5TLkQuRC4KPE9QVElP TiBWQUxVRT0iaHR0cDovL3d3dy5zY2hsb2NrbWVyY2VuYXJ5LmNvbS8iPlNjaGxvY2sgTWVy Y2VuYXJ5CjxPUFRJT04gVkFMVUU9Imh0dHA6Ly93d3cubXJiYW5nLm5ldC8iPlNleCBhbmQg VmlvbGVuY2UKCjwvU0VMRUNUPjxOT1NDUklQVD48aW5wdXQgdHlwZT1zdWJtaXQgdmFsdWU9 IkdvISI+PC9OT1NDUklQVD4KICAgICAgICAgICAgICAgIDwvVEQ+CiAgICAgICAgPC9UUj4K PC9GT1JNPgo8L1RBQkxFPgoKCiAgIDwvdGQ+CiA8L3RyPgogPHRyPgogICA8dGQgY29sc3Bh bj01Pjx0YWJsZSBib3JkZXI9MCB3aWR0aD0xMDAlIGNlbGxwYWRkaW5nPTAgY2VsbHNwYWNp bmc9MCBiYWNrZ3JvdW5kPSJodHRwOi8vd3d3LmtlZW5zcG90Lm9yZy9oZWFkZXItY29taWNs aW5raW1hZ2VzL2hlYWRlci1saW5lLmdpZiIgaGVpZ2h0PTMgd2lkdGg9MTAwJT48dHI+PHRk PjxpbWcgc3JjPSJodHRwOi8vd3d3LmtlZW5zcG90Lm9yZy9pbWFnZXMvc3BhY2VyLmdpZiIg aGVpZ2h0PTMgd2lkdGg9Mz48L3RkPjwvdHI+PC90YWJsZT48L3RkPgogPC90cj4KPC90YWJs ZT4NCg0KDQoNCjxjZW50ZXI+PHRhYmxlIEJPUkRFUj0wIENFTExTUEFDSU5HPTAgQ0VMTFBB RERJTkc9MCA+DQo8dHI+DQo8dGQgV0lEVEg9IjQ2OCI+DQo8Y2VudGVyPgogPFNDUklQVCBM QU5HVUFHRT0iSkFWQVNDUklQVCI+CiA8IS0tCmlmIChhZGZ2YWxpZCA9PSB0cnVlKSB7CiBk b2N1bWVudC53cml0ZSgiPGEgaHJlZj0nIithZmJhbmxvYysiJz48aW1nIGJvcmRlcj0wIHdp ZHRoPTQ4NiBoZWlnaHQ9NjAgc3JjPSciK3JlcGxhZCsiJz48L2E+Iik7Cn0gZWxzZSB7Cgpp ZiAob3JkIDwgOTgwMDAwKSB7CmRvY3VtZW50LndyaXRlKCc8UycrJ0NSSVBUIFNSQz0iaHR0 cDovL2FkLmtlZW5zcGFjZS5jb20vYWRzZXJ2MTAuanM/c2luZmVzdCI+Jyk7CmRvY3VtZW50 LndyaXRlKCc8XC9TJysnQ1JJUFQ+Jyk7Cn0KCmlmIChvcmQgPj0gOTgwMDAwICYmIG9yZCA8 IDEwMDAwMDApIHsKZG9jdW1lbnQud3JpdGUoJzxTJysnQ1JJUFQgU1JDPSJodHRwOi8vYWQu a2VlbnNwYWNlLmNvbS9hZHNlcnYzMS5qcz9zaW5mZXN0Ij4nKTsKZG9jdW1lbnQud3JpdGUo JzxcL1MnKydDUklQVD4nKTsKfQogIAp9CiAvLy0tPgogPC9TQ1JJUFQ+Cgo8bm9zY3JpcHQ+ PGEgaHJlZj0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vYWRzL2FkODIyM2EtbWFwLmNnaS9u cyIgdGFyZ2V0PSJfdG9wIj48aW1nIHNyYz0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vY2dp LWJpbi9hZHMvYWQ4MjIzYS5jZ2kvbnMiIHdpZHRoPSI0NjgiIGhlaWdodD0iNjAiIGJvcmRl cj0iMCIgYWx0PSJDbGljayBIZXJlIj48L2E+Cjwvbm9zY3JpcHQ+CiAgPC9jZW50ZXI+DQo8 L3RkPg0KPC90cj4NCjwvdGFibGU+PC9jZW50ZXI+DQoNCjxjZW50ZXI+PHRhYmxlIEJPUkRF Uj0wIENFTExTUEFDSU5HPTAgQ0VMTFBBRERJTkc9MCBDT0xTPTcgV0lEVEg9IjQ2OCIgQkdD T0xPUj0iIzkzOENCRiIgPHRhYmxlID4NCjx0cj4NCjx0ZD4NCjxjZW50ZXI+PGZvbnQgZmFj ZT0iQXJpYWwgQmxhY2siPjxmb250IHNpemU9LTI+PGEgaHJlZj0iaHR0cDovL3NpbmZlc3Qu bmV0L3N0cmlwc19wYWdlLmh0bSI+c3RyaXBzPC9hPjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+ DQo8L3RkPg0KDQo8dGQgQkdDT0xPUj0iIzZGOTFCNyI+DQo8Y2VudGVyPjxmb250IGZhY2U9 IkFyaWFsIEJsYWNrIj48Zm9udCBzaXplPS0yPjxhIGhyZWY9Imh0dHA6Ly9zaW5mZXN0Lm5l dC9jYXN0Lmh0bSI+Y2FzdDwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkIEJHQ09MT1I9IiNDRUIzRUMiPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJBcmlhbCBCbGFj ayI+PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJodHRwOi8vc2luZmVzdC5uZXQvZ2FsbGVyeV9w YWdlLmh0bSI+Z2FsbGVyeTwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48 YSBocmVmPSJodHRwOi8vc2luZmVzdC5uZXQvbGlua3MuaHRtIj5saW5rczwvYT48L2ZvbnQ+ PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkIEJHQ09MT1I9IiM3QUE3QjQiPg0KPGNl bnRlcj48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJo dHRwOi8vZm9ydW1zLmtlZW5zcG90LmNvbS92aWV3Zm9ydW0ucGhwP2ZvcnVtPTI2JjExNjg0 MSI+Zm9ydW08L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZCBCR0NP TE9SPSIjNEU4QUE3Ij4NCjxjZW50ZXI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250 IHNpemU9LTI+PGEgaHJlZj0ibWFpbHRvOm1ycGludEBob3RtYWlsLmNvbSI+ZS1tYWlsPC9h PjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxmb250 IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBzaXplPS0yPjxhIGhyZWY9Imh0dHA6Ly93d3cu Y2FmZXByZXNzLmNvbS9zaW5mZXN0Ij5zdG9yZTwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVy Pg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8YnI+Jm5ic3A7DQo8Y2Vu dGVyPjx0YWJsZSBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgV0lEVEg9IjM2MCIgPg0K PHRyPg0KPHRkIEFMSUdOPVJJR0hUIFZBTElHTj1UT1A+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxp bWcgU1JDPSJzbGljay5naWYiIGhlaWdodD0xNDMgd2lkdGg9Nzc+PC9kaXY+DQo8L3RkPg0K DQo8dGQgVkFMSUdOPVRPUCBXSURUSD0iMjc3Ij4NCjxjZW50ZXI+PGltZyBTUkM9InNpbmZl c3RfbG9nby5naWYiIGhlaWdodD04NiB3aWR0aD0yMjc+DQo8YnI+PHU+PGZvbnQgZmFjZT0i Q291cmllciBOZXcsQ291cmllciI+PGZvbnQgY29sb3I9IiNGRkZGQ0MiPlQgQSBUIFMgVQ0K WSBBJm5ic3A7Jm5ic3A7IEkgUyBIIEkgRCBBPC9mb250PjwvZm9udD48L3U+DQo8YnI+PGZv bnQgZmFjZT0iSGFldHRlbnNjaHdlaWxlciI+PGZvbnQgY29sb3I9IiMwMDAwMDAiPlByZXNp ZGVudCwgQ0VPLA0KUmV2b2x1dGlvbmFyeTwvZm9udD48L2ZvbnQ+DQo8L2NlbnRlcj4NCjwv dGQ+DQo8L3RyPg0KPC90YWJsZT48L2NlbnRlcj4NCg0KPGJyPiZuYnNwOw0KPGNlbnRlcj48 dGFibGUgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0wIFdJRFRIPSI1NDUiID4NCjx0cj4N Cjx0ZCBBTElHTj1SSUdIVCBWQUxJR049VE9QIFdJRFRIPSIxNzgiPg0KPGNlbnRlcj48Yj48 Zm9udCBjb2xvcj0iI0ZGQ0NGRiI+PGZvbnQgc2l6ZT0rMz5+PC9mb250PjwvZm9udD48L2I+ DQo8YnI+PGI+PGk+PGZvbnQgZmFjZT0iR2FyYW1vbmQiPjxmb250IGNvbG9yPSIjRkZDQ0ZG Ij5JbmNvbmNlaXZhYmxlITwvZm9udD48L2ZvbnQ+PC9pPjwvYj4NCjxicj48Yj48Zm9udCBm YWNlPSJHYXJhbW9uZCI+PGZvbnQgY29sb3I9IiNGRkNDRkYiPjxmb250IHNpemU9KzM+fjwv Zm9udD48L2ZvbnQ+PC9mb250PjwvYj48L2NlbnRlcj4NCg0KPHA+PGJyPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48YSBocmVm PSJodHRwOi8vc2luZmVzdC5uZXQvc3RyaXBzX3BhZ2UuaHRtIj5zdHJpcHMmbmJzcDs8L2E+ PC9mb250PjwvZm9udD48L2Rpdj4NCg0KPGJyPiZuYnNwOw0KPGNlbnRlcj4NCjxwPjxmb250 IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBzaXplPS0yPjxhIGhyZWY9Im1haWx0bzptcnBp bnRAaG90bWFpbC5jb20iPmUtbWFpbCZuYnNwOzwvYT48L2ZvbnQ+PC9mb250PjxhIGhyZWY9 Im1haWx0bzptcnBpbnRAaG90bWFpbC5jb20iPjxpbWcgU1JDPSJkZXZpbF9wdXBwZXRfcGFu ZWwuZ2lmIiBoZWlnaHQ9MTEyIHdpZHRoPTg3IGFsaWduPUNFTlRFUj48L2E+PC9jZW50ZXI+ DQoNCjxwPjxicj4NCjxkaXYgYWxpZ249cmlnaHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5jYWZl cHJlc3MuY29tL3NpbmZlc3QiPjxpbWcgU1JDPSJkZXZpbHN0b3JlLmdpZiIgQk9SREVSPTAg aGVpZ2h0PTE2NyB3aWR0aD0xMDIgYWxpZ249VEVYVFRPUD48L2E+PC9kaXY+DQo8L3RkPg0K DQo8dGQgVkFMSUdOPUNFTlRFUiBXSURUSD0iMTU1Ij48YSBocmVmPSJodHRwOi8vc2luZmVz dC5uZXQvc3RyaXBzX3BhZ2UuaHRtIj48aW1nIFNSQz0iaGFwcHlfZmFkZS5naWYiIEJPUkRF Uj0wIGhlaWdodD0xOTcgd2lkdGg9MTU1IGFsaWduPUFCU0NFTlRFUj48L2E+DQo8cD48Zm9u dCBmYWNlPSJBcmlhbCBCbGFjayI+PGZvbnQgc2l6ZT0tMj48YSBocmVmPSJodHRwOi8vZm9y dW1zLmtlZW5zcG90LmNvbS92aWV3Zm9ydW0ucGhwP2ZvcnVtPTI2JjExNjg0MSI+Zm9ydW0m bmJzcDs8L2E+PC9mb250PjwvZm9udD48YSBocmVmPSJodHRwOi8vZm9ydW1zLmtlZW5zcG90 LmNvbS92aWV3Zm9ydW0ucGhwP2ZvcnVtPTI2JjExNjg0MSI+PGltZyBTUkM9Im1vbmlxdWUu R0lGIiBCT1JERVI9MCBoZWlnaHQ9MjEyIHdpZHRoPTc3IGFsaWduPVRFWFRUT1A+PC9hPg0K PHA+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IHNpemU9LTI+PGEgaHJlZj0iaHR0 cDovL3d3dy5jYWZlcHJlc3MuY29tL3NpbmZlc3QiPiZuYnNwO3N0b3JlPC9hPjwvZm9udD48 L2ZvbnQ+DQo8cD4mbmJzcDs8L3RkPg0KDQo8dGQgVkFMSUdOPVRPUD4NCjx0YWJsZSBDRUxM UEFERElORz0wIENPTFM9MSBXSURUSD0iMTAwJSIgPg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48 c3ViPjxmb250IGZhY2U9IkFyaWFsIEJsYWNrIj48Zm9udCBjb2xvcj0iIzY2MzM2NiI+PGZv bnQgc2l6ZT0tMT5ub3Rlcw0KZnJvbTwvZm9udD48L2ZvbnQ+PC9mb250Pjwvc3ViPjwvY2Vu dGVyPg0KPC90ZD4NCjwvdHI+DQoNCjx0cj4NCjx0ZCBCR0NPTE9SPSIjNjYzMzY2Ij4NCjxj ZW50ZXI+PGZvbnQgY29sb3I9IiNGRkZGMDAiPjxiPjxzdXA+VEhFPC9zdXA+PC9iPjxpPjxm b250IGZhY2U9IkltcGFjdCI+PGZvbnQgc2l6ZT0rMj5SDQpFIFMgSSBTIFQgQSBOIEMgRSA6 Jm5ic3A7PC9mb250PjwvZm9udD48L2k+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+ DQoNCjx0cj4NCjx0ZD48Zm9udCBjb2xvcj0iI0NDRkZGRiI+DQo8aT5PbiBsaWZlLjwvaT4g QXQgYW55IGdpdmVuIHBvaW50IGluIGxpZmUsIHlvdSdyZSBlaXRoZXIgaW4gdHJhaW5pbmcg DQpvciB5b3UncmUgaW4gdGhlIHRyZW5jaGVzLiBZb3UncmUgZWl0aGVyIGxlYXJuaW5nIHRo ZSByb3BlcyBvciBwYXZpbmcgDQp0aGUgd2F5LiBZb3UncmUgYnVzeSBzZWFyY2hpbmcgb3Ig YnVzeSByZWFsaXppbmcuIEFuZCBtb3N0IG9mIHVzIGFyZQ0KdHJhaW5lZXMsIGJ1c2ggbGVh Z3VlcnMsIFBhZGF3YW4gbGVhcm5lcnMgbm90IHlldCBhbGxvd2VkIHRvIA0Kc2l0IGF0IHRo ZSBKZWRpIHRhYmxlLiBXZSB1c2Uga2lkcHJvb2YgbGlnaHQgc2FiZXJzLiBTaW11bGF0ZSBi YXR0bGVzDQppbiB0aGUgRGFuZ2VyIFJvb20uIFJpZGUgd2l0aCB0cmFpbmluZyB3aGVlbHMu IFByYWN0aWNlLCBwcmFjdGljZSwgDQpwcmFjdGljZS4gQW5kIHdlJ3JlIGFsbCBzbyBpbXBh dGllbnQgdG8gZW5nYWdlIHdpdGggdGhlDQpyZWFsIHdvcmxkLCBlYWdlciB0byBjaGFuZ2Ug dGhpbmdzIGFuZCBtYWtlIGV2ZXJ5dGhpbmcgcGVyZmVjdCBmb3JldmVyLg0KQW5kIGluIG91 ciBoYXN0ZSB3ZSBkZWZ5IG91ciBoaWdoZXItdXBzLCBzZXQgb2ZmIGZvciB0aGUgYmlnIGJh ZCANCndvcmxkLCBhbmQgcm91bmRseSBnZXQgb3VyIGFzc2VzIHdoaXBwZWQuIEFuZCBldmVy eSBvbmUgb2YgdXMsIHNvb25lcg0Kb3IgbGF0ZXIsIGVuZCB1cCBiYWNrIGluIHNjaG9vbC4N CkJ1dCBhaW4ndCBubyBzaGFtZSBpbiB0aGF0LiBUaGF0J3MgdGhlIHdheSBvZiB0aGUgd29y bGQsIHRoZSBjaXJjbGUNCm9mIGxpZmUsIHRoZSBtYXN0ZXIgcGxhbiwgeW91IGRpZz8NCjxi cj4tVC4gDQo8YnI+PGZvbnQgZmFjZT0iQXJpYWwgQmxhY2siPjxmb250IHNpemU9LTI+PGEg aHJlZj0iaHR0cDovL3NpbmZlc3QubmV0L3Jlc2lzdGFuY2UuaHRtIj5tb3JlDQpyZXNpc3Rh bmNlPC9hPjwvZm9udD48L2ZvbnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KPC90ZD4NCjwv dHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8YnI+Jm5ic3A7DQo8Y2VudGVyPjx0YWJsZSBC T1JERVI9MCBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgV0lEVEg9IjU1MCIgQ09MPSIy IiA+DQo8dHI+DQo8dGQ+Jm5ic3A7DQo8ZGl2IEFMSUdOPXJpZ2h0Pjx0YWJsZSBCT1JERVI9 MyBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgV0lEVEg9IjMzMCIgPg0KPHRyPg0KPHRk IEJHQ09MT1I9IiNGRjAwMDAiPg0KPGNlbnRlcj48Yj48dT48Zm9udCBmYWNlPSJBcmlhbCBC bGFjayI+PGZvbnQgY29sb3I9IiNGRkZGMDAiPjxmb250IHNpemU9KzI+RlVUSUxJVFkNCldB VENIPC9mb250PjwvZm9udD48L2ZvbnQ+PC91PjwvYj4NCjxicj48Zm9udCBmYWNlPSJBcmlh bCxIZWx2ZXRpY2EiPjxmb250IGNvbG9yPSIjQ0NGRkZGIj48Zm9udCBzaXplPS0yPlRyYWNr aW5nDQp0aGUgbnVtYmVyIG9mIHRpbWVzIFRhdHN1eWEgZ2V0cyByZWplY3RlZCBieSB0aGUg c3luZGljYXRlcywgdGh1cyByZWFmZmlybWluZw0KaGlzIHN0YXR1cyBhcyBhIHJlbmVnYWRl IGZvbGsgaGVyby4mbmJzcDs8L2ZvbnQ+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+ DQoNCjx0ZCBXSURUSD0iNzAiIEJHQ09MT1I9IiNGRkZGOTkiPg0KPGNlbnRlcj48Zm9udCBj b2xvcj0iI0ZGMDAwMCI+PGZvbnQgc2l6ZT0rND4xMTwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+ DQo8L3RkPg0KPC90cj4NCjwvdGFibGU+PC9kaXY+DQo8L3RkPg0KDQo8dGQ+DQo8Y2VudGVy PjxiPjxmb250IGZhY2U9IlZlcmRhbmEiPjxmb250IGNvbG9yPSIjRkZGRjgyIj48Zm9udCBz aXplPS0xPlNpbmZlc3QNCkhvbWUgRGVsaXZlcnk8L2ZvbnQ+PC9mb250PjwvZm9udD48L2I+ DQo8YnI+Cjx0YWJsZT48dHI+PHRkPgo8Zm9ybSBuYW1lPWVtYWlsbGlzdCBhY3Rpb249Imh0 dHA6Ly93d3cua2VlbnNwb3QuY29tL2NnaS1iaW4vc2VuZHN1YmluZm8uY2dpIj4KPGlucHV0 IHR5cGU9aGlkZGVuIG5hbWU9Y29taWNsaXN0IHZhbHVlPXNpbmZlc3QtZGFpbHk+CjxpbnB1 dCBuYW1lPWVtYWlsIHZhbHVlPSJFbnRlciBFLU1haWwhIiBzaXplPTEzPgo8aW5wdXQgdHlw ZT1zdWJtaXQgdmFsdWU9InN1YnNjcmliZSI+CjwvdGQ+PC90cj4KPC9mb3JtPgo8L3RhYmxl PgogICAgPC9jZW50ZXI+DQo8L3RkPg0KPC90cj4NCjwvdGFibGU+PC9jZW50ZXI+DQoNCjxi cj4mbmJzcDsNCjxjZW50ZXI+PHRhYmxlIEJPUkRFUj0wIENFTExTUEFDSU5HPTAgQ0VMTFBB RERJTkc9MCBDT0xTPTIgV0lEVEg9IjcyMCIgPg0KPHN1Yj48Zm9udCBzaXplPSsxPjxmb250 IGZhY2U9IlRpbWVzIE5ldyBSb21hbixUaW1lcyI+PGZvbnQgY29sb3I9IiM2NkZGRkYiPlRP REFZJ1MNClNUUklQOiZuYnNwOyA8L2ZvbnQ+PC9mb250Pjxmb250IGZhY2U9IkdhcmFtb25k Ij48Zm9udCBjb2xvcj0iI0NDRkZGRiI+VGh1cnNkYXksIFNlcHRlbWJlciA1LCAyMDAyPC9m b250PjwvZm9udD48L2ZvbnQ+PC9zdWI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8Y2VudGVy Pjx0YWJsZSBCT1JERVI9MyBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgQ09MUz0yIFdJ RFRIPSI3MjAiID4NCjx0cj4NCjx0ZCBXSURUSD0iNzAwIiBCR0NPTE9SPSIjRkZGRkZGIj48 Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNjcmlwdCBsYW5ndWFnZT0iSkFWQVNDUklQVCI+Cjwh LS0KdmFyIHdhcnBlbmFibGVkOwp2YXIgd2FycGFsaXZlOwppZiAoYWRmdmFsaWQgPT0gdHJ1 ZSAmJiB3YXJwZW5hYmxlZCA9PSB0cnVlICYmIHdhcnBhbGl2ZSA9PSB0cnVlKSB7CiBkb2N1 bWVudC53cml0ZSgnPElNRyBBTFQ9ImNvbWljIiBCT1JERVI9MCBTUkM9Imh0dHA6Ly9zaW5m ZXN0LndhcnBrZWVuLmNvbS9jb21pY3Mvc2YyMDAyMDkwNS5naWYiIEhFSUdIVD0iMjc2IiBX SURUSD0iNjY1Ij4nKTsKfSBlbHNlIHsKIGRvY3VtZW50LndyaXRlKCc8SU1HIEFMVD0iY29t aWMiIEJPUkRFUj0wIFNSQz0iL2NvbWljcy9zZjIwMDIwOTA1LmdpZiIgSEVJR0hUPSIyNzYi IFdJRFRIPSI2NjUiPicpOwp9Ci8vLS0+Cjwvc2NyaXB0Pgo8bm9zY3JpcHQ+CjxJTUcgQUxU PSJjb21pYyIgQk9SREVSPTAgU1JDPSIvY29taWNzL3NmMjAwMjA5MDUuZ2lmIiBIRUlHSFQ9 IjI3NiIgV0lEVEg9IjY2NSI+Cjwvbm9zY3JpcHQ+CjwvZm9udD4NCjxicj48Zm9udCBmYWNl PSJUYWhvbWEiPjxmb250IGNvbG9yPSIjMDAwMDAwIj48Zm9udCBzaXplPS0yPkNPUFlSSUdI VCZjb3B5OzIwMDINClNJTkZFU1QgUFJPRFVDVElPTlMvQWxsIHJpZ2h0cyByZXNlcnZlZCwg YmFieS48L2ZvbnQ+PC9mb250PjwvZm9udD48L3RkPg0KDQo8dGQgQkdDT0xPUj0iIzAwMDAw MCIgbGluaz0iI0ZGRkZGRiIgdmxpbms9IiNGRkZDQ0MiIGFsaW5rPSIjRkZDQzAwIj4NCjxj ZW50ZXI+PGZvbnQgY29sb3I9IiNGRkZGRkYiPjxhIGhyZWY9Ii9kLzIwMDAwMTE3Lmh0bWwi PlRoZSBmaXJzdCBjb21pYzwvYT48L2ZvbnQ+DQo8cD48Zm9udCBjb2xvcj0iI0ZGRkZGRiI+ PGEgaHJlZj0iL2QvMjAwMjA5MDQuaHRtbCI+UHJldmlvdXMgY29taWM8L2E+PC9mb250Pjwv Y2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQoNCjxicj48YnI+ DQo8Y2VudGVyPjx0YWJsZSBDRUxMU1BBQ0lORz0wIENFTExQQURESU5HPTAgQ09MUz0yIFdJ RFRIPSI1MDAiID4NCjx0cj4NCjx0ZD4NCjxjZW50ZXI+DQo8dGFibGUgYm9yZGVyPSIxIiB3 aWR0aD0iMTc1Ij4KICAgIDx0cj4KICAgICAgICA8dGQgYmdjb2xvcj0iV0hJVEUiPjxwIGFs aWduPSJjZW50ZXIiPjxhCiAgICAgICAgaHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20i Pjxmb250IGNvbG9yPSIjRkZGRkZGIj48c3Ryb25nPjxpbWcKICAgICAgICBzcmM9Imh0dHA6 Ly9rZWVuc3BvdC5jb20vZGF0YS9uZXdzbGlnaHRsb2dvLmdpZiIKICAgICAgICBib3JkZXI9 IjAiIHdpZHRoPSIxNTciIGhlaWdodD0iMjgiPjwvc3Ryb25nPjwvZm9udD48L2E+PC9wPgog ICAgICAgIDwvdGQ+CiAgICA8L3RyPgogICAgPHRyPgogICAgICAgIDx0ZCBiZ2NvbG9yPSIj MDAwMDAwIj48cCBhbGlnbj0iY2VudGVyIj48Zm9udAogICAgICAgIGNvbG9yPSJ3aGl0ZSIg c2l6ZT0iMiIgZmFjZT0iQXJpYWwiPjxzdHJvbmc+UEFSVFknUyBPVkVSLjwvc3Ryb25nPjwv Zm9udD48Zm9udAogICAgICAgIGNvbG9yPSIjRkZDQzAwIiBzaXplPSIxIiBmYWNlPSJBcmlh bCI+PHN0cm9uZz48YnI+CiAgICAgICAgPC9zdHJvbmc+PC9mb250PjxhCiAgICAgICAgaHJl Zj0iaHR0cDovL3d3dy50aGVjbGFzc20uY29tL2QvMjAwMjA4MjYuaHRtbCI+PGltZwogICAg ICAgIHNyYz0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20vZGF0YS9uZXdzLWNsYXNzbWVuYWdl cmllLXNlcDAyLmdpZiIKICAgICAgIGJvcmRlcj0wPjwvYT48YnI+CgoKPGZvbnQKICAgICAg ICBjb2xvcj0id2hpdGUiIHNpemU9IjEiIGZhY2U9IkFyaWFsIj5UaGUgYmVsZWFndWVyZWQg RGVNb250Zm9ydApjYW1wdXMgPC9mb250Pjxmb250CiAgICAgICAgY29sb3I9IndoaXRlIiBz aXplPSIxIiBmYWNlPSJBcmlhbCI+PGEgaHJlZj0iaHR0cDovL3d3dy50aGVjbGFzc20uY29t L2QvMjAwMjA3MTUuaHRtbCI+bXVzaWNhbDwvYT4gaGFzIHN1cnZpdmVkCm1pc2Nhc3Rpbmcs IGluZmlnaHRpbmcsIGFuZCBhIHJpZGljdWxvdXNseSBoaWdoIGNvcHkgYnVkZ2V0LiAgQnV0 IHRoZSBiaWdnZXN0CnRocmVhdCB5ZXQgbm93IHN0cmlrZXMgaW4gYSBkYXJrIGFsbGV5d2F5 LiAgV2lsbCB0aGUgc2hvdyBnbyBvbj88L2ZvbnQ+PC9hPgogICAgICAgIAogICAgICAgIDwv dGQ+CiAgICA8L3RyPgo8L3RhYmxlPjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRl cj48YSBocmVmPSJodHRwOi8vd3d3LnRvcHNpdGVsaXN0cy5jb20vYmVzdHNpdGVzL2NvbWlj c3RyaXAvdG9wc2l0ZXMuY2dpP0lEPTEwMSI+PGltZyBTUkM9InRvcDEwMGNvbWljc3RyaXAu Z2lmIiBCT1JERVI9MCBoZWlnaHQ9MTIyIHdpZHRoPTEwOD48L2E+DQo8cD48YSBocmVmPSJo dHRwOi8vd3d3LmJpZ3BhbmRhLm5ldC8iPjxpbWcgU1JDPSJ0b3AuZ2lmIiBCT1JERVI9MCBo ZWlnaHQ9NjQgd2lkdGg9NjQ+PC9hPg0KPHA+PGEgaHJlZj0iaHR0cDovL3d3dy50aGVmdW5u eXBhcGVycy5jb20vdG9wY2dpL3RvcHNpdGVzLmNnaT9zaW5mZXN0IiBUQVJHRVQ9Il9CTEFO SyI+PGltZyBTUkM9ImZwdm90ZTMuZ2lmIiBCT1JERVI9MCA+PC9hPjwvY2VudGVyPg0KPC90 ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8Y2VudGVyPg0KPHA+PGltZyBTUkM9 InRpbnlfbG9nby5naWYiIGhlaWdodD02NSB3aWR0aD0xMTQ+PC9jZW50ZXI+DQoNCjxjZW50 ZXI+PHRhYmxlIENFTExTUEFDSU5HPTAgQ0VMTFBBRERJTkc9MCBDT0xTPTcgV0lEVEg9IjQw MCIgPg0KPHRyPg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250IHNp emU9LTE+PGEgaHJlZj0iaHR0cDovL3NpbmZlc3QubmV0L3N0cmlwc19wYWdlLmh0bSI+c3Rh c2g8L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4NCjxjZW50ZXI+ PGZvbnQgZmFjZT0iSW1wYWN0Ij48Zm9udCBzaXplPS0xPjxhIGhyZWY9Imh0dHA6Ly9zaW5m ZXN0Lm5ldC9jYXN0Lmh0bSI+Y3JldzwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90 ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250IHNpemU9LTE+ PGEgaHJlZj0iaHR0cDovL3NpbmZlc3QubmV0L2dhbGxlcnlfcGFnZS5odG0iPmphbTwvYT48 L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBm YWNlPSJJbXBhY3QiPjxmb250IHNpemU9LTE+PGEgaHJlZj0iaHR0cDovL3NpbmZlc3QubmV0 L2xpbmtzLmh0bSI+cGx1ZzwvYT48L2ZvbnQ+PC9mb250PjwvY2VudGVyPg0KPC90ZD4NCg0K PHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250IHNpemU9LTE+PGEgaHJl Zj0iaHR0cDovL2ZvcnVtcy5rZWVuc3BvdC5jb20vdmlld2ZvcnVtLnBocD9mb3J1bT0yNiYx MTY4NDEiPnJhdmU8L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQoNCjx0ZD4N CjxjZW50ZXI+PGZvbnQgZmFjZT0iSW1wYWN0Ij48Zm9udCBzaXplPS0xPjxhIGhyZWY9Im1h aWx0bzptcnBpbnRAaG90bWFpbC5jb20iPnBvc3RhbDwvYT48L2ZvbnQ+PC9mb250PjwvY2Vu dGVyPg0KPC90ZD4NCg0KPHRkPg0KPGNlbnRlcj48Zm9udCBmYWNlPSJJbXBhY3QiPjxmb250 IHNpemU9LTE+PGEgaHJlZj0iaHR0cDovL3d3dy5jYWZlcHJlc3MuY29tL3NpbmZlc3QiPnBp bXA8L2E+PC9mb250PjwvZm9udD48L2NlbnRlcj4NCjwvdGQ+DQo8L3RyPg0KPC90YWJsZT48 L2NlbnRlcj4NCg0KPGNlbnRlcj48Zm9udCBjb2xvcj0iI0ZGQ0MzMyI+PGZvbnQgc2l6ZT0t MT5Db3B5cmlnaHQgJmNvcHk7IDIwMDEgYnkgU2luZmVzdA0KUHJvZHVjdGlvbnMuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuPC9mb250PjwvZm9udD4NCg0KPGNlbnRlcj48dGFibGUgQk9SREVS PTAgQ0VMTFNQQUNJTkc9MCBDRUxMUEFERElORz0wID4NCjx0cj4NCjx0ZCBXSURUSD0iNDY4 Ij4NCjxjZW50ZXI+CjxzY3JpcHQ+CjwhLS0KaWYgKCFhZGZ2YWxpZCkgewpkb2N1bWVudC53 cml0ZSgnPFMnKydDUklQVCBTUkM9Imh0dHA6Ly9hZC5rZWVuc3BhY2UuY29tL2Fkc2VydjEx LmpzP3NpbmZlc3QiPjxcL1MnKydDUklQVD4nKTsKfQovLyAtLT48L3NjcmlwdD4KPG5vc2Ny aXB0Pgo8aWZyYW1lIFNSQz0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vY2dpLWJpbi9hZHMv YmE4MjIzYS5jZ2kvUkVUVVJOLUNPREUvaWYvNDk3NTAwLyIgc2Nyb2xsaW5nPSJubyIgbWFy Z2lud2lkdGg9IjAiIG1hcmdpbgpoZWlnaHQ9IjAiIGZyYW1lYm9yZGVyPSIwIiB2c3BhY2U9 IjAiIGhzcGFjZT0iMCIgd2lkdGg9IjQ2OCIgaGVpZ2h0PSI2MCI+CjxBIHRhcmdldD0iX3Rv cCIgSFJFRj0iaHR0cDovL3d3dy5idXJzdG5ldC5jb20vYWRzL2JhODIyM2EtbWFwLmNnaS80 OTc1MDAiPjxJTUcgU1JDPSJodHRwOi8vd3d3LmJ1cnN0bmV0LmNvbS9jZ2ktYmluL2Fkcy9i YTgyMjNhLmNnaS80OTc1MDAiIGJvcmRlcj0iMCIgd2lkdGg9IjQ2OCIgaGVpZ2h0PSI2MCIg YWx0PSJQbGVhc2Ugc3VwcG9ydCBvdXIgc3BvbnNvci4iPgo8L2E+PC9pZnJhbWU+Cjwvbm9z Y3JpcHQ+CjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPjwvY2VudGVyPg0KDQo8 Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxmb250IHNpemU9LTE+U0lORkVTVCBpcyBo b3N0ZWQgYnkgPGEgaHJlZj0iaHR0cDovL3d3dy5rZWVuc3BvdC5jb20iPktFRU5TUE9UPC9h Pi4NCjxhIGhyZWY9Imh0dHA6Ly93d3cua2VlbnNwb3QuY29tL3ByaXZhY3kuaHRtbCI+UHJp dmFjeQ0KUG9saWN5PC9hPjwvZm9udD48L2ZvbnQ+PC9jZW50ZXI+DQoNCjxicj48Y2VudGVy Pg0KPGEgdGFyZ2V0PSJfdG9wIiBocmVmPSJodHRwOi8veS5leHRyZW1lLWRtLmNvbS9zLz90 YWc9bXVzZXBpbXAiPg0KPGltZyBuYW1lPWltIHNyYz0iaHR0cDovL3kwLmV4dHJlbWUtZG0u Y29tL2kvIiBoZWlnaHQ9MzggYm9yZGVyPTANCndpZHRoPTQxIGFsdD0iIj48L2E+PHNjcmlw dCBsYW5ndWFnZT0iamF2YXNjcmlwdCI+PCEtLQ0KYW49bmF2aWdhdG9yLmFwcE5hbWU7ZD1k b2N1bWVudDtmdW5jdGlvbg0KcHIoKXtkLndyaXRlKCI8aW1nIHNyYz1cImh0dHA6Ly95MS5l eHRyZW1lLWRtLmNvbSIsDQoiL3ovP3RhZz1tdXNlcGltcCZqPXkmc3J3PSIrc3J3KyImc3Ji PSIrc3JiKyImIiwNCiJycz0iK3IrIiZsPSIrZXNjYXBlKGQucmVmZXJyZXIpKyJcIiBoZWln aHQ9MSAiLA0KIndpZHRoPTE+Iik7fXNyYj0ibmEiO3Nydz0ibmEiOy8vLS0+DQo8L3Njcmlw dD48c2NyaXB0IGxhbmd1YWdlPSJqYXZhc2NyaXB0MS4yIj48IS0tDQpzPXNjcmVlbjtzcnc9 cy53aWR0aDthbiE9Ik5ldHNjYXBlIj8NCnNyYj1zLmNvbG9yRGVwdGg6c3JiPXMucGl4ZWxE ZXB0aDsvLy0tPg0KPC9zY3JpcHQ+PHNjcmlwdCBsYW5ndWFnZT0iamF2YXNjcmlwdCI+PCEt LQ0Kcj00MTtkLmltYWdlcz9yPWQuaW0ud2lkdGg6ej0wO3ByKCk7Ly8tLT4NCjwvc2NyaXB0 Pjxub3NjcmlwdD48aW1nIGhlaWdodD0xIHdpZHRoPTEgYWx0PSIiIA0Kc3JjPSJodHRwOi8v eTEuZXh0cmVtZS1kbS5jb20vei8/dGFnPW11c2VwaW1wJmo9biI+PC9ub3NjcmlwdD4NCjwv Y2VudGVyPg0KDQo8L2JvZHk+DQo8L2h0bWw+DQ=9 --Bq50vA3GEMK-- From owner-linux-xfs@oss.sgi.com Thu Sep 5 11:52:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 11:52:54 -0700 (PDT) Received: from mailrtr1.mailzone.edeltacom.com (IDENT:mirapoint@mailrtr1.mailzone.edeltacom.com [216.248.176.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85IqntG029069 for ; Thu, 5 Sep 2002 11:52:50 -0700 Received: (from Administrator@localhost) by mailrtr1.mailzone.edeltacom.com (Mirapoint Messaging Server MOS 3.1.0.54-GA) id ACQ88044; Thu, 5 Sep 2002 14:56:56 -0400 (EDT) Date: Thu, 5 Sep 2002 14:56:56 -0400 (EDT) From: Message-Id: <200209051856.ACQ88044@mailrtr1.mailzone.edeltacom.com> To: linux-xfs@oss.sgi.com Subject: Virus Alert X-archive-position: 282 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Administrator@mailrtr1.mailzone.edeltacom.com Precedence: bulk X-list: linux-xfs The WORM_KLEZ.H virus was detected in email from nmcminn@charter.net (09/05/2002 14:56:56). The attachment (alt.pif) was deleted. From owner-linux-xfs@oss.sgi.com Thu Sep 5 12:49:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 12:49:51 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85JnntG031525 for ; Thu, 5 Sep 2002 12:49:49 -0700 Received: from dialup-63.214.86.178.dial1.boston1.level3.net ([63.214.86.178] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17n2hQ-0006gx-00 by VAauthid with fixed_plain for ; Thu, 05 Sep 2002 12:53:57 -0700 Message-ID: <3D77B641.1020407@osdn.com> Date: Thu, 05 Sep 2002 15:53:37 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] return() cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 284 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs Patch 4 for the latest 2.4 cvs http://www.axehind.com/xfs/xfs-cleanup-4-linux-2.4.patch changes return(i); - > return i; in fs/xfs/dmapi Brian From owner-linux-xfs@oss.sgi.com Thu Sep 5 15:38:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 15:38:20 -0700 (PDT) Received: from mail.vasoftware.com (mail@mail.vasoftware.com [198.186.202.175]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85McEtG002996 for ; Thu, 5 Sep 2002 15:38:15 -0700 Received: from dialup-63.214.75.234.dial1.boston1.level3.net ([63.214.75.234] helo=osdn.com) by mail.vasoftware.com with asmtp (Cipher TLSv1:RC4-MD5:128) (Exim 3.31-VA-mm2 #1 (Debian)) id 17n5KL-00079A-00 by VAauthid with fixed_plain for ; Thu, 05 Sep 2002 15:42:17 -0700 Message-ID: <3D77DD83.5050206@osdn.com> Date: Thu, 05 Sep 2002 18:41:07 -0400 From: Brian Pontz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [PATCH] last 2.4 return() cleanup Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 285 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: brian.pontz@osdn.com Precedence: bulk X-list: linux-xfs This is the last patch against the 2.4 cvs making return(i); - > return i; http://www.axehind.com/xfs/xfs-cleanup-5-linux-2.4.patch Since no one has told me I'm wasting my time yet, I'll start on 2.5 now. Brian From owner-linux-xfs@oss.sgi.com Thu Sep 5 15:55:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 15:56:02 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g85MtttG003889 for ; Thu, 5 Sep 2002 15:55:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA29927; Thu, 5 Sep 2002 17:59:58 -0500 (CDT) Received: from [192.168.1.101] (IDENT:qV/unN4YeuRVq9ubgy7fyJBM6WHhO4P6@cf-vpn-sw-corp-64-52.corp.sgi.com [134.15.64.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA63965; Thu, 5 Sep 2002 17:59:57 -0500 (CDT) Subject: Re: [PATCH] last 2.4 return() cleanup From: Stephen Lord To: Brian Pontz Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D77DD83.5050206@osdn.com> References: <3D77DD83.5050206@osdn.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 05 Sep 2002 18:01:39 -0500 Message-Id: <1031266902.1240.0.camel@snafu> Mime-Version: 1.0 X-archive-position: 286 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-05 at 17:41, Brian Pontz wrote: > This is the last patch against the 2.4 cvs > making return(i); - > return i; > > http://www.axehind.com/xfs/xfs-cleanup-5-linux-2.4.patch > > Since no one has told me I'm wasting my time yet, I'll start on 2.5 now. > > Brian There should be no need to do 2.5, we can merge the 2.4 changes into 2.5 when we integrate them. Thanks for the cleanup. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 5 20:13:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 20:13:41 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g863DZtG007880 for ; Thu, 5 Sep 2002 20:13:35 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA07995 for ; Thu, 5 Sep 2002 20:17:41 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA25509; Fri, 6 Sep 2002 13:16:13 +1000 (EST) Date: Fri, 6 Sep 2002 13:16:13 +1000 (EST) From: Nathan Scott Message-Id: <200209060316.NAA25509@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: agruen@suse.de Subject: TAKE - attr/acl X-archive-position: 287 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 5 20:15:41 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:126816a cmd/acl/doc/CHANGES - 1.42 cmd/attr/doc/CHANGES - 1.28 cmd/attr/libattr/syscalls.c - 1.15 cmd/acl/setfacl/setfacl.c - 1.4 cmd/acl/setfacl/do_set.c - 1.8 cmd/acl/po/de.po - 1.3 cmd/acl/po/acl.pot - 1.3 - updates from Andreas. From owner-linux-xfs@oss.sgi.com Thu Sep 5 23:27:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Sep 2002 23:27:56 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g866RntG014588 for ; Thu, 5 Sep 2002 23:27:49 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g866VvQ4064991; Fri, 6 Sep 2002 08:31:57 +0200 (CEST) Message-Id: <4.3.2.7.2.20020906083021.02ca1da8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Sep 2002 08:30:46 +0200 To: James Rich , XFS mailing list From: Seth Mos Subject: Re: update summary page In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 288 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:01 5-9-2002 -0600, James Rich wrote: >I've updated the CVS summary for August 27 - September 5. Quite a bit of >work has been done during that period. If people feel there are some >significant issues or important checkins that should be listed in the >"Significant issues" section please let me know. Great I'll add a link from the FAQ to it. Thanks! -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 6 02:11:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 02:11:08 -0700 (PDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g869B1tG021236 for ; Fri, 6 Sep 2002 02:11:01 -0700 Received: (qmail 546 invoked from network); 6 Sep 2002 09:15:09 -0000 Received: from unknown (HELO mountainviewdata.com) (210.72.245.13) by relay1.pair.com with SMTP; 6 Sep 2002 09:15:09 -0000 X-pair-Authenticated: 210.72.245.13 Message-ID: <3D7944C7.6020309@mountainviewdata.com> Date: Fri, 06 Sep 2002 17:13:59 -0700 From: tom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020626 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: a deadlock problem Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 289 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: twang@mountainviewdata.com Precedence: bulk X-list: linux-xfs Hi XFS developers, When studying xfs code(2.4.19), I found that the inode will be locked by XFS_ILOCK_SHARE flags before we get acl, which may cause deadlock. Because when getting acl, it will allocate memory in KM_SLEEP, If the memory is tight, the process will call xfs_strategy, and may lock(XFS_ILOCK_SHARE)the same inode again. If between these two locks, another process try to lock the inode by XFS_ILOCK_EXCL, these two processes will be deadlock. As follows, A process get ea B process want lock ipA 1) xfs_ilock(ipA, XFS_ILOCK_SHARE) ..................... | | | | get acl 2) xfs_ilock(ipA, XFS_ILOCK_EXCL) | | | | memory tight | | xfs_stragegy | | 3)xfs_ilock(ipA, XFS_ILOCK_SHARE) ............................ these two processes will be dead lock. So I believe that acl allocation GFP_MASKshould be changed to KM_NOFS. right? best regards wdd From owner-linux-xfs@oss.sgi.com Fri Sep 6 04:29:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 04:30:14 -0700 (PDT) Received: from mail.blazebox.homeip.net (postfix@pool-141-155-135-124.ny5030.east.verizon.net [141.155.135.124]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g86BTvtG025301 for ; Fri, 6 Sep 2002 04:29:58 -0700 Received: from blaze.homeip.net (blaze [192.168.0.43]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 2F9A99E2F for ; Fri, 6 Sep 2002 07:34:21 -0400 (EDT) Subject: XFS patch for kernel 2.4.20-pre5. From: Paul Blazejowski To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-a7YMRB0N+v4sk+C1dcX/" X-Mailer: Ximian Evolution 1.0.8 Date: 06 Sep 2002 07:34:21 -0400 Message-Id: <1031312061.3104.16.camel@blaze> Mime-Version: 1.0 X-archive-position: 290 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: paulb@blazebox.homeip.net Precedence: bulk X-list: linux-xfs --=-a7YMRB0N+v4sk+C1dcX/ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello folks, If i can recall someone on the list was asking for patches against latest -preXX of 2.4 kernel...i have created a cvs patch for my own use/testing/fun :D. The patch is from cvs tree as of 9-6-02 and should be applied to kernel 2.4.20-pre5 from kernel.org, it comes in bzip2 format. http://www.blazebox.homeip.net:81/~paul/linux=20 Regards, Paul B. --=-a7YMRB0N+v4sk+C1dcX/ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9eJK9IymMQsXoRDARAunLAKCQ/V9Oq5MzHEHDEsQp1d8agqNGUQCfZb2O /+2LLRk9/u4auPjtYsgBXFk= =h9pb -----END PGP SIGNATURE----- --=-a7YMRB0N+v4sk+C1dcX/-- From owner-linux-xfs@oss.sgi.com Fri Sep 6 10:26:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 10:26:33 -0700 (PDT) Received: from endeavour.uwyo.edu (endeavour.uwyo.edu [129.72.10.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g86HQUtG002181 for ; Fri, 6 Sep 2002 10:26:31 -0700 Received: from CONVERSION-DAEMON.endeavour.uwyo.edu by endeavour.uwyo.edu (PMDF V6.1-1 #40460) id <0H21006011Z652@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Fri, 06 Sep 2002 11:30:42 -0600 (MDT) Received: from asuwlink.uwyo.edu (asuwlink.uwyo.edu [129.72.60.2]) by endeavour.uwyo.edu (PMDF V6.1-1 #40460) with ESMTP id <0H21003DF1Z60L@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Fri, 06 Sep 2002 11:30:42 -0600 (MDT) Received: from localhost (fletcher@localhost) by asuwlink.uwyo.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA10193 for ; Fri, 06 Sep 2002 11:30:41 -0600 (MDT) Date: Fri, 06 Sep 2002 11:30:41 -0600 (MDT) From: Walter R Fletcher Subject: Re: XFS bad block recording? To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Authentication-warning: asuwlink.uwyo.edu: fletcher owned process doing -bs X-archive-position: 291 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fletcher@uwyo.edu Precedence: bulk X-list: linux-xfs People, I must have missed something. Disk drives have had for some years the logic to detect and remap detected bad sectors on the fly. Some drives did this silently while others have had additional functionality to report a developing problem. At any rate, the disks have already dealt with the problem (reported or not), so remapping a sector (that is already remapped) makes not one whit of sense. As has already been said, if the disk has run out of spare sectors, the disk is in serious trouble already and probably scraping itself out of existence. Given this, why insert code into a filesystem to deal with errors that are already remedied? Perhaps the device driver might stimulate an alarm or at least an entry in the syslog so the admin would be aware of a developing failure. That is not a filesystem's task. What should the filesystem do? Handle errors from a device that doesn't remap? How much responsibility does the filesystem have with regard to hardware reliability? -- Reid Walter Reid Fletcher, WB7CJO Department of Geology and Geophysics P. O. Box 3006 University of Wyoming 1-307-766-6227 Laramie, WY 82071 Internet: Fletcher @ UWyo.Edu Are we all roadkill on the information highway? - Jeff Greenfield From owner-linux-xfs@oss.sgi.com Fri Sep 6 14:44:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 14:44:54 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g86LiltG018973 for ; Fri, 6 Sep 2002 14:44:47 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id <3M5Q1PKT>; Fri, 6 Sep 2002 14:48:52 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F1F8@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-xfs@oss.sgi.com '" Subject: Oops in init on 9/5/02 XFS cvs code Date: Fri, 6 Sep 2002 14:48:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C255EF.30234E00" X-archive-position: 292 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dale.stephenson@quantum.com Precedence: bulk X-list: linux-xfs This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C255EF.30234E00 Content-Type: text/plain Here's the situation -- kdb build using XFS cvs tree from 9/5/02. 11 drive RAID5 with spare setup, created an lvm volume on the RAID. Failed a drive in the RAID5 during the sync, then created an xfs filesystem on the volume. When mounting the volume, the init processes oopses. In kdb I found the oops was inside kmem_cache_alloc(). Somehow, the slabs_free structure inside of names_cache's kmem_cache_t had become corrupted. The other list heads in the structure seemed fine. Any idea what could possibly cause this? Attached is the back trace of init, of the mount, of the raid5 recovery daemon, dissasembly of the relevant part of kmem_cache_alloc, and the kmem_cache_t structure. Dale Stephenson steph@snapserver.com ------_=_NextPart_000_01C255EF.30234E00 Content-Type: application/octet-stream; name="oops.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="oops.txt" oops into kdb, in process 1 (init). Failed raid5 during sync, then created an xfs filesystem on a logical volume on the raid5. Possibly relevant info: kdb> bt EBP EIP Function (args) 0xc1c17f58 0xc012acd3 kmem_cache_alloc+0x53 (0xc1c0fea0, 0x1f0, 0xc1c16000,= 0xc1c17fa0, 0xc1c17fa0) kernel .text 0xc0100000 0xc012ac80 0xc012ad44 0xc1c17f74 0xc013b3db getname+0x1b (0x804dcef, 0xc1c16000, 0xc1c17fa0, 0x80= 4dea7, 0x9) kernel .text 0xc0100000 0xc013b3c0 0xc013b464 0xc1c17f90 0xc013c464 __user_walk+0x14 (0xc1c16000, 0xbffffa70, 0xc0346000,= 0xc1c16000, 0xef164080) kernel .text 0xc0100000 0xc013c450 0xc013c4a8 0xc1c17fbc 0xc0139402 sys_stat64+0x1a (0x804dcef, 0xbffff6a0, 0x80500c8, 0x= bffffa70, 0x804dea7) kernel .text 0xc0100000 0xc01393e8 0xc013945c 0xc0108c6b system_call+0x33 kernel .text 0xc0100000 0xc0108c38 0xc0108c70 kdb> id kmem_cache_alloc+0x35 0xc012acb5 kmem_cache_alloc+0x35: pushf 0xc012acb6 kmem_cache_alloc+0x36: popl 0xfffffffc(%ebp) 0xc012acb9 kmem_cache_alloc+0x39: cli 0xc012acba kmem_cache_alloc+0x3a: lea 0x8(%esi),%ebx 0xc012acbd kmem_cache_alloc+0x3d: mov 0x8(%esi),%ecx 0xc012acc0 kmem_cache_alloc+0x40: cmp %ebx,%ecx 0xc012acc2 kmem_cache_alloc+0x42: jne 0xc012ace6 kmem_cache_alloc+0x66 0xc012acc4 kmem_cache_alloc+0x44: lea 0x10(%esi),%eax 0xc012acc7 kmem_cache_alloc+0x47: mov 0x10(%esi),%ecx 0xc012acca kmem_cache_alloc+0x4a: cmp %eax,%ecx 0xc012accc kmem_cache_alloc+0x4c: je 0xc012ad20 kmem_cache_alloc+0xa0 0xc012acce kmem_cache_alloc+0x4e: mov 0x4(%ecx),%eax 0xc012acd1 kmem_cache_alloc+0x51: mov (%ecx),%edx 0xc012acd3 kmem_cache_alloc+0x53: mov %eax,0x4(%edx) 0xc012acd6 kmem_cache_alloc+0x56: mov %edx,(%eax) 0xc012acd8 kmem_cache_alloc+0x58: mov 0x8(%esi),%eax kdb> rd eax =3D 0x00000000 ebx =3D 0xc1c0fea8 ecx =3D 0xcfa45500 edx =3D 0x00000400 esi =3D 0xc1c0fea0 edi =3D 0x000001f0 esp =3D 0xc1c17f48 eip =3D 0xc012acd3 ebp =3D 0xc1c17f58 xss =3D 0x00000018 xcs =3D 0x00000010 eflags =3D 0x00010= 006 xds =3D 0x00000018 xes =3D 0x00000018 origeax =3D 0xffffffff ®s =3D 0xc1= c17f14 kdb> md 0xc1c0fea0 0xc1c0fea0 efe0fee0 efe0f780 c1c0fea8 c1c0fea8 0xc1c0feb0 cfa45500 cfa45500 00001000 00012000 0xc1c0fec0 00000001 00000000 00000000 00000000 ................ 0xc1c0fed0 00000000 00000020 00000000 c1c0f0a0 .... .......=20 0xc1c0fee0 00000000 00000001 00000000 00000000 ................ 0xc1c0fef0 00000000 656d616e 61635f73 00656863 ....names_cache. 0xc1c0ff00 00000000 00000000 c1c0fe98 c1c0ff78 ..........@..@. 0xc1c0ff10 eddd4040 efded000 ee164000 ee164000 @@ kdb> md 0xcfa45500 0xcfa45500 00000400 00000000 00000000 00000000 ................ kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0xc1c16000 00000001 00000000 1 000 run 0xc1c16270*init 0xefe06000 00000009 00000001 1 000 run 0xefe06270 mdrecoveryd 0xeeb02000 00002900 00002868 1 000 stop 0xeeb02270 mount kdb> btp 2900 EBP EIP Function (args) 0xeeb03ae8 0xc0113ad3 schedule+0x363 (0xcfdfb300, 0xcfdfb300, 0xecfeec00, 0= xcfdfb360, 0xeeb03b04) kernel .text 0xc0100000 0xc0113770 0xc0113af8 0xeeb03b14 0xc0107a8d __down+0x61 (0xcfdfb358, 0x3, 0x0) kernel .text 0xc0100000 0xc0107a2c 0xc0107ad8 0xeeb03b28 0xc0107bfb __down_failed+0xb (0x1, 0xeeb03b4c, 0xc01d5ac4, 0xcfd= fb300, 0x20000) kernel .text 0xc0100000 0xc0107bf0 0xc0107c04 0xc01d85f7 .text.lock.page_buf+0x23 kernel .text 0xc0100000 0xc01d85d4 0xc01d8600 0xeeb03b34 0xc01d79f1 pagebuf_iowait+0x29 (0xcfdfb300, 0x20000, 0xcfdfb300,= 0xcfd143a0) kernel .text 0xc0100000 0xc01d79c8 0xc01d79fc 0xeeb03b4c 0xc01d5ac4 xfs_bwrite+0x6c (0xecfeec00, 0xcfdfb300, 0xcfdfb300, = 0xcfdfb300, 0x100) kernel .text 0xc0100000 0xc01d5a58 0xc01d5b3c 0xeeb03b78 0xc01c1bfc xlog_bwrite+0x60 (0xcfd143a0, 0x2, 0x100, 0xcfdfb300,= 0x200) kernel .text 0xc0100000 0xc01c1b9c 0xc01c1c28 0xeeb03bd0 0xc01c2cc3 xlog_write_log_records+0x163 (0xcfd143a0, 0x0, 0x2, 0= x200, 0x1) kernel .text 0xc0100000 0xc01c2b60 0xc01c2d00 0xeeb03c04 0xc01c2de1 xlog_clear_stale_blocks+0xe1 (0xcfd143a0, 0x0, 0x1, 0= xcfd143a0, 0xeeb03c74) kernel .text 0xc0100000 0xc01c2d00 0xc01c2df4 0xeeb03c50 0xc01c290f xlog_find_tail+0x357 (0xcfd143a0, 0xeeb03c74, 0xeeb03= c7c, 0x0, 0xcfd143a0) kernel .text 0xc0100000 0xc01c25b8 0xc01c2940 0xeeb03c84 0xc01c58e2 xlog_recover+0x1e (0xcfd143a0, 0x0, 0x3, 0x14) more> kernel .text 0xc0100000 0xc01c58c4 0xc01c5980 0xeeb03c9c 0xc01bef75 xfs_log_mount+0x71 (0xecfeec00, 0x3a00, 0xc800080, 0x= 0, 0x40000) kernel .text 0xc0100000 0xc01bef04 0xc01befa8 0xeeb03db0 0xc01c7166 xfs_mountfs+0xab2 (0xcfa453e0, 0xecfeec00, 0x3a00, 0x= 0, 0xcf13e800) kernel .text 0xc0100000 0xc01c66b4 0xc01c7670 0xeeb03dec 0xc01ce5e2 xfs_cmountfs+0x52e (0xcfa453e0, 0x3a00, 0x3a00, 0x0, = 0xcf13e800) kernel .text 0xc0100000 0xc01ce0b4 0xc01ce678 0xeeb03e1c 0xc01ce6bd xfs_mount+0x45 (0xcfa453e0, 0xcf13e800, 0x0, 0x3a00, = 0x200) kernel .text 0xc0100000 0xc01ce678 0xc01ce6c8 0xeeb03e98 0xc01e05cf linvfs_read_super+0xff (0xecfee800, 0xcf85d000, 0x0, = 0xfffffff4, 0xc1c1f3a0) kernel .text 0xc0100000 0xc01e04d0 0xc01e0740 0xeeb03ee4 0xc013785a get_sb_bdev+0x20e (0xc033836c, 0x0, 0xed2bf000, 0xcf8= 5d000, 0xedc53000) kernel .text 0xc0100000 0xc013764c 0xc01378b8 0xeeb03f08 0xc0137a12 do_kern_mount+0x56 (0xedc53000, 0x0, 0xed2bf000, 0xcf= 85d000, 0x0) kernel .text 0xc0100000 0xc01379bc 0xc0137abc 0xeeb03f3c 0xc0147e89 do_add_mount+0x6d (0xeeb03f70, 0xedc53000, 0x0, 0x0, = 0xed2bf000) kernel .text 0xc0100000 0xc0147e1c 0xc0147f6c 0xeeb03f8c 0xc014814c do_mount+0x138 (0xed2bf000, 0xefe00000, 0xedc53000, 0= xc0ed0000, 0xcf85d000) kernel .text 0xc0100000 0xc0148014 0xc0148168 0xeeb03fbc 0xc01484d0 sys_mount+0x7c (0x8059aa8, 0x8059ac0, 0x8059ad8, 0xc0= ed0000, 0x8059b48) kernel .text 0xc0100000 0xc0148454 0xc0148510 0xc0108c6b system_call+0x33 kernel .text 0xc0100000 0xc0108c38 0xc0108c70 more> kdb> btp 9 EBP EIP Function (args) 0xefe07e08 0xc0113ad3 schedule+0x363 (0xcfb03800, 0x161458, 0x5, 0x1, 0x1) kernel .text 0xc0100000 0xc0113770 0xc0113af8 0xefe07e58 0xc022bc45 get_active_stripe+0xa1 (0xcfb03800, 0x161458, 0x0, 0x= 0, 0x1) kernel .text 0xc0100000 0xc022bba4 0xc022c054 0xefe07ea4 0xc022df82 raid5_sync_request+0x42 (0xcfd142a0, 0x161458, 0xcfd1= 42a0, 0xecd19000, 0xefe07fa4) kernel .text 0xc0100000 0xc022df40 0xc022e000 0xefe07f7c 0xc0236636 md_do_sync+0x21a (0xcfd142a0, 0xecd19780, 0xefe06000,= 0xefe0d220, 0xefe06000) kernel .text 0xc0100000 0xc023641c 0xc0236900 0xefe07fa8 0xc02369f6 md_do_recovery+0xf6 (0x0, 0x100, 0xc1c17ecc, 0x0, 0xe= fe0d228) kernel .text 0xc0100000 0xc0236900 0xc0236b38 0xefe07fec 0xc0235932 md_thread+0xfe kernel .text 0xc0100000 0xc0235834 0xc0235980 0xc0107543 kernel_thread+0x23 kernel .text 0xc0100000 0xc0107520 0xc0107558 ------_=_NextPart_000_01C255EF.30234E00-- From owner-linux-xfs@oss.sgi.com Fri Sep 6 18:16:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 18:16:38 -0700 (PDT) Received: from nm.ru (node13ae8.a2000.nl [24.132.58.232]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g871FwtG024090 for ; Fri, 6 Sep 2002 18:16:05 -0700 Message-ID: <000e01c255fd$2756ec10$0100a8c0@slashx> From: "Julia" To: linux-xfs@oss.sgi.com Subject: Hi! Weisste noch wer ich bin ? Date: Sat, 7 Sep 2002 01:28:49 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 418 X-archive-position: 293 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andream@yajoo.de Precedence: bulk X-list: linux-xfs Hallo !=20 Ganz schon viel Zeit vergangen seitdem ich dich das letzte Mal gesehen habe= , aber wie du siehst , vergessen habe ich dich nicht ;). Bin jetzt aus dem Urlaub zur=FCck, braun gebrant und happy . Wie ich jetzt = aussehe kannste dir auf meiner neuen Homepage ansehen : http://www.julia.5x= x.net , hoffe dir f=E4llt auch dann ein wer ich bin ;). Naja, bis dann mal ! [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Sep 6 19:32:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 19:32:30 -0700 (PDT) Received: from mail.miratek.com ([216.97.55.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g872WNtG025098 for ; Fri, 6 Sep 2002 19:32:24 -0700 Received: from maherxp [24.145.147.99] by mail.miratek.com with ESMTP (SMTPD32-7.12) id A4D33D1024A; Fri, 06 Sep 2002 21:30:43 -0500 Reply-To: From: "Mike" To: Subject: mkfs.xfs tune performance options (sunit and swidth) Date: Fri, 6 Sep 2002 22:35:46 -0400 Message-ID: <000001c25617$45e86590$967ba8c0@maherxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <1031266902.1240.0.camel@snafu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 294 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: samba@miratek.com Precedence: bulk X-list: linux-xfs We are creating a single large filesystem 7x72GB using SCSI 10k disks. The system is 2x2.4 GHz and 4GB RAM. The application which will be accessing those drives creates large files and gets accessed sequentially (not database) with multi reads and writes. I configured the 7 disks using RAID0 (/etc/raidtab below) and created xfs filesystem: raiddev /dev/md7 raid-level 0 nr-raid-disks 7 chunk-size 256k persistent-superblock 1 nr-spare-disks 0 device /dev/sdd1 raid-disk 0 device /dev/sde1 raid-disk 1 device /dev/sdf1 raid-disk 2 device /dev/sdg1 raid-disk 3 device /dev/sdh1 raid-disk 4 device /dev/sdi1 raid-disk 5 device /dev/sdj1 raid-disk 6 #mkfs -t xfs -V -f -l internal,size=32768b -b size=4k /dev/md7 # xfs_info /data2 meta-data=/data2 isize=256 agcount=119, agsize=1048576 blks data = bsize=4096 blocks=124473216, imaxpct=25 = sunit=64 swidth=448 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768 realtime =none extsz=1835008 blocks=0, rtextents=0 My question is how can I tune this to perform better for large file reads and writes. The RAID Chunk size is 256K. Shall I make it larger? What should I use for sunit, swidth, su, or sw. sunit and swidth are confusiong, how those values relate to stride option on ext2/3? Any other considerations? Thanks, Mike From owner-linux-xfs@oss.sgi.com Fri Sep 6 19:35:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Sep 2002 19:35:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g872Z2tG025568 for ; Fri, 6 Sep 2002 19:35:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA39921 for ; Fri, 6 Sep 2002 21:39:10 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id VAA30739 for ; Fri, 6 Sep 2002 21:39:10 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g872ZhP25081; Fri, 6 Sep 2002 21:35:43 -0500 Message-Id: <200209070235.g872ZhP25081@stout.americas.sgi.com> Date: Fri, 6 Sep 2002 21:35:43 -0500 Subject: TAKE - Backport kmem_cache_size from 2.5 X-archive-position: 295 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs From Christoph: "Backport kmem_cache_size from 2.5 (already in 2.4.20-pre) and use it to implement kmem_zone_zalloc. Remove kmem_cache_zalloc." This will reduce our footprint in 2.4.20. Backport kmem_cache_size from 2.5 Date: Fri Sep 6 19:38:01 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126898a linux/mm/slab.c - 1.31 linux/kernel/ksyms.c - 1.135 linux/include/linux/slab.h - 1.22 linux/fs/xfs/support/kmem.c - 1.22 From owner-linux-xfs@oss.sgi.com Sat Sep 7 01:45:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 01:45:14 -0700 (PDT) Received: from relay.pair.com (relay1.pair.com [209.68.1.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g878j9tG029530 for ; Sat, 7 Sep 2002 01:45:09 -0700 Received: (qmail 41573 invoked from network); 7 Sep 2002 08:49:20 -0000 Received: from unknown (HELO mountainviewdata.com) (210.72.245.13) by relay1.pair.com with SMTP; 7 Sep 2002 08:49:20 -0000 X-pair-Authenticated: 210.72.245.13 Message-ID: <3D79BCE4.9050703@mountainviewdata.com> Date: Sat, 07 Sep 2002 16:46:28 +0800 From: Eric Mei User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: xfs-list Subject: hardlink overflow Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 296 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ericm@mountainviewdata.com Precedence: bulk X-list: linux-xfs Hi, recently I noticed XFS's strange behaviour on hardlink. i_nlink is defined as "unsigned short" in kernel, although xfs_dinode_core defined it as "unint32". it seems linux-XFS didn't check it's overflow. simply add 65536 hardlink to a file will make their nlink to 0. I'm using latest 2.4.19 CVS version. Best Wishs Eric From owner-linux-xfs@oss.sgi.com Sat Sep 7 03:09:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 03:09:57 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87A9ptG031577 for ; Sat, 7 Sep 2002 03:09:51 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id DAA05203 for ; Sat, 7 Sep 2002 03:14:03 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id UAA88744 for linux-xfs@oss.sgi.com; Sat, 7 Sep 2002 20:12:44 +1000 (EST) Date: Sat, 7 Sep 2002 20:12:44 +1000 (EST) From: Nathan Scott Message-Id: <200209071012.UAA88744@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - v2 log X-archive-position: 297 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Sat Sep 7 03:11:28 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:126903a linux/fs/xfs/xfs_log_recover.c - 1.242 - Fixed a typo bug (& != &&) in the v2 log recovery code - found by inspection, not sure it caused any problems in the wild. tidied some code around it to be max 80chars wide. From owner-linux-xfs@oss.sgi.com Sat Sep 7 06:25:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 06:25:29 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87DPLtG002841 for ; Sat, 7 Sep 2002 06:25:22 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id XAA07383; Sat, 7 Sep 2002 23:22:18 +0930 Message-ID: <3D7A020D.E3C1C512@rebel.net.au> Date: Sat, 07 Sep 2002 23:11:33 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Walter R Fletcher CC: linux-xfs@oss.sgi.com Subject: Re: XFS bad block recording? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 298 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Hmmm... > of a developing failure. That is not a filesystem's task. What should > the filesystem do? Be aware of possible errors reported by lower level handlers (in this case the device driver for the hard disk) and deal with them in a configurable, sensible and logical manner. > How much responsibility does the filesystem have with regard to hardware > reliability? None, but if it is possible it should use as much of the information available to it, eg errors logged by lower device handlers, in the decisions it makes. :-) DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 06:46:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 06:46:39 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87DkYtG003568 for ; Sat, 7 Sep 2002 06:46:34 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA43921; Sat, 7 Sep 2002 08:50:44 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id IAA14756; Sat, 7 Sep 2002 08:50:43 -0500 (CDT) Date: Sat, 7 Sep 2002 08:50:49 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Saji Kumar VR cc: Subject: Re: How can I become a part of XFS development team In-Reply-To: <00ac01c25346$cea919c0$670b720a@wipro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 299 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Saji - Sorry for the late reply. The main activity lately has been massaging XFS to get it ready for inclusion in the 2.5 kernel. Future plans include updated releases, and addition of some features like unwritten extents and realtime subvolume support, off the top of my head. Anyone is welcome to help with development, but it will have to be a mostly self-directed exercise. We're down to a handful of developers working on the project, with other internal projects, so unfortunately there's not a whole lot of time for tuturials, etc. If you're looking for a place to start, there are often bugs reported to the list; if you think you can tackle one, go for it! Other known bugs I can think of are occasional hangs on shutdown, and xfs_fsr is not properly zeroing the last bit of the last block of a file. -Eric On Tue, 3 Sep 2002, Saji Kumar VR wrote: > Hi, > > I would like to know about this project, like what are the future plans? Can I join the development team? > what are the current activities going on... > > Thanks & Rgds, > Saji > > > From owner-linux-xfs@oss.sgi.com Sat Sep 7 06:54:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 06:54:02 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87DrxtG005160 for ; Sat, 7 Sep 2002 06:54:00 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id XAA07989; Sat, 7 Sep 2002 23:50:37 +0930 Message-ID: <3D7A08AF.5A442BB8@rebel.net.au> Date: Sat, 07 Sep 2002 23:39:51 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Saji Kumar VR , linux-xfs@oss.sgi.com Subject: Re: How can I become a part of XFS development team References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 300 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Eric, > Anyone is welcome to help with development, but it will have to be > a mostly self-directed exercise. We're down to a handful of developers > working on the project, with other internal projects, so unfortunately > there's not a whole lot of time for tuturials, etc. I don't know whether I have the expertise, although I could attempt it I guess, but maybe becoming the "holder of tutorials for new developers" could be where I might fit in... Are there any starter documents that you have somewhere? DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:02:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:02:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87E29tG005763 for ; Sat, 7 Sep 2002 07:02:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA43375; Sat, 7 Sep 2002 09:06:18 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA82723; Sat, 7 Sep 2002 09:06:18 -0500 (CDT) Date: Sat, 7 Sep 2002 09:06:19 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: David Lloyd cc: Saji Kumar VR , Subject: Re: How can I become a part of XFS development team In-Reply-To: <3D7A08AF.5A442BB8@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 301 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi David - A good overview document of XFS features is chapter 9(?) of the "Advanced Filesystem Implementer's Guide" that Daniel Robbins did for IBM's DeveloperWorks web site. For lower-level technical info, there are XFS design papers on our website, but those are fairly dated, and have no Linux-specific info. Unfortunately, that's probably the best info in writing for now. I always thought that a document that showed basic filesystem layout, superblock structure, allocation group header info, etc and tied it to the structures in the code would be nice. Most of that information is in the design papers mentioned above, but it could be tied together, updated, and tidied up. Thanks, -Eric On Sat, 7 Sep 2002, David Lloyd wrote: > > Eric, > > I don't know whether I have the expertise, although I could attempt it I > guess, but maybe becoming the "holder of tutorials for new developers" > could be where I might fit in... > > Are there any starter documents that you have somewhere? From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:11:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:11:09 -0700 (PDT) Received: from rebel.net.au (IDENT:root@news.tellurian.com.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EB3tG006335 for ; Sat, 7 Sep 2002 07:11:04 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA08451; Sun, 8 Sep 2002 00:07:50 +0930 Message-ID: <3D7A0CB9.2B6870D6@rebel.net.au> Date: Sat, 07 Sep 2002 23:57:05 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Saji Kumar VR , linux-xfs@oss.sgi.com Subject: Re: How can I become a part of XFS development team References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 302 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Eric, > I always thought that a document that showed basic filesystem layout, > superblock structure, allocation group header info, etc and tied it > to the structures in the code would be nice. Most of that information > is in the design papers mentioned above, but it could be tied together, > updated, and tidied up. Would SGI have a problem if the document was auspiced under The Linux Documentation Project? This would have the effect of throwing it to a wider audience, a peer review system some of whom have no idea what I'm talking about (always a good thing -- this is a tutorial, so the only thing I'd assume is that the person knows a little about working with the Linux Kernel source code and file system concepts)... Would SGI mind if the document were under the GNU Document Licence? (I forget the correct acronym) DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:13:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:13:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EDDtG006818 for ; Sat, 7 Sep 2002 07:13:13 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA44355; Sat, 7 Sep 2002 09:17:24 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA68024; Sat, 7 Sep 2002 09:17:24 -0500 (CDT) Date: Sat, 7 Sep 2002 09:17:29 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Saji Kumar VR cc: Subject: Re: How can I become a part of XFS development team In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 303 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 7 Sep 2002, Eric Sandeen wrote: > Other known bugs I can think of are occasional hangs on shutdown, > and xfs_fsr is not properly zeroing the last bit of the last block of a > file. Oh, actually - the problem is not with xfs_fsr, but with truncate(). A patch was posted to fix up xfs_fsr (Subject: [PATCH] xfs_fsr causes mapcheck to trigger) but it's really truncate() that needs to be fixed. -Eric From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:18:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:18:11 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EI9tG007317 for ; Sat, 7 Sep 2002 07:18:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA44497; Sat, 7 Sep 2002 09:22:19 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA70509; Sat, 7 Sep 2002 09:22:19 -0500 (CDT) Date: Sat, 7 Sep 2002 09:22:24 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: David Lloyd cc: Saji Kumar VR , Subject: Re: How can I become a part of XFS development team In-Reply-To: <3D7A0CB9.2B6870D6@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 304 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I think that if you author a document from publicly available information, you can put it under any license you'd like. Although I'm not a lawyer... If you take the design documents (which are still incorrectly marked "confidential") and cut and paste from them, then that probably raises different issues. Although I am not a lawyer. :) -Eric On Sat, 7 Sep 2002, David Lloyd wrote: > > Eric, > > Would SGI have a problem if the document was auspiced under The Linux > Documentation Project? > > This would have the effect of throwing it to a wider audience, a peer > review system some of whom have no idea what I'm talking about (always a > good thing -- this is a tutorial, so the only thing I'd assume is that > the person knows a little about working with the Linux Kernel source > code and file system concepts)... > > Would SGI mind if the document were under the GNU Document Licence? (I > forget the correct acronym) > > DSL > -- > Con te partiro, su navi per mari > Che io lo so, no, no non esistono piu > Con te io li vivro. > (Sartori F, Quarantotto E) > From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:21:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:21:16 -0700 (PDT) Received: from rebel.net.au (IDENT:root@mail.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87ELDtG007805 for ; Sat, 7 Sep 2002 07:21:14 -0700 Received: from rebel.net.au (dialup-3.rebel.net.au [203.20.69.73]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA08725; Sun, 8 Sep 2002 00:18:01 +0930 Message-ID: <3D7A0F1B.34A826C8@rebel.net.au> Date: Sun, 08 Sep 2002 00:07:15 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Saji Kumar VR , linux-xfs@oss.sgi.com Subject: Re: How can I become a part of XFS development team References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 305 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Eric, > I think that if you author a document from publicly available information, > you can put it under any license you'd like. Although I'm not a lawyer... I know, but upsetting SGI unnecessarily would be a little pointless woudln't it? > If you take the design documents (which are still incorrectly marked > "confidential") and cut and paste from them, then that probably > raises different issues. Although I am not a lawyer. :) I'd need someone inside SGI or a contact to actually work out what the issues might be... DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Sat Sep 7 07:26:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 07:26:29 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87EQPtG008301 for ; Sat, 7 Sep 2002 07:26:27 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA42408; Sat, 7 Sep 2002 09:30:36 -0500 (CDT) Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA42603; Sat, 7 Sep 2002 09:30:35 -0500 (CDT) Date: Sat, 7 Sep 2002 09:30:41 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: David Lloyd cc: Saji Kumar VR , Subject: Re: How can I become a part of XFS development team In-Reply-To: <3D7A0F1B.34A826C8@rebel.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 306 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I don't think you have anything to worry about, but I can't speak for SGI on legal issues. I'll try to find someone who can and let you know. -Eric On Sun, 8 Sep 2002, David Lloyd wrote: > I'd need someone inside SGI or a contact to actually work out what the > issues might be... > From owner-linux-xfs@oss.sgi.com Sat Sep 7 13:46:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 13:46:40 -0700 (PDT) Received: from bonzo.nirvana (pD9E7D8BE.dip.t-dialin.net [217.231.216.190]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87KkUtG012122 for ; Sat, 7 Sep 2002 13:46:31 -0700 Date: Sat, 7 Sep 2002 22:50:41 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com Cc: linux-bugs@nvidia.com, =?iso-8859-1?Q?J=F6rg_Prante?= Subject: XFS & NVIDIA Bug? Message-ID: <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 307 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by bonzo.nirvana id g87Kofj25934 I am using J=F6rg Prante's kernel patch set 2.4.19-jp14 from http://infolinux.de/jp/, which includes among others o XFS for 2.4.19 o rmap-13b o O1-Scheduler o low-latency patches o preempt-kernel If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get= a kernel BUG at filemap.c:236 in Trace; c012cc26 Trace; c012ccee Trace; c01b2de3 Trace; c01c95e6 Trace; c01d6399 Trace; c0155efd Trace; c013bb09 Trace; c013bddc Trace; c014e76f Trace; c0108a3b (the whole Oops is attached.) This happens reproducably with VMware, but also with Samba (nmbd), which is pure userland. It causes severe filesystem corruption. Using the XFree86 nv driver keeps the system stable (and the NVIDIA card useless). Using 2.4.18-4SGI_XFS_1.1 (with the root access fix applied) and = the NVIDIA module also works. The XFS FAQ mentions that any NVIDIA driver later than 1.0-1251 would fit. = Do maybe the newest NVIDIA modules break XFS again? --=20 Axel.Thimm@physik.fu-berlin.de --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=us-ascii Content-Description: Oops.txt Content-Disposition: attachment; filename="delme.log" ksymoops 2.4.4 on i686 2.4.18-4SGI_XFS_1.1-puariko. Options used -v /usr/src/linux-2.4.19-jp14-puariko/vmlinux (specified) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.19-jp14-puariko (specified) -S Reading Oops report from the terminal Sep 5 19:33:29 puariko kernel: kernel BUG at filemap.c:236! Sep 5 19:33:29 puariko kernel: invalid operand: 0000 Sep 5 19:33:29 puariko kernel: CPU: 0 Sep 5 19:33:29 puariko kernel: EIP: 0010:[] Tainted: PF Using defaults from ksymoops -t elf32-i386 -a i386 Sep 5 19:33:29 puariko kernel: EFLAGS: 00213286 Sep 5 19:33:29 puariko kernel: eax: da7ebd88 ebx: c148f490 ecx: da7ea000 edx: d9fb4ad8 Sep 5 19:33:29 puariko kernel: esi: 00000000 edi: c148f490 ebp: 00000006 esp: da7ebd28 Sep 5 19:33:29 puariko kernel: ds: 0018 es: 0018 ss: 0018 Sep 5 19:33:29 puariko kernel: Process vmware (pid: 7115, stackpage=da7eb000) Sep 5 19:33:29 puariko kernel: Stack: c148f490 c012cc26 c148f490 dc0536e0 00000000 00000001 00000000 00000000 Sep 5 19:33:29 puariko kernel: 000186fe 00000003 00000000 00000000 c18b1000 da7ea000 00000000 da7ebd88 Sep 5 19:33:29 puariko kernel: dbb68110 00000000 c012ccee dbb68110 dbb68120 00000000 da7ebd88 da7ebd88 Sep 5 19:33:29 puariko kernel: Call Trace: [] [] [] [] [] Sep 5 19:33:29 puariko kernel: [] [] [] [] [] Sep 5 19:33:29 puariko kernel: Code: 0f 0b ec 00 5d fc 2a c0 8b 43 28 85 c0 74 0e 6a 00 53 e8 ad >>EIP; c012ca7c <===== Trace; c012cc26 Trace; c012ccee Trace; c01b2de3 Trace; c01c95e6 Trace; c01d6399 Trace; c0155efd Trace; c013bb09 Trace; c013bddc Trace; c014e76f Trace; c0108a3b Code; c012ca7c 00000000 <_EIP>: Code; c012ca7c 0: 0f 0b ud2a <===== Code; c012ca7e 2: ec in (%dx),%al Code; c012ca7f 3: 00 5d fc add %bl,0xfffffffc(%ebp) Code; c012ca82 6: 2a c0 sub %al,%al Code; c012ca84 8: 8b 43 28 mov 0x28(%ebx),%eax Code; c012ca87 b: 85 c0 test %eax,%eax Code; c012ca89 d: 74 0e je 1d <_EIP+0x1d> c012ca99 Code; c012ca8b f: 6a 00 push $0x0 Code; c012ca8d 11: 53 push %ebx Code; c012ca8e 12: e8 ad 00 00 00 call c4 <_EIP+0xc4> c012cb40 --Kj7319i9nmIyA2yE Content-Type: application/x-bzip2 Content-Description: Kernel_config.bz2 Content-Disposition: attachment; filename=".config.bz2" Content-Transfer-Encoding: base64 QlpoOTFBWSZTWdpvDbwAB+HfgEAQWOf/8j////C////gYB/8AAHMHSi91HA5 UFAb46U+xaACN61LWUpTXSgOi29e9jVHvWFA6A9B3e3RF73atgG3W89utWvX ElVSffPnc3dy32++3w1MQBMRkJiNIE1NNTMoYmTMo8kANBpoIAgTQFJmmqGQ AAA0AAAxAkNTSaeoyDVH6p6QD1PU08UekwNTQ9Q9QBJpJIaRqYJimmp6TQ0G 0EGJkYmgHqGgkoRpqaT09TIanpT9R5Rkj1GTyZGiA00aNpAEiIEAICImSNDU AAAAAAft/D8fcsq1bI0pRrJWKttBiFKWoCom0mJ1e4HSX3YZheFwykFNggFp 9z/RM5IcOr/Nz/beJeK7U/BzZn4pj3ELAefRyiRawrUxKyW1SoCyFctihiYw aWChiLFrJWI5SyVhWVKkWGCEKwCpUByyityiwUgVXFMMyONrZlkMGKYmJJ3J pJjK6ZUK1hjDEMcRSTGYMgYwgYzBC2lYpJUUMZWYmOMLlrjWCixYEFwSLAWu DMaitwIBVuWqxRssaI2mDKz4GmhtaavrvvuC6axsqiloYeyzXsu3EqTSExg5 kVbnws4JtJotNmmMkKxSIYhV43MLcumGFujJhcjBW0wtcsDC2Kc2QNMk1Lpu DmZZiXMuJV5uGF0ZkWEEcK23MsxRlSmTMUoOJaiYkU0hphmu9HQcuuXwvxfv vn19+Q4Ld5hgO1fPEuCSQQN6zWS1+bDsnlVQPNZoGgjwxYbUIUIDTHWnyU9D GySHYmQNkRVWc5UYnZgNA0gBIlKpr8LP/PocZn+n5RWTx+pgssbw6ZCHvX1q uGrExgzT79Ofy+O3Xb7MdPx/p6SwZ2g/6TjsSy+Ua+Hya2Mij1ZPzu0Ln9k2 JCI/m59C0+eeWGDW2N+jPg9v2tGkp2+NJLojFrBNyt8+hk0PL5nh8eMW40pZ hjSNcXjszDjHmLHNLQnat1+7CDr4yltES0v9G0ZpHBIurOkITyhq2la87s2c bkTu9p8HSmI74mWLWvO2j0bHZFxMMQrXiekfKmniNuVxjPi787uPppmobu3E CvpClz1xazHl8JlXprBkAQBOFMw7YdFo7F+O8bQg92syl9EgkM15QyP6HpAr YLcyi7GzxfA6VVmxhVha1a/XrOYjYWrq1XMHsfMZtiY30Par8k78bdvSnXGn Dsw0q7jqWjcq6kb+bX0XoSGvfu8NEmW4nKFq9ntxa0ZTbAWm4s7p5dmX2pnw beeStxHWGuuXGlYjH3bb0ppCkt+MGZoi2+xvC4gZ/OHWnpR78SB6EnTu5+Tw 55X0oauysDNXlhfh6Z8687Hbrthjp2veLmSnW0bPTl7rWVdEHRjMP9zerkOr frEkhBv2dnR+czZNtGEwiSQgI5v5i/uwHZHyo46bM88aU08cfqUX6x+48QAQ CD6vaCn+r10U25a3zSW1ds7Z6m9ZMN4R/1++U58MdGPB406OwztW20br8Kft 2tSTWezJlYMFLc69iEVL+DFg6fCHCFVUQWNdzwngY1BSLn7NQebdrM+QzUYt vztesC7xhKkQlJ8af0d3eO7Nnxx8hhQWmnluG3hEen2Z9eOnVdDq1/JTbJxT LY/w/yOf0RA+MMBj6sCmindHF0+wmmrujYjx8+Pli7Ah6FHLx1bXoN9/OOPb R0Z4doJKvivz6YshacMmY+/fux3gq+sSzkHTQmxvXszVkU4+MhstqK3oepIo sViOJ0mcLAiUQAV1y7oAIQpmQPvzU12jerctpeULRFNs8DD6WPHbHa0WBsqb rfcdN+r01KsnAhEwq2nRK8sKQQlAuvcwMttriWVh4pdNM84xDmrrvQkwk+eN pjC8pvgV+IDFQ1qBbaETNT1W+mudl8SK7zrI9xuSSFygiuqies0ZGBARsw+/ FqxL5AuhE+d6iBcDZR6vGfYXpRjE694pIE+oPIzfswJZmLtINF+1cMaKbwRk KEAFcSeXORiUu0q5rYbJvftSLF1FHcXn1ym3YUIU1KvrGTEARSnbRhn5N1V+ ehJ3wNXkVwZAKjalmgB/dFgwAqTHNsX8B4AKbhbCHZO3p055GauFfFYYIhj5 PlmGXrga7uIaSDAQYDEHHO3ivnoN8cMCioUXMBSb9vhPrW5UNCWYIufk/zi2 6t/kXsaXn1wj19jSrH02wRrW25xYxm+B+1t2L8FuZJGZ6wEmMthFz38WHpLr iRyy2f2ModdfAzm2BHDd1GKc8hyacRT3j6JNStA4NJtEd1LiXd2z60417eJv f3jxj9eq82m4c8ewdTqaJyvmzc/RxNQ2tcGIjmm9N/r68al0PxTLzrhLHJbX uhZ5Oqwr3bFvkeuDiIXwHgvSfG7YQcguj/CSeQj5VjsbMOzK+HCJr1g1bLXG hu8KnvS/eGUr1zu+TSItIsguuRveWbdGuFobTZeHn234kjzLN19DWvHyyryY 401Gu8l1LArQNZPc6MOZOguCB25xyLuh5PesGe+rZbG5zkw11zLci5ktYe3s cJROpkUic9ZdZvY8Pw2jxJ73pwEJaiID2FVgHpNaSmEESf27kNGAVtTJsmOx LDSRPihJobl1oEDjmxqN627aN4LEgzgRdmFv1WlvY/OMMSJAgqkoEcyermnr 9fmkm94i22iDFD4vTGURjIBQ0EBOppCOVeiclJ97NcOZ41priD3l0ucwOcr8 WLdeLWwuOGBsQKF5MBg/ciQqRggDkETPL7TwN78kU74rVb6kXEcPSI1DMoJO 0IXi3U+MLFtS0b58ZR5OaPmkNEmVtw0QsjfZm1is5ELXeTcmwwlcUUJdsP6n UAoQ9ptvpnR3KdDBR2C8IMoB47rXJ8Q4HS+M42pE+uFKXz58fbFLGg6GXadG vlt7XRCBBbR56zxWGRefm2Vj4ZLS5SQ9ZI1erFrRjSYzEPHLDGVjksoirJIp BYIo+KTiDS3Osqd6LO1Tjfw/2jY4qwFKUDJ7CLqs7iwsImUxZdJlpnShqLdM 1cyggZfcVuIj2E5CUasGHTol3TSeiG9GDkPy4XIvJzolQLT1d+hYAjWnkPSa kl22gkYirNzkHawUnYOuM1hFm+LuG2wacPfO4ipZEIoyxvTKhhiRfe1/Dbfe z0bHcB9TEiiyMiICqxIKjGMVQigisiqIqKgwRBQEiLEQFkUiikRUkYKDCKLB iLBYsBggiQRIqxSCSLBSDEVjFRjIsiIxCJBQEYQEUYoowRRijEgqMVgrIgjF YAxSCjGKKiERikIIiiIwQRIiqAikWDJBRYqxZIRAUgsRgMVYgqIgsgqwVBBQ GIxWQWKsWIwhEYsUVGRBgpGAoNNJsGmUS9fZKPqbbT+fPHQFirAKHiRUmKRI RNC54lbsKJADirF6c+Kv1S9Yx3+FTDLV0vk7ryyE2IyagasOWqjorzJNdpRO 0NDuwCgkoAVVWWaq1ZKBympQffM/V+uXWd9tcGlPYbLeQw9C0dxgLvZjAwSq YmSlJrvqw95B9aNbhaYxAdmPT9T+RuRbQrSyssO6oQFjaVdO0Ced4dgFI0kc o1YBLby3kEShqwxBYSJgrPZhBjSMfN7e3GHQdSgREUFAlsgixAwJZ9g9DTa+ UjpKs0l7M8XKazI0Ds76OHYId4i0MG0PJ/B0b77BXIui91RSnvvH0aCnMKNf AKJ99hhoVRsgWQuqptlQOxqdu6gF6tEoRjlWIPo8VBeAs3W+22jgZS6JjAo0 MrtSrE8V9GQhJWK1Ix7PXDH7qyyZn4PTR9i+8KdSHEk6RBdxVmFBirtLTv5W eeokffL5NrutFgpPfeZrsfq3IJ0zSSs0BL2VR0NNKrO1QRSzJ38/Qla4MCx9 Sb8ONngIMEScCyzwHqQ+/T04FaJBRbVh7rrMKBAUKM0siiyrrcANzQyMzeha qgQaVhAsUyzqa3tSE7x7z6Oe29irX4Msz32t2DpggwpIeeMS/rOYoQIJOKwb FWqZyHjpS+6dg468bF3GjDmJhZqT8Lz26xxAGtI1rDzg500J4zgEaBnCIGCi FCoVyENoBEtnUE/oYr8MReMGecAjUypI2cKSLnRguQXhpsKrWXQ1cCU7WY/E c/Ve0xM9dDz57dz7Pu/osggDdgjw/uzPOI+5P3l3qeRIQAbfWemP6x7fBeCH v+dFwPcqJj9NIOWUY4qLMBQguaKaqTJ15u03x4f1dMJDim8pTpOnZtTdQirL 2OdaFZ7NGbQUeZ7sjRy0kd3DQfufY+7FOAaXna9bmZljPS1mrulmOdfl6ey9 7e05nJWlJOcQa0Pt4hWxXHhBhAqtEW3tZEVaH954sWcpmjhwWAvrS0QkIyzg KN4SSEHLkkgoBBYAQ4oEqSAoAAsIm0lLQkI7H24bSb0Daci8xMG82eWb5m4n EKqN3FG23jxKhrFuCyo/wxI9ApYMVEShUgIRXaIGCN1cu2d+ivXiNrxP3Iw8 OjLlFZ+AoRXPZAm0tWLkrZt4xJDDy48yjdCBhjaIOsFoLfhjsaQjLbGUmcZc FdAkeZRrV+mOO+sdGDSD/iECk2EEI4YpLaE+TUyn7X/Hru/vUsaaeX1IXjct 5wJCAD3Lx9vC6tN9JFld02BRb1FZq+0RwB8jtTFPFAxmh8Pci54zIlNxmrk1 aAN2fPJAqFZjEuOsqhZtVKNNgNsJ2KFklnRm56z7O+ZX3KO7KKkCHjEoEs2/ EDfiQ+eSiehyVaPwqirMnKqhQhfoLxOg2y+54u2x68IEPm7B6Mrcr5E0qGmJ cwHMumSKvqSdq4pVItSXrbMC0FOauM34WbDbRLo7UhNjZE+A9W2PLR6apU1L 5fsJxQaj7tj8CsuRIU4zKrpUQ++wFB2gEEOAxIaYvWSqwz5vWY7bUwaMEBkj Te0o42mq8PziDvSsrIxjU6ZmvQPcXJhgJKcissHNTIuvYxbPhV7yo0VeHax3 XoyX1FTOizAvfkuKYAHxF4MqwfRY8ZvSK3VtNRICfiazA4RAyNIO5aEUyzla egg7mUQ30eNaanZ+mAoYk2xPTZnQogRo+Dgy9Rp1NM1kfXWEI7tLDRcMammt ifXxBgzhuCpFMrvV5ZQEzymUvRU0UhXGgEgT29BSVYhrfCcQLzY6tsMNvLTO TusvUlftCS5YFRFA5elNn2GmUNADUatCCjgVDuixDaxqRqgzEqLgh+Ji6X6L NEQaQZMM36Yc9UxtXR/qzJ45qjPELl+BsbYO6K1od3l80r77W8/GuudToaqP 7v8tSD2iAgRy178uHglldYalkD3exXr9LSqr5rh2dGNk8FFUypZtcyWbO+Hf rt29G7AeQ92pMmahKmGgSM3gOMU5ChGFEkgJ7DmZrrk35HDXbflxTnrnJFAD ReNJCABYZJIMKml1c1gylw7T3t66i4wawyGXSEXT5rPuiu93qPyFskgMx0RO 1hCIRCSTM7SxsZFkFiTq1Kw2or2+5WrGmw8OGDzzgRmeUp/ToXf4d48vN2ZD XzfehFPKEybQYHcp4n2QZ0WYxk9KXgJPPxeHRqSD1O91MHpz8S7K+XWKKltF dPZiTbN5SNFPyjT8rcTEJv1rM5MXRUcM0YHXWUnJ9rsYkIAM+xvqqdsQiGdw rFBg2Mz4MeR721k2L7JDXB3xQtxpfV7S4sxHYO0chwdaz9SmSSW4Ha8IWobb 6FH9adq0ZZZ9s+8fB58KcFSEjHAIssndgu/1f1boCzOPfcfcHRyV+N7n0zIr C4+aGLQVZF5hyOGQ2S4bQ6omNLkhVsj4hqW0zQaGbeIzcJPdApEa4YTKKxoD R5CRIjJykHtoM3QggMeIpEReDE7SX11lK7QN+MELDDJo20DbSkQT1+kZemvZ pZ+84TD4zrGsy3xCOLIZuQYHYAZN6ObdGcksuQBDZVrYvmnEsFaA7WgrcmUH UyKypekIxEJEcWphImpBHAO81y4XfBzrn3SAgyq9HqPwd5o+mb47XL4LMQKS H9PQr4/Pz+Hk9MxfrToLNJv2yrKEa1D2cQQ+ojZ0mB+cp+kZAYXIluVJh6Nq UlJUtal0cKOpqURH6UQD2tGVhM+I8UgswGsG7g9bc7FA0jEBdzaKTtzrSgUg nvsSiXSmcY1mB4jNMQ7kQJBdkbamo6FR2hRXO/nO/bL5doygMCEXX6dcYd8m TIEKRgkWoat2aOWKT+GHefqBDOTnq+N8Y9NBFd/no5Yk352V6FJjPqNjQiQA bCrJlkFoSy6SFE6csJwyW65XsnPM0trl9U9vmc0/MRlcVpa7LSNTOasWT0TO W0jjoCaH4YIVtExIQgRqXI2K8Mri2ueKLh822MLsHed6oAKrMzOWRZB9GqHS zWb5tpdeHheZyAeL5iOQizo0QBHXeenakAsMfrL5gKS0CWnaMXvMmSkoacvg w7Ep5aFRkFRIjCGTDp6znkkjNUkBOnGmHJ0wrrrnehWeOocTwQoGgJNb41BZ KGv1fFniw0G9O8HjCaSnbDypMSklIIngg8CMRdldYyzvJzeplozFYyL8YuRc 1KrPTGVIyvIiiZER2fzEJFHjMiI8yFqwaNHba6OPPgSKUlEjIGkumNrZyMpB zOBMRkqzra8KawYM45VypbHh3+Uj3bLwzL0GbX2kVJ1VpCau0qFQeWnTigcT JRq0cati5Nrw8n1UeirPrSl0RhFWuBGRlgGFjATQMkVYQex8YHOo8sy9Sdqh WiCDmCZIcxaRBCUdhNpxoTdQFGtm+eJCuZ3cwKcHDBb7sRZlDAR2niqVix66 l68xj6TlaxpBxFdDnKj3jRqDxgRhgkgugTQThxIRqsYs03HxxkEoc1+9Ypw/ FlQA2AvoKXBrxFnxsV2g0BhYDCEpLWu5isfqa+R2Q7uzwxS83Lqd4uXqXIes crVBT2yJdZgbJM1IWpiVQlPeJUxDKu94e1VaSPNy0wqSQMAcqKwpmG8Rgant 9A5quA5/M22tU2NLRHeR0PokQ0DahdU2vr62vRUQQT21mLH5zXWyneGkFCGS EKUOmhPuiqWOODDqyoHQERCa5YAjIE0ciqjxekeLCuMFTslfFUAazBqrJXmt Fqw6y6REzpklla01iLJl2Iu5GINsQvVjPFE7F7OilwIIYCXBwfI6rmuhLGZ+ yV4XQp1nwVZERQNyvG6wmFbxmeIHJ1FO8kX3XHmVtSHum8rIv22PYnu+tPtJ Q9R4XXAg+AkxQCkBZepzfTq46LTzZewtmoYjTr6b0ruPw5fWe1ibWBjj9UQh CckCGNyMIZePJNOc33Wu2RjpDquHKrkDNrYS+JQahAQJu8470nqLoB9JtPJG L+4G7rfRvqe3VXSqFLW4bj2yT6JIM5hgGa0o6Ne7AEMhMAXuNuFQgRZzsQYa kZqttB4iVklmte62VAMMPsUglXhcLNs8a+Kmtsq0NWEfnAkBa0G8fUz7VYfK nPGbDM4bE/mZb56momBxFqas4QSA+k0WoDMBlcVtiFKDYaK0vo9L4rxTQTnq wwKxol5ZLtnzyz82o+ySuobl/BTaq6vpVKlJZmLdY136MkHqyBWkkasTYNig tplptv1cztHGMWvE/tWQX28VoiBRcGRkUFqyZGeT4pXWfyqJAw7TDgsqUvta JWSE4fmSTx3mvFTnyVPnxWcX++4fi0Ue22co26hTSw9c26M79DyBUJQy1rBN yqQGrs2hJiB7rapFdeFwEkNhT0Rzy1AWGtXtaHW84xCBQxR51iV2cdzN5FFi sUY9lKonneZvv1GjfOmjlsIDV4fuvzzzfnrFe2ezB51Qd2AlWszGY7Ts3Pmw CLAXzAcATXQbh0e6IKNQLm3MCxHFT1pEVQUWdZMLF9ljGs3hlCYIzkVae15w GQJGbmu/qE0Njc5NSg0L1x1eUKBAgKARvM1cZgd6+YdM9+4PBzBk6GlY08bd 7ojxiYR3hB2qoN+YBI7+/vWiOXwkgmZu0kNiTdHbhxzbximzXqM7zxzf3tis 71aHtXmYfso4KBOl+niq95vvasu8gG0gOGgeLs0gzBD9tUZLccOONMsjqvcY vYdYqDEljztp+PMFIsgh5O562NL8TamklaezKAkGZd/UmPMU8NWkIif3ynVj nwSQG813q6HM+4wL9zMSHhvARkppfyZ9WO9z8O19u3Pq61lIuTdoQs2T7t7x cskkeiqCUJREJIKEoobmkWM72pBcV23rLNoIe8UYcuMoOzQiD4jLEMjcrqg4 5znvlZi1yiM9dELiGUHYfBeUAYaxnvxmJDovFqVwe+2zXNVuw4zL8eeuLGiP yLtW8axr6mBoC8LocEDI8gC7UBABG+9LFddOw44Me+1VljRv3lxnzoWV2IH8 RExdpvvSFoM2evbd+u35R8X/XMcPnv56ohNgvU+vVEYte5GYXwO30Ptu69dg 7++czMEnzZ5MnljOjyKYKbEoV6LvB8Lwy1PmEL7qiucfxGnL6/XEGUR5BEMi ejVupxMiCzx8RqRYKPSFNjYC6BFhJ9zc0AjTBdPxQrP/uX9Hb+pOSXt7ppg0 EhgjcI1dNjfHD6vhhs6QutOL7lhBmQvLqQp66zrcUE6QMhZYMW+FA5ZBREK/ cZ5EFdCECVJ33EkhBROn4+ZhEVofyciTHmezq+ax3rLYWytX4vufK175RsH3 +yqSRg0yDYkdTuWsQNNPSZVsGSKTTzu09OeSmiKmOViV+fVFkBJIQVEPQZ/D BmGMELuNXjsDpPv2YwgvQAnDr+738+EccEa+JE7wrgsFEvwB8czlcCr38gTS BJIPfhb8LutVxMYQg0l06ZGIR3ZQtJ2spAr9f0ZNiSQg0sjIi8tjk5grOPxu xVGrH7+SEuyeHtl10FTDBK2/iY0GrNDigjTqyYp9qIO5khVbogAkFlVhlx6P oXO8y9MmbZiSRWxjDmwgW1bEBgje+MrMeIgxBH446pHx+78dVzLLLMjDRJQ+ Q8EDYiD9HRxOBCBX4okFrsvmD86PYFo/dlVYzL5GNKdHGZ7O1e4kkIGJ1X0A AkHt1qsXeMPf4RGEkeXCSRokGUIBICErMWd/+fmWAiIgQAuZgrQd85F0+j3p A2FJ1u37RVkQYqaCZQAZJEDYnI1glD73iQ5kyX7XMv21/irb100++ofsbaTY jbcpZ2PjzH6/XjIaCHAgpxhHv6U+/gcME3DcgGsBIRTRdda92vI42SHGWUn/ F3JFOFCQ2m8NvA== --Kj7319i9nmIyA2yE-- From owner-linux-xfs@oss.sgi.com Sat Sep 7 14:59:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 14:59:41 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87LxZtG013291 for ; Sat, 7 Sep 2002 14:59:35 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 5EF8DED2BE; Sat, 7 Sep 2002 15:03:52 -0700 (PDT) Date: Sat, 7 Sep 2002 15:03:52 -0700 From: Chris Wedgwood To: Axel Thimm Cc: linux-xfs@oss.sgi.com, linux-bugs@nvidia.com, =?iso-8859-1?Q?J=F6rg?= Prante Subject: Re: XFS & NVIDIA Bug? Message-ID: <20020907220352.GA2594@tapu.f00f.org> References: <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020907225041.A10340@bonzo.nirvana> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 308 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 10:50:41PM +0200, Axel Thimm wrote: o XFS for 2.4.19 o rmap-13b o O1-Scheduler o low-latency patches o preempt-kernel You have *many* variables here. Perhaps you should try with plan 2.4.19-xfs and the NV module and see if that is any better. FWIW, I use 2.4.19-cvs+rmap14a with the NV driver and don't see any crashes, but it may be I just have luck on my side. --cw From owner-linux-xfs@oss.sgi.com Sat Sep 7 15:21:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 15:21:56 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g87MLrtG013970 for ; Sat, 7 Sep 2002 15:21:54 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1DEA61D9A03; Sat, 7 Sep 2002 15:26:11 -0700 (PDT) Date: Sat, 7 Sep 2002 15:26:11 -0700 From: Chris Wedgwood To: Eric Mei Cc: xfs-list Subject: Re: hardlink overflow Message-ID: <20020907222611.GA2652@tapu.f00f.org> References: <3D79BCE4.9050703@mountainviewdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D79BCE4.9050703@mountainviewdata.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 309 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 04:46:28PM +0800, Eric Mei wrote: > it seems linux-XFS didn't check it's overflow. simply add 65536 > hardlink to a file will make their nlink to 0. Yes, I can confirm I've seen this too. It's not hard to patch this in XFS, but in general I wonder if this fix doesn't really belong in the VFS layer and there *are* system calls that can return larger than the 16-bit value. --cw From owner-linux-xfs@oss.sgi.com Sat Sep 7 18:44:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 18:44:22 -0700 (PDT) Received: from dns1.nvidia.com ([209.249.170.16]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g881iItG016258 for ; Sat, 7 Sep 2002 18:44:18 -0700 Received: from NVVwall.nvidia.com (z06.nvidia.com [209.213.198.25]) by dns1.nvidia.com (8.12.4/8.12.4) with SMTP id g881mMrE009938; Sat, 7 Sep 2002 18:48:22 -0700 (PDT) Received: from 172.16.217.105 by NVVwall.nvidia.com (InterScan E-Mail VirusWall NT); Sat, 07 Sep 2002 18:48:17 -0700 Received: by mail-sc-0.nvidia.com with Internet Mail Service (5.5.2653.19) id ; Sat, 7 Sep 2002 18:48:17 -0700 Received: from [172.16.224.92] (172.16.224.92 [172.16.224.92]) by mail-sc-0.nvidia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Q0337BJS; Sat, 7 Sep 2002 18:48:11 -0700 From: Andy Ritger To: Chris Wedgwood Cc: Axel Thimm , linux-xfs@oss.sgi.com, linux-bugs@nvidia.com, =?ISO-8859-1?Q?J=F6rg_Prante?= Date: Sat, 7 Sep 2002 21:46:05 -0400 (EDT) Subject: Re: XFS & NVIDIA Bug? In-Reply-To: <20020907220352.GA2594@tapu.f00f.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 310 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ARitger@nvidia.com Precedence: bulk X-list: linux-xfs Yes, if you could narrow down which of these patches are required to reproduce the problem, that would be very helpful. My development machine is 2.4.18+xfs and I've not experienced any problems. - Andy Ritger On Sat, 7 Sep 2002, Chris Wedgwood wrote: > On Sat, Sep 07, 2002 at 10:50:41PM +0200, Axel Thimm wrote: > > o XFS for 2.4.19 > o rmap-13b > o O1-Scheduler > o low-latency patches > o preempt-kernel > > You have *many* variables here. > > Perhaps you should try with plan 2.4.19-xfs and the NV module and see > if that is any better. > > FWIW, I use 2.4.19-cvs+rmap14a with the NV driver and don't see any > crashes, but it may be I just have luck on my side. > > > > --cw > From owner-linux-xfs@oss.sgi.com Sat Sep 7 19:32:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 19:33:01 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g882WxtG017133 for ; Sat, 7 Sep 2002 19:32:59 -0700 Received: (qmail 23223 invoked by uid 500); 8 Sep 2002 02:36:41 -0000 Subject: Re: XFS & NVIDIA Bug? From: Austin Gonyou To: Axel Thimm Cc: linux-xfs@oss.sgi.com, linux-bugs@nvidia.com, =?ISO-8859-1?Q?J=F6rg?= Prante In-Reply-To: <20020907225041.A10340@bonzo.nirvana> References: <20020907225041.A10340@bonzo.nirvana> Content-Type: text/plain; charset=ISO-8859-1 Organization: Coremetrics, Inc. Message-Id: <1031452601.22717.12.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 07 Sep 2002 21:36:41 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g882WxtG017170 X-archive-position: 312 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Just curious...have you used the -aa1 patch? On Sat, 2002-09-07 at 15:50, Axel Thimm wrote: > I am using Jörg Prante's kernel patch set 2.4.19-jp14 from > http://infolinux.de/jp/, which includes among others > > o XFS for 2.4.19 > o rmap-13b > o O1-Scheduler > o low-latency patches > o preempt-kernel > > If I try to use NVIDIA's modules (the latest available are 1.0-2960), > I get a > kernel BUG at filemap.c:236 in > > Trace; c012cc26 > Trace; c012ccee > Trace; c01b2de3 > Trace; c01c95e6 > Trace; c01d6399 > Trace; c0155efd > Trace; c013bb09 > Trace; c013bddc > Trace; c014e76f > Trace; c0108a3b > (the whole Oops is attached.) > > This happens reproducably with VMware, but also with Samba (nmbd), > which is > pure userland. It causes severe filesystem corruption. > > Using the XFree86 nv driver keeps the system stable (and the NVIDIA > card > useless). Using 2.4.18-4SGI_XFS_1.1 (with the root access fix applied) > and the > NVIDIA module also works. > > The XFS FAQ mentions that any NVIDIA driver later than 1.0-1251 would > fit. Do > maybe the newest NVIDIA modules break XFS again? > -- > Axel.Thimm@physik.fu-berlin.de > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Sat Sep 7 19:32:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Sep 2002 19:32:59 -0700 (PDT) Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g882WqtG017137 for ; Sat, 7 Sep 2002 19:32:53 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g882b3s27269; Sun, 8 Sep 2002 04:37:03 +0200 Date: Sun, 8 Sep 2002 04:37:03 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Chris Wedgwood Cc: Eric Mei , xfs-list Subject: Re: hardlink overflow Message-ID: <20020908043703.A24188@vestdata.no> References: <3D79BCE4.9050703@mountainviewdata.com> <20020907222611.GA2652@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020907222611.GA2652@tapu.f00f.org>; from cw@f00f.org on Sat, Sep 07, 2002 at 03:26:11PM -0700 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g882b3s27269 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g882WstG017139 X-archive-position: 311 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@ragnark.vestdata.no Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 03:26:11PM -0700, Chris Wedgwood wrote: > On Sat, Sep 07, 2002 at 04:46:28PM +0800, Eric Mei wrote: > > it seems linux-XFS didn't check it's overflow. simply add 65536 > > hardlink to a file will make their nlink to 0. > > Yes, I can confirm I've seen this too. It's not hard to patch this in > XFS, but in general I wonder if this fix doesn't really belong in the > VFS layer and there *are* system calls that can return larger than the > 16-bit value. There is a thread on l-k and reiserfs about this. Basicly it has been proposed to change VFS to truncate nlink or use special values (0 or 1) when nlink is to large to be exported to userspace. -- Ragnar Kjørstad From owner-linux-xfs@oss.sgi.com Sun Sep 8 04:02:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Sep 2002 04:02:42 -0700 (PDT) Received: from netmail.netcologne.de (netmail.netcologne.de [194.8.194.109]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g88B2XtG023579 for ; Sun, 8 Sep 2002 04:02:33 -0700 Received: from jungle (xdsl-213-168-110-59.netcologne.de [213.168.110.59]) by netmail.netcologne.de (Mirapoint Messaging Server MOS 2.9.3.5) with ESMTP id AZZ04660; Sun, 8 Sep 2002 13:06:14 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: =?iso-8859-1?q?J=F6rg=20Prante?= Reply-To: joerg@infolinux.de Organization: Linux Kernel Pacthset (http://infolinux.de) To: Axel Thimm , linux-xfs@oss.sgi.com Subject: Re: XFS & NVIDIA Bug? Date: Sun, 8 Sep 2002 13:05:52 +0200 X-Mailer: KMail [version 1.4] Cc: linux-bugs@nvidia.com References: <20020907225041.A10340@bonzo.nirvana> In-Reply-To: <20020907225041.A10340@bonzo.nirvana> MIME-Version: 1.0 Message-Id: <200209081305.52636.joergprante@netcologne.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g88B2YtG023580 X-archive-position: 313 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joergprante@netcologne.de Precedence: bulk X-list: linux-xfs > Do maybe the newest NVIDIA modules break XFS again? Axel, maybe you should add that the bug you have reported to me has been initiated by vmware. Also it would be helpful to note what kind of video card you use. Even more helpful it would be to describe the steps in detail how to reproduce it. Vmware is a very powerful software with many dependencies, and maybe there are certain actions you took when the bug occured. I for myself don't use vmware, but I still encounter random crashes with the nvidia driver on a Geforce 2 Go since I installed the nvidia driver many versions before, so I'm getting used to it, it's getting old. It shouldn't be concerned too much to XFS. Most it's due to dependencies between the modified kernel memory management patches in the -jp kernel patch set I guess, and that concerns both nvidia and XFS modules, and much more. The XFree86 4.2.0 server is probably concerned, too. What I observe are infrequent freezes, sometimes NULL pointers in page_alloc, sometimes panicking. I don't have much time to spend on debugging. I comfort myself that it's absolutely normal in a bleeding edge development kernel under stress testing conditions. The hard one to deal with is the nvidia driver, because I'm bound to it, but it's impossible to trace the source code, and I know most kernel hackers wish they could do so. I wish I could help to make the nvidia driver more stable, or adjustable to patches, but I can't. The file system corruption you reported is "only" a side effect of the crash. Here is the nvidia driver version I currently use: NVRM version: NVIDIA NVdriver Kernel Module 1.0-2960 Tue May 14 07:41:42 PDT 2002 GCC version: gcc version 2.95.3 20010315 (SuSE) Best Regards, Jörg From owner-linux-xfs@oss.sgi.com Sun Sep 8 13:06:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Sep 2002 13:06:57 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g88K6ntG009107 for ; Sun, 8 Sep 2002 13:06:50 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-26.quicknet.nl [212.58.163.26]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g88KAniX065196; Sun, 8 Sep 2002 22:10:49 +0200 (CEST) Message-Id: <4.3.2.7.2.20020908220418.03797d20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 08 Sep 2002 22:09:31 +0200 To: Axel Thimm , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS & NVIDIA Bug? Cc: linux-bugs@nvidia.com, =?iso-8859-1?Q?J=F6rg?= Prante In-Reply-To: <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 314 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 22:50 7-9-2002 +0200, Axel Thimm wrote: >If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get a >kernel BUG at filemap.c:236 in The kernel developers can't help you when using the nVIDIA driver for the obvious reasons also mentioned on lkml. (closed source, direct access to system resources). AFAIK the vmware modules are much of the same. Sorry! Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Sep 9 07:40:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Sep 2002 07:40:47 -0700 (PDT) Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g89EedtG008345 for ; Mon, 9 Sep 2002 07:40:40 -0700 Received: from rebel.net.au (dialup-4.rebel.net.au [203.20.69.74]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id AAA08669 for ; Tue, 10 Sep 2002 00:38:14 +0930 Message-ID: <3D7CB6CC.9D464863@rebel.net.au> Date: Tue, 10 Sep 2002 00:27:16 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS Technical Documentation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 315 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lloy0076@rebel.net.au Precedence: bulk X-list: linux-xfs Ok, I reckon I might be able to start this off; my aim would be to create documentation similar to that contained in O'Reilly's book "Understanding the Linux Kernel" with perhaps a little more detail. It is possible that I may approach O'Reilly with the aim of including the material into their book with the provision that the material remains licenced to the XFS team to develop and amend. But I am jumping ahead of myself. DSL -- Con te partiro, su navi per mari Che io lo so, no, no non esistono piu Con te io li vivro. (Sartori F, Quarantotto E) From owner-linux-xfs@oss.sgi.com Tue Sep 10 01:04:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 01:04:37 -0700 (PDT) Received: from MailUser (tamqfl1-ar8-4-46-216-017.tamqfl1.dsl-verizon.net [4.46.216.17]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8A84VtG022973 for ; Tue, 10 Sep 2002 01:04:31 -0700 Message-Id: <200209100804.g8A84VtG022973@oss.sgi.com> Reply-To: cranfordlines.claimscenter@verizon.net From: "Steve Kelly" To: "" Subject: What happened with your forms processing idea? Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 10 Sep 2002 03:54:46 -0400 X-archive-position: 316 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Cranfordlines.claimscenter@verizon.net Precedence: bulk X-list: linux-xfs We are struggling with the decisions related to wether or not to go ahead with our plans to purchase an OCR and forms scanning solution. An outside consultant mentioned that he had heard that not to long ago you folks were considering implementing OCR technology to reduce data entry costs and improve efficiency. If you could let us know if you did move forward with any plans in that direction it would be of great help to us. May I ask what initialy prompted you to consider OCR? Did you decide it could help your compamy? What software did you go with? Would you recomend we take a look at it? At present we are still planning to continue our research until we decide which OCR system best suits our needs, then implement it quickly. If you are just starting to consider this technology feel free to stay in touch. We will let you know what we decide on and if it works for us. If you cannot advise on this please forward this E-mail to the proper individual in your company who might be able to help with this. Thanks, Steve From owner-linux-xfs@oss.sgi.com Tue Sep 10 06:53:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 06:54:01 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ADrqtG007468 for ; Tue, 10 Sep 2002 06:53:55 -0700 Received: (qmail 26708 invoked by uid 1010); 10 Sep 2002 13:58:20 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.147.29]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 13:58:20 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id 1CA43132EC for ; Tue, 10 Sep 2002 15:58:17 +0200 (CEST) Date: Tue, 10 Sep 2002 15:58:14 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <527280437.20020910155814@huno.net> To: linux-xfs@oss.sgi.com Subject: raid1 (u)mount error MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 317 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs hello, i've got a RAID1 running that seems to not umount itself properly. so when i try to mount the system after a reboot i see: md: raid1 personality registered as nr 3 md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. ... md: md0: raid array is not clean -- starting background reconstruction ... raid1: raid set md0 not clean; reconstructing mirrors ... md: syncing RAID array md0 ... XFS mounting filesystem md(9,0) XFS: failed to locate log tail XFS: log mount/recovery failed XFS: log mount failed now i don't have /dev/md0 in fstab just to be sure that it doesn't try to mount itself before the raid array is started. but it doesn't matter. whatever i try the only thing that helps is xfs_repair -L /dev/md0, after that it mounts without any problems. stock 2.4.19 kernel with xfs patch applied, compiled with gcc3.1.1 - anyone got a clue what is going on? thx thomas From owner-linux-xfs@oss.sgi.com Tue Sep 10 08:27:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 08:27:49 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AFRgtG015988 for ; Tue, 10 Sep 2002 08:27:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA66115 for ; Tue, 10 Sep 2002 10:32:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA07113 for ; Tue, 10 Sep 2002 10:32:06 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AFTlG00913; Tue, 10 Sep 2002 10:29:47 -0500 Message-Id: <200209101529.g8AFTlG00913@jen.americas.sgi.com> Date: Tue, 10 Sep 2002 10:29:47 -0500 Subject: TAKE - merge up to 2.5.34 To: linux-xfs@oss.sgi.com X-archive-position: 318 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Getting to be almost a noop now, just remove a list_t use from xfs Date: Tue Sep 10 08:28:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127018a linux/include/asm-i386/max_numnodes.h - 1.1 linux/arch/i386/mm/discontig.c - 1.1 linux/arch/i386/kernel/numaq.c - 1.1 linux/include/asm-alpha/kmap_types.h - 1.1 linux/include/asm-i386/mmzone.h - 1.1 linux/include/asm-i386/numaq.h - 1.1 linux/include/linux/rmap-locking.h - 1.1 linux/net/x25/x25_in.c - 1.10 linux/net/socket.c - 1.41 linux/net/packet/af_packet.c - 1.34 linux/net/ipx/Makefile - 1.8 linux/net/ipv6/af_inet6.c - 1.25 linux/net/ipv4/tcp_output.c - 1.32 linux/net/ipv4/tcp_input.c - 1.40 linux/net/ipv4/igmp.c - 1.18 linux/net/ipv4/af_inet.c - 1.39 linux/net/core/sock.c - 1.27 linux/net/core/dst.c - 1.10 linux/net/802/Makefile - 1.10 linux/mm/vmscan.c - 1.110 linux/mm/page_alloc.c - 1.89 linux/mm/memory.c - 1.90 linux/mm/filemap.c - 1.132 linux/kernel/sysctl.c - 1.56 linux/kernel/softirq.c - 1.28 linux/kernel/signal.c - 1.39 linux/kernel/sched.c - 1.80 linux/kernel/ksyms.c - 1.162 linux/kernel/fork.c - 1.68 linux/kernel/exit.c - 1.52 linux/init/main.c - 1.89 linux/include/net/tcp.h - 1.35 linux/include/net/sock.h - 1.33 linux/include/net/inet_common.h - 1.5 linux/include/linux/sysctl.h - 1.60 linux/include/linux/sched.h - 1.81 linux/include/linux/ptrace.h - 1.4 linux/include/linux/pci.h - 1.63 linux/include/linux/mm.h - 1.98 linux/include/linux/list.h - 1.18 linux/include/linux/igmp.h - 1.7 linux/include/linux/genhd.h - 1.23 linux/include/linux/fs.h - 1.189 linux/include/linux/blkdev.h - 1.66 linux/include/asm-sparc64/hardirq.h - 1.17 linux/include/asm-sparc/hardirq.h - 1.14 linux/include/asm-ppc/semaphore.h - 1.9 linux/include/asm-ppc/pci-bridge.h - 1.10 linux/include/asm-ppc/io.h - 1.18 linux/include/asm-ppc/hardirq.h - 1.20 linux/include/asm-ppc/elf.h - 1.12 linux/include/asm-i386/spinlock.h - 1.27 linux/include/asm-i386/pgtable.h - 1.37 linux/include/asm-i386/page.h - 1.29 linux/include/asm-i386/io.h - 1.28 linux/include/asm-alpha/user.h - 1.3 linux/include/asm-alpha/pgtable.h - 1.36 linux/include/asm-alpha/ide.h - 1.11 linux/include/asm-alpha/floppy.h - 1.6 linux/include/asm-alpha/dma.h - 1.6 linux/include/asm-alpha/core_t2.h - 1.9 linux/fs/sysv/dir.c - 1.17 linux/fs/namei.c - 1.60 linux/fs/minix/dir.c - 1.14 linux/fs/locks.c - 1.31 linux/fs/lockd/svc.c - 1.19 linux/fs/lockd/clntlock.c - 1.12 linux/fs/file_table.c - 1.22 linux/fs/fcntl.c - 1.24 linux/fs/fat/inode.c - 1.47 linux/fs/ext2/dir.c - 1.24 linux/fs/exec.c - 1.63 linux/fs/buffer.c - 1.132 linux/fs/block_dev.c - 1.57 linux/fs/binfmt_elf.c - 1.46 linux/fs/affs/file.c - 1.30 linux/fs/Makefile - 1.68 linux/drivers/video/Makefile - 1.44 linux/drivers/scsi/sym53c8xx.c - 1.34 linux/drivers/scsi/st.c - 1.51 linux/drivers/scsi/sr_vendor.c - 1.13 linux/drivers/scsi/sr_ioctl.c - 1.26 linux/drivers/scsi/sr.h - 1.9 linux/drivers/scsi/sr.c - 1.50 linux/drivers/scsi/sd.h - 1.8 linux/drivers/scsi/sd.c - 1.68 linux/drivers/scsi/scsi_error.c - 1.29 linux/drivers/scsi/qlogicfc.h - 1.11 linux/drivers/scsi/qlogicfc.c - 1.30 linux/drivers/pci/quirks.c - 1.30 linux/drivers/isdn/sc/timer.c - 1.6 linux/drivers/isdn/sc/shmem.c - 1.4 linux/drivers/isdn/sc/packet.c - 1.5 linux/drivers/isdn/sc/message.c - 1.6 linux/drivers/isdn/sc/ioctl.c - 1.7 linux/drivers/isdn/sc/interrupt.c - 1.6 linux/drivers/isdn/sc/event.c - 1.4 linux/drivers/isdn/sc/command.c - 1.7 linux/drivers/isdn/pcbit/drv.c - 1.14 linux/drivers/isdn/hisax/teles3.c - 1.15 linux/drivers/isdn/hisax/teles0.c - 1.13 linux/drivers/isdn/hisax/teleint.c - 1.12 linux/drivers/isdn/hisax/tei.c - 1.11 linux/drivers/isdn/hisax/sportster.c - 1.12 linux/drivers/isdn/hisax/sedlbauer.c - 1.19 linux/drivers/isdn/hisax/q931.c - 1.7 linux/drivers/isdn/hisax/niccy.c - 1.17 linux/drivers/isdn/hisax/netjet.c - 1.21 linux/drivers/isdn/hisax/mic.c - 1.11 linux/drivers/isdn/hisax/lmgr.c - 1.7 linux/drivers/isdn/hisax/l3dss1.c - 1.15 linux/drivers/isdn/hisax/l3_1tr6.c - 1.11 linux/drivers/isdn/hisax/ix1_micro.c - 1.12 linux/drivers/isdn/hisax/isdnl3.c - 1.15 linux/drivers/isdn/hisax/isdnl2.c - 1.14 linux/drivers/isdn/hisax/isdnl1.c - 1.16 linux/drivers/isdn/hisax/isac.c - 1.13 linux/drivers/isdn/hisax/hscx.c - 1.12 linux/drivers/isdn/hisax/hfc_2bs0.c - 1.15 linux/drivers/isdn/hisax/hfc_2bds0.c - 1.15 linux/drivers/isdn/hisax/fsm.c - 1.12 linux/drivers/isdn/hisax/elsa.c - 1.20 linux/drivers/isdn/hisax/diva.c - 1.16 linux/drivers/isdn/hisax/callc.c - 1.18 linux/drivers/isdn/hisax/avm_a1.c - 1.12 linux/drivers/isdn/hisax/asuscom.c - 1.15 linux/drivers/isdn/hisax/arcofi.c - 1.11 linux/drivers/isdn/hisax/amd7930.c - 1.12 linux/drivers/isdn/act2000/capi.c - 1.7 linux/drivers/isdn/act2000/act2000_isa.c - 1.9 linux/drivers/char/tty_io.c - 1.50 linux/drivers/char/ftape/lowlevel/Makefile - 1.5 linux/drivers/char/Makefile - 1.71 linux/drivers/cdrom/sbpcd.h - 1.5 linux/drivers/cdrom/sbpcd.c - 1.27 linux/drivers/cdrom/mcdx.c - 1.18 linux/drivers/cdrom/cdu31a.c - 1.20 linux/drivers/cdrom/cdrom.c - 1.45 linux/drivers/block/xd.c - 1.43 linux/drivers/block/rd.c - 1.57 linux/drivers/block/ps2esdi.c - 1.45 linux/drivers/block/paride/pd.c - 1.35 linux/drivers/block/paride/pcd.c - 1.23 linux/drivers/block/loop.c - 1.64 linux/drivers/block/ll_rw_blk.c - 1.111 linux/drivers/block/genhd.c - 1.32 linux/drivers/block/floppy.c - 1.47 linux/drivers/block/acsi.c - 1.36 linux/drivers/block/Makefile - 1.28 linux/drivers/acorn/block/mfmhd.c - 1.29 linux/arch/sparc64/mm/init.c - 1.48 linux/arch/sparc64/lib/VIScsum.S - 1.6 linux/arch/sparc64/kernel/process.c - 1.40 linux/arch/sparc64/kernel/ioctl32.c - 1.56 linux/arch/sparc64/defconfig - 1.74 linux/arch/sparc/mm/sun4c.c - 1.36 linux/arch/sparc/mm/srmmu.c - 1.36 linux/arch/sparc/mm/fault.c - 1.21 linux/arch/sparc/kernel/process.c - 1.30 linux/arch/sparc/kernel/pcic.c - 1.22 linux/arch/ppc/mm/fault.c - 1.22 linux/arch/ppc/kernel/smp.c - 1.43 linux/arch/ppc/kernel/setup.c - 1.49 linux/arch/ppc/kernel/process.c - 1.41 linux/arch/ppc/kernel/ppc_ksyms.c - 1.49 linux/arch/ppc/kernel/ppc_htab.c - 1.19 linux/arch/ppc/kernel/pci.c - 1.28 linux/arch/ppc/kernel/indirect_pci.c - 1.8 linux/arch/ppc/kernel/Makefile - 1.30 linux/arch/ppc/amiga/config.c - 1.19 linux/arch/ppc/amiga/Makefile - 1.8 linux/arch/ppc/8xx_io/uart.c - 1.21 linux/arch/m68k/sun3x/Makefile - 1.5 linux/arch/m68k/hp300/Makefile - 1.4 linux/arch/i386/vmlinux.lds - 1.19 linux/arch/i386/mm/init.c - 1.41 linux/arch/i386/mm/Makefile - 1.8 linux/arch/i386/kernel/setup.c - 1.82 linux/arch/i386/kernel/irq.c - 1.47 linux/arch/i386/kernel/init_task.c - 1.10 linux/arch/i386/kernel/Makefile - 1.34 linux/arch/i386/config.in - 1.88 linux/arch/i386/Makefile - 1.30 linux/arch/arm/mm/init.c - 1.32 linux/arch/alpha/kernel/traps.c - 1.22 linux/arch/alpha/kernel/time.c - 1.23 linux/arch/alpha/kernel/sys_sable.c - 1.10 linux/arch/alpha/kernel/sys_rx164.c - 1.10 linux/arch/alpha/kernel/sys_alcor.c - 1.11 linux/arch/alpha/kernel/smp.c - 1.38 linux/arch/alpha/kernel/proto.h - 1.19 linux/arch/alpha/kernel/process.c - 1.28 linux/arch/alpha/kernel/irq.c - 1.24 linux/arch/alpha/kernel/core_tsunami.c - 1.21 linux/arch/alpha/kernel/core_t2.c - 1.13 linux/arch/alpha/kernel/core_polaris.c - 1.13 linux/arch/alpha/kernel/core_mcpcia.c - 1.19 linux/arch/alpha/kernel/core_lca.c - 1.14 linux/arch/alpha/kernel/core_cia.c - 1.25 linux/arch/alpha/kernel/core_apecs.c - 1.14 linux/arch/alpha/Makefile - 1.18 linux/Makefile - 1.215 linux/MAINTAINERS - 1.116 linux/include/linux/ide.h - 1.61 linux/drivers/isdn/hisax/telespci.c - 1.12 linux/drivers/isdn/hisax/s0box.c - 1.9 linux/drivers/isdn/hisax/isar.c - 1.18 linux/drivers/isdn/hisax/avm_pci.c - 1.15 linux/drivers/isdn/hisax/avm_a1p.c - 1.9 linux/drivers/isdn/eicon/eicon_idi.c - 1.15 linux/drivers/block/blkpg.c - 1.27 linux/arch/ppc/xmon/start.c - 1.20 linux/arch/i386/vmlinux.lds.S - 1.6 linux/drivers/block/cpqarray.c - 1.54 linux/kernel/ptrace.c - 1.25 linux/include/asm-i386/setup.h - 1.3 linux/include/linux/threads.h - 1.5 linux/drivers/net/ppp_generic.c - 1.30 linux/fs/partitions/check.c - 1.50 linux/fs/partitions/Makefile - 1.11 linux/drivers/isdn/hisax/saphir.c - 1.10 linux/drivers/isdn/hisax/jade.c - 1.10 linux/drivers/isdn/hisax/isurf.c - 1.12 linux/drivers/isdn/hisax/hfcscard.c - 1.10 linux/drivers/isdn/hisax/hfc_pci.c - 1.24 linux/drivers/isdn/hisax/gazel.c - 1.14 linux/drivers/isdn/hisax/bkm_a8.c - 1.13 linux/drivers/isdn/hisax/bkm_a4t.c - 1.13 linux/drivers/isdn/divert/divert_procfs.c - 1.20 linux/arch/alpha/kernel/pci_impl.h - 1.11 linux/arch/alpha/kernel/pci.c - 1.22 linux/drivers/block/DAC960.h - 1.18 linux/drivers/block/DAC960.c - 1.53 linux/arch/sparc64/kernel/pci_sabre.c - 1.31 linux/arch/sparc64/kernel/pci_psycho.c - 1.29 linux/arch/sh/mm/init.c - 1.20 linux/include/asm-i386/pci.h - 1.19 linux/drivers/pcmcia/Makefile - 1.19 linux/include/linux/pci_ids.h - 1.72 linux/mm/highmem.c - 1.42 linux/mm/bootmem.c - 1.22 linux/include/linux/highmem.h - 1.25 linux/include/linux/bootmem.h - 1.9 linux/include/asm-i386/highmem.h - 1.13 linux/drivers/isdn/hisax/w6692.c - 1.13 linux/include/asm-ppc/pgalloc.h - 1.12 linux/include/asm-i386/pgalloc.h - 1.22 linux/arch/alpha/kernel/core_irongate.c - 1.12 linux/mm/numa.c - 1.12 linux/include/linux/mmzone.h - 1.25 linux/drivers/char/agp/agp.h - 1.27 linux/drivers/i2c/Makefile - 1.7 linux/drivers/pci/setup-res.c - 1.11 linux/arch/ppc/kernel/galaxy_pci.c - 1.5 linux/arch/ia64/config.in - 1.35 linux/arch/alpha/kernel/pci_iommu.c - 1.19 linux/include/linux/raid/md.h - 1.18 linux/drivers/net/8139too.c - 1.42 linux/drivers/isdn/hisax/hfc_sx.c - 1.13 linux/drivers/isdn/hysdn/hysdn_net.c - 1.10 linux/drivers/isdn/hysdn/hysdn_procconf.c - 1.15 linux/drivers/isdn/hysdn/hysdn_proclog.c - 1.14 linux/include/asm-mips64/pgtable.h - 1.14 linux/include/asm-mips64/mmzone.h - 1.8 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.10 linux/net/econet/af_econet.c - 1.13 linux/drivers/ide/ide.c - 1.64 linux/drivers/ide/ide-probe.c - 1.35 linux/drivers/ide/ide-geometry.c - 1.16 linux/drivers/ide/ide-floppy.c - 1.34 linux/drivers/ide/ide-disk.c - 1.46 linux/drivers/ide/ide-cd.c - 1.46 linux/drivers/ide/hd.c - 1.28 linux/drivers/ide/Makefile - 1.27 linux/net/ipv4/netfilter/ipfwadm_core.c - 1.13 linux/net/ipv4/netfilter/ipchains_core.c - 1.12 linux/net/ipv4/netfilter/Makefile - 1.17 linux/fs/ramfs/inode.c - 1.29 linux/arch/ppc/8260_io/uart.c - 1.12 linux/drivers/s390/block/dasd.c - 1.28 linux/fs/xfs/xfs_dmapi.c - 1.84 linux/drivers/usb/storage/usb.c - 1.27 linux/arch/alpha/kernel/core_titan.c - 1.6 linux/arch/alpha/kernel/core_wildfire.c - 1.3 linux/include/asm-arm/memory.h - 1.6 linux/fs/jffs/inode-v23.c - 1.31 linux/drivers/mtd/ftl.c - 1.22 linux/drivers/net/tun.c - 1.16 linux/net/ipv4/tcp_minisocks.c - 1.15 linux/include/asm-sparc/highmem.h - 1.6 linux/drivers/usb/storage/sddr09.c - 1.17 linux/drivers/isdn/hisax/nj_u.c - 1.10 linux/drivers/isdn/hisax/nj_s.c - 1.11 linux/drivers/isdn/hisax/l3ni1.c - 1.8 linux/drivers/isdn/hisax/icc.c - 1.7 linux/drivers/isdn/eicon/linchr.c - 1.7 linux/drivers/block/cciss.c - 1.41 linux/drivers/block/cciss.h - 1.13 linux/drivers/md/md.c - 1.53 linux/fs/dnotify.c - 1.6 linux/include/asm-ppc/highmem.h - 1.9 linux/arch/i386/kernel/dmi_scan.c - 1.20 linux/fs/reiserfs/stree.c - 1.27 linux/fs/reiserfs/super.c - 1.28 linux/fs/reiserfs/tail_conversion.c - 1.18 linux/fs/reiserfs/resize.c - 1.8 linux/fs/reiserfs/namei.c - 1.26 linux/arch/sparc64/kernel/pci_schizo.c - 1.16 linux/fs/reiserfs/journal.c - 1.33 linux/fs/reiserfs/inode.c - 1.34 linux/fs/reiserfs/hashes.c - 1.4 linux/fs/reiserfs/fix_node.c - 1.26 linux/include/linux/reiserfs_fs.h - 1.31 linux/include/linux/reiserfs_fs_i.h - 1.7 linux/include/linux/reiserfs_fs_sb.h - 1.15 linux/fs/reiserfs/bitmap.c - 1.19 linux/arch/cris/mm/init.c - 1.9 linux/net/wanrouter/af_wanpipe.c - 1.8 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.5 linux/include/linux/compiler.h - 1.6 linux/include/asm-alpha/mmzone.h - 1.3 linux/arch/alpha/mm/numa.c - 1.5 linux/drivers/mtd/nftlcore.c - 1.22 linux/drivers/acpi/Config.in - 1.7 linux/drivers/char/sonypi.h - 1.9 linux/arch/mips/au1000/common/Makefile - 1.4 linux/drivers/net/ns83820.c - 1.14 linux/fs/jffs2/background.c - 1.10 linux/fs/jffs2/file.c - 1.10 linux/drivers/mtd/devices/blkmtd.c - 1.13 linux/drivers/i2c/i2c-proc.c - 1.6 linux/drivers/message/i2o/i2o_block.c - 1.20 linux/drivers/message/i2o/Makefile - 1.3 linux/drivers/scsi/sym53c8xx_2/sym_glue.c - 1.7 linux/fs/ext3/inode.c - 1.18 linux/fs/intermezzo/kml_utils.c - 1.2 linux/fs/reiserfs/procfs.c - 1.10 linux/fs/driverfs/inode.c - 1.20 linux/include/linux/device.h - 1.15 linux/init/do_mounts.c - 1.18 linux/include/linux/init_task.h - 1.11 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.4 linux/arch/i386/Config.help - 1.11 linux/drivers/pnp/pnpbios_core.c - 1.11 linux/arch/ppc/4xx_io/serial_sicc.c - 1.2 linux/arch/ppc/8xx_io/cs4218_tdm.c - 1.2 linux/arch/ppc/iSeries/LparData.c - 1.2 linux/arch/ppc/iSeries/rtc.c - 1.4 linux/arch/ppc/kernel/ppc4xx_serial.c - 1.2 linux/arch/ppc/platforms/apus_pci.c - 1.2 linux/arch/ppc/platforms/apus_setup.c - 1.5 linux/arch/ppc/platforms/chrp_pci.c - 1.2 linux/arch/ppc/platforms/gemini_pci.c - 1.2 linux/arch/ppc/platforms/pmac_pci.c - 1.3 linux/arch/ppc/platforms/proc_rtas.c - 1.2 linux/include/asm-ppc64/page.h - 1.6 linux/drivers/isdn/hisax/hisax_hfcpci.c - 1.3 linux/fs/jfs/jfs_metapage.h - 1.5 linux/drivers/hotplug/ibmphp_hpc.c - 1.4 linux/fs/jfs/file.c - 1.10 linux/fs/jfs/inode.c - 1.12 linux/fs/jfs/jfs_dtree.c - 1.7 linux/fs/jfs/jfs_extendfs.h - 1.3 linux/fs/jfs/jfs_extent.c - 1.4 linux/fs/jfs/jfs_incore.h - 1.9 linux/fs/jfs/jfs_imap.c - 1.7 linux/fs/jfs/namei.c - 1.11 linux/fs/jfs/jfs_logmgr.c - 1.15 linux/fs/jfs/super.c - 1.13 linux/fs/jfs/jfs_mount.c - 1.9 linux/fs/jfs/jfs_superblock.h - 1.4 linux/fs/jfs/jfs_txnmgr.c - 1.14 linux/fs/jfs/jfs_umount.c - 1.5 linux/fs/jfs/jfs_metapage.c - 1.10 linux/kernel/futex.c - 1.7 linux/include/asm-i386/tlbflush.h - 1.3 linux/include/asm-generic/percpu.h - 1.3 linux/mm/pdflush.c - 1.5 linux/drivers/isdn/i4l/isdn_ppp.c - 1.6 linux/drivers/block/umem.c - 1.7 linux/arch/i386/pci/fixup.c - 1.3 linux/drivers/pci/probe.c - 1.5 linux/include/linux/page-flags.h - 1.7 linux/kernel/suspend.c - 1.10 linux/drivers/char/hvc_console.c - 1.4 linux/drivers/isdn/hisax/amd7930_fn.c - 1.3 linux/drivers/isdn/hisax/enternow_pci.c - 1.2 linux/drivers/isdn/hisax/ipacx.c - 1.3 linux/drivers/s390/block/dasd_genhd.c - 1.5 linux/drivers/char/agp/agp.c - 1.2 linux/mm/rmap.c - 1.5 linux/include/asm-ppc64/mmzone.h - 1.3 linux/arch/i386/mm/pgtable.c - 1.2 linux/include/linux/preempt.h - 1.4 linux/drivers/base/fs/Makefile - 1.3 linux/fs/jfs/resize.c - 1.3 linux/fs/aio.c - 1.2 linux/fs/jfs/xattr.c - 1.2 linux/net/sctp/protocol.c - 1.2 linux/net/sctp/associola.c - 1.2 linux/net/sctp/bind_addr.c - 1.2 linux/net/sctp/endpointola.c - 1.2 linux/net/sctp/outqueue.c - 1.2 linux/net/sctp/sm_make_chunk.c - 1.2 linux/net/sctp/sm_sideeffect.c - 1.2 linux/net/sctp/sm_statefuns.c - 1.2 linux/include/net/sctp/structs.h - 1.2 linux/net/sctp/socket.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Sep 10 09:28:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 09:29:05 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AGSxtG018034 for ; Tue, 10 Sep 2002 09:28:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA66110 for ; Tue, 10 Sep 2002 11:33:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA21459 for ; Tue, 10 Sep 2002 11:33:22 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AGTTM21387; Tue, 10 Sep 2002 11:29:29 -0500 Message-Id: <200209101629.g8AGTTM21387@stout.americas.sgi.com> Date: Tue, 10 Sep 2002 11:29:29 -0500 Subject: TAKE - teach icmn_err about CE_WARN X-archive-position: 319 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs XFS error messages have different levels, although in practice they almost all turn into just a printk. icmn_err() didn't know about CE_WARN though, and so it printed out a rather cryptic message that's probably not very helpful. Add CE_WARN to the cases so it just turns into a printk like the others. Also added CE_WARN to cmn_err for consistency, although this won't change behavior at all. teach icmn_err about CE_WARN Date: Tue Sep 10 09:30:10 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127029a linux/fs/xfs/support/debug.c - 1.9 From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:18:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:18:17 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIICtG021268 for ; Tue, 10 Sep 2002 11:18:12 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id BEC701D9F5F; Tue, 10 Sep 2002 11:22:41 -0700 (PDT) Date: Tue, 10 Sep 2002 11:22:41 -0700 From: Chris Wedgwood To: thomas Cc: linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910182241.GA5230@tapu.f00f.org> References: <527280437.20020910155814@huno.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <527280437.20020910155814@huno.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 320 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 03:58:14PM +0200, thomas wrote: > i've got a RAID1 running that seems to not umount itself properly. so > when i try to mount the system after a reboot i see: > now i don't have /dev/md0 in fstab just to be sure that it > doesn't try to mount itself before the raid array is > started. but it doesn't matter. whatever i try the only thing > that helps is xfs_repair -L /dev/md0, after that it mounts > without any problems. Is this / on raid1? If so, I also see this... I put some stack dump stuff in to verify that /dev/md0 get opened *twice* as / is mounted, once I assume for the auto-raid stuff (or something?) and then again to mount / The raid1 code won't switch to RO in there is more than one reference and thus it's never able to be mounted cleanly. Sorry this doesn't provide a solution, I was tracking this down under time pressure and had to fix the problem using another means. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:26:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:26:22 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIQGtG021931 for ; Tue, 10 Sep 2002 11:26:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA67249; Tue, 10 Sep 2002 13:30:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA16097; Tue, 10 Sep 2002 13:30:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AISHn09474; Tue, 10 Sep 2002 13:28:17 -0500 Subject: Re: raid1 (u)mount error From: Steve Lord To: Chris Wedgwood Cc: thomas , linux-xfs@oss.sgi.com In-Reply-To: <20020910182241.GA5230@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 13:28:17 -0500 Message-Id: <1031682497.22845.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 321 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-10 at 13:22, Chris Wedgwood wrote: > On Tue, Sep 10, 2002 at 03:58:14PM +0200, thomas wrote: > > > i've got a RAID1 running that seems to not umount itself properly. so > > when i try to mount the system after a reboot i see: > > > now i don't have /dev/md0 in fstab just to be sure that it > > doesn't try to mount itself before the raid array is > > started. but it doesn't matter. whatever i try the only thing > > that helps is xfs_repair -L /dev/md0, after that it mounts > > without any problems. > > Is this / on raid1? > > If so, I also see this... I put some stack dump stuff in to verify > that /dev/md0 get opened *twice* as / is mounted, once I assume for > the auto-raid stuff (or something?) and then again to mount / > > The raid1 code won't switch to RO in there is more than one reference > and thus it's never able to be mounted cleanly. > > Sorry this doesn't provide a solution, I was tracking this down under > time pressure and had to fix the problem using another means. > Are you doing this with current cvs code? The xfs log used to effectively open the device again. I think this has been reworked in the current code to avoid the double open. I have not checked into this, so I might be wrong. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:37:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:38:09 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIbwtG022774 for ; Tue, 10 Sep 2002 11:37:58 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 15AA51D9F6F; Tue, 10 Sep 2002 11:42:28 -0700 (PDT) Date: Tue, 10 Sep 2002 11:42:28 -0700 From: Chris Wedgwood To: Steve Lord Cc: thomas , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910184228.GA5323@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031682497.22845.97.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 322 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 01:28:17PM -0500, Steve Lord wrote: > Are you doing this with current cvs code? I saw this about two weeks ago, whatever was current then. From the call path, XFS was only responsible for the second open though, might this still be the problem? > The xfs log used to effectively open the device again. I think this > has been reworked in the current code to avoid the double open. > I have not checked into this, so I might be wrong. I can, if you like, retest fairly easily with the head of the tree. Note, I'm talking about 2.4.x here in both messages. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:45:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:45:46 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIjitG023390 for ; Tue, 10 Sep 2002 11:45:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA68106; Tue, 10 Sep 2002 13:50:08 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA04689; Tue, 10 Sep 2002 13:50:08 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AIlmW09510; Tue, 10 Sep 2002 13:47:48 -0500 Subject: Re: raid1 (u)mount error From: Steve Lord To: Chris Wedgwood Cc: thomas , linux-xfs@oss.sgi.com In-Reply-To: <20020910184228.GA5323@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 13:47:48 -0500 Message-Id: <1031683668.22845.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 323 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-10 at 13:42, Chris Wedgwood wrote: > On Tue, Sep 10, 2002 at 01:28:17PM -0500, Steve Lord wrote: > > > Are you doing this with current cvs code? > > I saw this about two weeks ago, whatever was current then. Hmm, the code I am thinking of went on August 16th, so probably you already had it. > > >From the call path, XFS was only responsible for the second open > though, might this still be the problem? So one open for the raid resync, and one for the mount - both of those are outside XFS's control. The attempt to replay the log by making the filesystem writable in the middle of this operation is probably what gets thrown here. We remount read/write, run recovery, then remount readonly again, finally user space does its own remount read/write. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 10 11:52:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 11:52:55 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AIqrtG024049 for ; Tue, 10 Sep 2002 11:52:53 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 56180ED2C0; Tue, 10 Sep 2002 11:57:23 -0700 (PDT) Date: Tue, 10 Sep 2002 11:57:23 -0700 From: Chris Wedgwood To: Steve Lord Cc: thomas , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910185723.GA5375@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031683668.22845.102.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 324 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 01:47:48PM -0500, Steve Lord wrote: > Hmm, the code I am thinking of went on August 16th, so probably you > already had it. Yes, I'm pretty sure I would have. I will check though. > So one open for the raid resync, and one for the mount - both of > those are outside XFS's control. Yes. It seems for any other FS other than / you can remount the raid-superblock RO with "ref == 1" as the reference that is open is the process calling the ioctl to remount RO. For / fs, you always have a second reference and this screws you. I'm actually not sure how / is supposed to work on RAID so perhaps I have this wrong. > The attempt to replay the log by making the filesystem writable in > the middle of this operation is probably what gets thrown here. We > remount read/write, run recovery, then remount readonly again, > finally user space does its own remount read/write. Possibly, but this should get released again making XFS no different than any other fs... so I'm not sure XFS is to blame. I will try to get call-chains from *all* calls to the open on /dev/md0 and see what falls out. I should probably also get release information too :) --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:10:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:10:49 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJAktG024906 for ; Tue, 10 Sep 2002 12:10:46 -0700 Received: (qmail 22337 invoked by uid 500); 10 Sep 2002 19:14:34 -0000 Subject: What does this message actually mean? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031685274.21941.2.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 10 Sep 2002 14:14:34 -0500 X-archive-position: 325 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs xfs_alloc_read_agf: error in AG 51 bad agf_magicnum 0x0 Bad version number 0x0 -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:15:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:15:58 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJFstG025462 for ; Tue, 10 Sep 2002 12:15:54 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id DDE5C1D9F5F; Tue, 10 Sep 2002 12:20:23 -0700 (PDT) Date: Tue, 10 Sep 2002 12:20:23 -0700 From: Chris Wedgwood To: thomas Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910192023.GA5470@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1298234671.20020910211407@huno.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 326 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 09:14:07PM +0200, thomas wrote: > nope / is reiserfs. and this is /dev/md0 for you? or something else? if this is the device with umount errors, then I'm pretty sure we can't blame XFS :) > i am a bit confused now though cause i'm not completely sure if two > threads didn't get mixed together here :) so do you suggest steve to > get current cvs for the fix you put in august 16th? the changed to cvs by sandeclaws on the 16th will only affect XFS, so unless this is the fs with has umount problems, it won't affect you --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:17:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:17:56 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJHrtG025957 for ; Tue, 10 Sep 2002 12:17:53 -0700 Received: (qmail 5485 invoked by uid 1010); 10 Sep 2002 19:14:12 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.153.65]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 19:14:12 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id DADD3134C6; Tue, 10 Sep 2002 21:14:09 +0200 (CEST) Date: Tue, 10 Sep 2002 21:14:07 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <1298234671.20020910211407@huno.net> To: Chris Wedgwood , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error In-Reply-To: <20020910185723.GA5375@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 327 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs > Is this / on raid1? nope / is reiserfs. i am a bit confused now though cause i'm not completely sure if two threads didn't get mixed together here :) so do you suggest steve to get current cvs for the fix you put in august 16th? thomas From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:22:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:22:16 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJMEtG026512 for ; Tue, 10 Sep 2002 12:22:14 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA66365; Tue, 10 Sep 2002 14:26:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA30117; Tue, 10 Sep 2002 14:26:38 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AJOIk09568; Tue, 10 Sep 2002 14:24:18 -0500 Subject: Re: What does this message actually mean? From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031685274.21941.2.camel@UberGeek.coremetrics.com> References: <1031685274.21941.2.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 10 Sep 2002 14:24:17 -0500 Message-Id: <1031685857.22954.107.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 328 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-10 at 14:14, Austin Gonyou wrote: > xfs_alloc_read_agf: error in AG 51 > bad agf_magicnum 0x0 > Bad version number 0x0 It means you got zeros on the disk where there was supposed to be metadata. I would run xfs_check on the unmounted fs, and then run xfs_repair. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:39:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:39:37 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJdWtG027231 for ; Tue, 10 Sep 2002 12:39:32 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id E913D1D9F8F; Tue, 10 Sep 2002 12:44:01 -0700 (PDT) Date: Tue, 10 Sep 2002 12:44:01 -0700 From: Chris Wedgwood To: Steve Lord Cc: thomas , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910194401.GA9951@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031682497.22845.97.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 329 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 01:28:17PM -0500, Steve Lord wrote: > I have not checked into this, so I might be wrong. <7 reboots of a test machine later> Actually... turns out you are correct :) At least I think so ... post Aug15 test kernels work as expected, they do not prevent / on md XFS to fail as I saw earlier. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 12:52:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 12:52:36 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AJqXtG027849 for ; Tue, 10 Sep 2002 12:52:33 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 70D8F1D9FBC; Tue, 10 Sep 2002 12:57:03 -0700 (PDT) Date: Tue, 10 Sep 2002 12:57:03 -0700 From: Chris Wedgwood To: thomas Cc: linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error Message-ID: <20020910195703.GA9987@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> <20020910192023.GA5470@tapu.f00f.org> <1019359078.20020910213251@huno.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1019359078.20020910213251@huno.net> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 330 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Tue, Sep 10, 2002 at 09:32:51PM +0200, thomas wrote: > +[~]: df -Th > Filesystem Type Size Used Avail Use% Mounted on > /dev/hda1 reiserfs 2.2G 430M 1.8G 20% / > /dev/hdc1 reiserfs 2.2G 1.6G 634M 72% /var > /dev/md0 xfs 75G 69G 5.9G 93% /data so what does umount /data raidstop /dev/md0 do? > now if there is a chance that cvs *might* help here i'm on my way to > grab it. can i patch cvs with 2.4.19 or do i have to get > 2.4.20-pre5? 2.4.20-pre5/6 won't help ... you want xfs from CVS post Aug 16. Are you able to give that a go? --cw From owner-linux-xfs@oss.sgi.com Tue Sep 10 13:17:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 13:17:48 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AKHhtG028830 for ; Tue, 10 Sep 2002 13:17:44 -0700 Received: (qmail 5836 invoked by uid 1010); 10 Sep 2002 20:22:12 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.147.22]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 20:22:12 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id F1C1A134F5; Tue, 10 Sep 2002 22:22:08 +0200 (CEST) Date: Tue, 10 Sep 2002 22:22:03 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <5112311328.20020910222203@huno.net> To: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error In-Reply-To: <20020910195703.GA9987@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> <20020910192023.GA5470@tapu.f00f.org> <1019359078.20020910213251@huno.net> <20020910195703.GA9987@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 331 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs while i was waiting for the responses i made a fresh 2.4.19-xfs with gcc2.95 just for kicks and guess what the error vanished. now the only difference between this kernel and the older one was the gcc version (3.1.1 vs 2.95.4) and the older one had some crazy CFLAGS, because i tried to optimize it for my VIA C3. i double checked and booted with the old kernel again and the error is back. i did this several times (new>old>new>old>new) just to be extra sure. false alarm, no xfs problem :) thomas From owner-linux-xfs@oss.sgi.com Tue Sep 10 13:23:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 13:23:12 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AKNAtG029393 for ; Tue, 10 Sep 2002 13:23:10 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA68639 for ; Tue, 10 Sep 2002 15:27:34 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA63815 for ; Tue, 10 Sep 2002 15:27:34 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8AKNdB29305; Tue, 10 Sep 2002 15:23:39 -0500 Message-Id: <200209102023.g8AKNdB29305@stout.americas.sgi.com> Date: Tue, 10 Sep 2002 15:23:39 -0500 Subject: TAKE - change symlink perms to 777 X-archive-position: 332 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs XFS symlinks were behaving a little differently than every other filesystem on linux... we set perms as: mode = 0777 & ~current->fs->umask; which is how irix does it as well. but ext2/3/reiser etc all just set it to 777, so we'll do that too. change symlink perms to 777 Date: Tue Sep 10 13:21:58 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127049a linux/fs/xfs/linux/xfs_iops.c - 1.173 From owner-linux-xfs@oss.sgi.com Tue Sep 10 14:21:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 14:21:52 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ALLitG030886 for ; Tue, 10 Sep 2002 14:21:44 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 848F11DA025; Tue, 10 Sep 2002 14:26:14 -0700 (PDT) Date: Tue, 10 Sep 2002 14:26:14 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020910212614.GA10273@tapu.f00f.org> References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="R3G7APHDIzY6R/pk" Content-Disposition: inline In-Reply-To: <200209102023.g8AKNdB29305@stout.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 333 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > XFS symlinks were behaving a little differently than every other > filesystem on linux... we set perms as: > mode = 0777 & ~current->fs->umask; > which is how irix does it as well. > but ext2/3/reiser etc all just set it to 777, so we'll do that too. > change symlink perms to 777 ... to fix those already on your fs --cw P.S. Don't bitch, just send patches. --R3G7APHDIzY6R/pk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=GNUmakefile # GNUmakefile for sl-frob # # $Id: GNUmakefile,v 1.1 2002/09/10 21:23:27 cw Exp $ CFLAGS+="-Wall" all: strip sl-frob: sl-frob.o strip: sl-frob strip sl-frob clean: rm -f *~ *.o sl-frob rcsclean --R3G7APHDIzY6R/pk Content-Type: text/x-csrc; charset=us-ascii Content-Disposition: attachment; filename="sl-frob.c" /* * sl-frob.c * * 'stat' and recreate symlink is the perms are not 0777 as they * should be. This may be required if symlink permissions for all * hosed or messed up (for example, early versions of XFS would create * symlinks as non-0777 as it obeyed the umask). * * Usage is something like: * * find /path/to/fs -mount -type l -not -perm 777 -print0 | xargs -0 /path/to/sl-frob * * $Id: sl-frob.c,v 1.1 2002/09/10 21:19:37 cw Exp $ */ #include #include #include #include #include #include int main(int ac, char **av) { int i; struct stat st; char lpath[4096]; int nchar; if (ac < 2) { fprintf(stderr, "%s: filename \n\trecreate symlinks with busted perms\n", av[0]); return 1; } /* old versions of XFS will obey the umask */ umask(0); for (i=1; i '%s' (%s)\n", av[i], lpath, strerror(errno)); fprintf(stderr, "\tTHIS IS BAD --- MANUALLY FIX THIS\n"); continue; } } } return 0; } --R3G7APHDIzY6R/pk-- From owner-linux-xfs@oss.sgi.com Tue Sep 10 15:56:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Sep 2002 15:56:28 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8AMuMtG004213 for ; Tue, 10 Sep 2002 15:56:22 -0700 Received: (qmail 22774 invoked by uid 500); 10 Sep 2002 23:00:21 -0000 Subject: Re: What does this message actually mean? From: Austin Gonyou To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1031685857.22954.107.camel@jen.americas.sgi.com> References: <1031685857.22954.107.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031698821.21946.15.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 10 Sep 2002 18:00:21 -0500 X-archive-position: 334 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs It appears that we're all good after running the xfs_repair. Everything seemed to be working ok otherwise, so I didn't know why this error would be there. Either way..it looks happy now.:) On Tue, 2002-09-10 at 14:24, Steve Lord wrote: > On Tue, 2002-09-10 at 14:14, Austin Gonyou wrote: > > xfs_alloc_read_agf: error in AG 51 > > bad agf_magicnum 0x0 > > Bad version number 0x0 > > It means you got zeros on the disk where there was supposed to be > metadata. I would run xfs_check on the unmounted fs, and then run > xfs_repair. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 11 00:13:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 00:14:06 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8B7DxtG032603 for ; Wed, 11 Sep 2002 00:13:59 -0700 Received: from erbenson.alaska.net (6-pm29.nwc.alaska.net [209.112.158.6]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8B7IQBs039973 for ; Tue, 10 Sep 2002 23:18:27 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 6B0363A0F for ; Tue, 10 Sep 2002 23:18:25 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id BF3CC4104E2; Tue, 10 Sep 2002 23:18:24 -0800 (AKDT) Date: Tue, 10 Sep 2002 23:18:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020911071824.GG714@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f5QefDQHtn8hx44O" Content-Disposition: inline In-Reply-To: <20020910212614.GA10273@tapu.f00f.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 335 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --f5QefDQHtn8hx44O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: >=20 > > XFS symlinks were behaving a little differently than every other > > filesystem on linux... we set perms as: >=20 > > mode =3D 0777 & ~current->fs->umask; >=20 > > which is how irix does it as well. >=20 > > but ext2/3/reiser etc all just set it to 777, so we'll do that too. >=20 > > change symlink perms to 777 >=20 > ... to fix those already on your fs why? symlink permissions are completly irrelevant. bsd also sets symlink perms according to umask, i actually prefer that since world writable files throw a red flag in my mind when inspecting permission.=20 i think if one were to set a standard uniform permission on symlinks it should be 444 or 555, symlinks by thier nature are readonly, the only way to alter them is unlink() and re symlink() so why pretend. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --f5QefDQHtn8hx44O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1+7kAACgkQJKx7GixEevyOHQCfTIeQVuTZf7VD3h/YrDTY2Brf M2UAnRr5YLsTPwHQe7Ect6mxANbBQ+/2 =0VJu -----END PGP SIGNATURE----- --f5QefDQHtn8hx44O-- From owner-linux-xfs@oss.sgi.com Wed Sep 11 05:19:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 05:19:09 -0700 (PDT) Received: from fruit.eu.org (qmailr@d5111f5b.cable.wanadoo.nl [213.17.31.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BCJ1tG013698 for ; Wed, 11 Sep 2002 05:19:02 -0700 Received: (qmail 25463 invoked by uid 500); 11 Sep 2002 12:23:32 -0000 Date: Wed, 11 Sep 2002 14:23:32 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020911122332.GD17696@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020911071824.GG714@plato.local.lan> User-Agent: Mutt/1.4i X-oi: oi X-archive-position: 336 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-10 23:18:24-0800, Ethan Benson wrote: > On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > > > mode = 0777 & ~current->fs->umask; > why? symlink permissions are completly irrelevant. They are not. Consider a sticky directory. > i think if one were to set a standard uniform permission on symlinks > it should be 444 or 555, symlinks by thier nature are readonly, the > only way to alter them is unlink() and re symlink() so why pretend. That's a change that needs to be at the VFS level. For now it would just look bad for XFS to differ in behaviour. Kind regards, -- Wessel Dankers The static electricity routing is acting up... From owner-linux-xfs@oss.sgi.com Wed Sep 11 06:38:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 06:38:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BDcftG016326 for ; Wed, 11 Sep 2002 06:38:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA75089; Wed, 11 Sep 2002 08:43:05 -0500 (CDT) Received: from fsgi158.americas.sgi.com (fsgi158.americas.sgi.com [128.162.191.39]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA87801; Wed, 11 Sep 2002 08:43:04 -0500 (CDT) From: Tad Dolphay Received: by fsgi158.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) id IAA10993; Wed, 11 Sep 2002 08:43:04 -0500 (CDT) Message-Id: <200209111343.IAA10993@fsgi158.americas.sgi.com> Subject: Re: TAKE - change symlink perms to 777 To: wsl@fruit.eu.org (Wessel Dankers) Date: Wed, 11 Sep 2002 08:43:03 -0500 (CDT) Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020911122332.GD17696@fruit.eu.org> from "Wessel Dankers" at Sep 11, 2002 02:23:32 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 337 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tbd@sgi.com Precedence: bulk X-list: linux-xfs > > On 2002-09-10 23:18:24-0800, Ethan Benson wrote: > > On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > > > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > > > > mode = 0777 & ~current->fs->umask; > > > why? symlink permissions are completly irrelevant. > > They are not. Consider a sticky directory. > > > i think if one were to set a standard uniform permission on symlinks > > it should be 444 or 555, symlinks by thier nature are readonly, the > > only way to alter them is unlink() and re symlink() so why pretend. > > That's a change that needs to be at the VFS level. For now it would just > look bad for XFS to differ in behaviour. > This was discussed internally at SGI some time ago in PV 831071. At that time nobody could find any POSIX or other standard mandating that symlink perms be set to 777. Furthermore, at the time xfsrestore relied on the symlink perms being set using the umask. I don't know if this is still the case. Tad From owner-linux-xfs@oss.sgi.com Wed Sep 11 07:14:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 07:14:44 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BEEftG019159 for ; Wed, 11 Sep 2002 07:14:42 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA75171; Wed, 11 Sep 2002 09:19:08 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA31213; Wed, 11 Sep 2002 09:19:08 -0500 (CDT) Subject: Re: TAKE - change symlink perms to 777 From: Eric Sandeen To: Tad Dolphay Cc: Wessel Dankers , linux-xfs@oss.sgi.com In-Reply-To: <200209111343.IAA10993@fsgi158.americas.sgi.com> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Sep 2002 09:15:06 -0500 Message-Id: <1031753707.9726.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 338 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Ok, it sounds like there's enough going on here that I'll revert the mod for now, until I'm sure there are no other implications. (Nathan had some concerns about acls as well...) -Eric On Wed, 2002-09-11 at 08:43, Tad Dolphay wrote: > This was discussed internally at SGI some time ago in PV 831071. At that time > nobody could find any POSIX or other standard mandating that symlink > perms be set to 777. Furthermore, at the time xfsrestore relied on > the symlink perms being set using the umask. I don't know if this is > still the case. > > Tad > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 11 07:25:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 07:25:54 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BEPjtG019762 for ; Wed, 11 Sep 2002 07:25:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA75269 for ; Wed, 11 Sep 2002 09:30:13 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA28271 for ; Wed, 11 Sep 2002 09:30:13 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8BEQBp10144; Wed, 11 Sep 2002 09:26:11 -0500 Message-Id: <200209111426.g8BEQBp10144@stout.americas.sgi.com> Date: Wed, 11 Sep 2002 09:26:11 -0500 Subject: TAKE - Back out that symlink/777 change for now X-archive-position: 339 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Need to make sure that xfsdump, acls, dmapi, nathan, dean, ethan, linus, and al are happy, first. ;-) Date: Wed Sep 11 07:29:13 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean Undoes mod: 2.4.x-xfs:slinx:127049a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127120a linux/fs/xfs/linux/xfs_iops.c - 1.174 From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:12:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:12:20 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BICFtG026735 for ; Wed, 11 Sep 2002 11:12:16 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA12593; Wed, 11 Sep 2002 20:16:45 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pC1y-0003qV-00; Wed, 11 Sep 2002 20:16:02 +0200 Date: Wed, 11 Sep 2002 20:16:02 +0200 From: Christian Guggenberger To: linux-kernel@vger.kernel.org Cc: andrea@suse.de, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911201602.A13655@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.4 Lines: 24 X-archive-position: 340 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Hi! just tried out 2.4.20-pre5aa2 with xfs enabled as module. But I can't load the xfs Module... modprobe xfs just won't work. Via top on another console I see two modpobe processes, each consuming 99.9% CPU time. Then, after a minute or so, the machine reboots... System is a Dell Precision with 2 Intel Xeons@2.2GHz and 2GB RDRAM and hyper-threading enabled, OS is Debian/GNU Linux 3.0 with: gcc-2.95.4 20011002 (Debian prerelease) ld-2.12.90.0.1 20020307 Debian/GNU Linux I tried to disable HT, but then it was even worse. Then my machine crashed hard after starting "modprobe xfs". thanks in advance Christian P.S. if needed, I could post my .config, or other relevant things... From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:20:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:20:18 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIKGtG027285 for ; Wed, 11 Sep 2002 11:20:16 -0700 Received: (qmail 25103 invoked by uid 500); 11 Sep 2002 18:24:15 -0000 Subject: Re: 2.4.20pre5aa2 From: Austin Gonyou To: Christian Guggenberger Cc: linux-kernel@vger.kernel.org, andrea@suse.de, linux-xfs@oss.sgi.com In-Reply-To: <20020911201602.A13655@pc9391.uni-regensburg.de> References: <20020911201602.A13655@pc9391.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031768655.24629.23.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 11 Sep 2002 13:24:15 -0500 X-archive-position: 341 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Did you try just using insmod, instead of modprobe. To use modprobe, your module must have something defined in /etc/modules.conf On Wed, 2002-09-11 at 13:16, Christian Guggenberger wrote: > Hi! > > just tried out 2.4.20-pre5aa2 with xfs enabled as module. But I can't > load > the xfs Module... > modprobe xfs just won't work. Via top on another console I see two > modpobe > processes, each consuming 99.9% CPU time. Then, after a minute or so, > the > machine reboots... > > System is a Dell Precision with 2 Intel Xeons@2.2GHz and 2GB RDRAM and > hyper-threading enabled, OS is Debian/GNU Linux 3.0 with: > > gcc-2.95.4 20011002 (Debian prerelease) > ld-2.12.90.0.1 20020307 Debian/GNU Linux > > > I tried to disable HT, but then it was even worse. Then my machine > crashed > hard after starting "modprobe xfs". > > > thanks in advance > Christian > > P.S. if needed, I could post my .config, or other relevant things... > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:24:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:24:19 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIOFtG027799 for ; Wed, 11 Sep 2002 11:24:16 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA13154; Wed, 11 Sep 2002 20:28:44 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pCDZ-0003x0-00; Wed, 11 Sep 2002 20:28:01 +0200 Date: Wed, 11 Sep 2002 20:28:01 +0200 From: Christian Guggenberger To: Austin Gonyou Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911202801.C13655@pc9391.uni-regensburg.de> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1031768655.24629.23.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Mit, Sep 11, 2002 at 20:24:15 +0200 X-Mailer: Balsa 1.2.4 Lines: 9 X-archive-position: 342 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Am 11 Sep 2002 20:24:15 schrieb(en) Austin Gonyou: > Did you try just using insmod, instead of modprobe. To use modprobe, > your module must have something defined in /etc/modules.conf > > yep, I tried this before, but causes the same bad result... Christian From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:31:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:31:25 -0700 (PDT) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIVJtG028331 for ; Wed, 11 Sep 2002 11:31:19 -0700 Received: from fwd07.sul.t-online.de by mailout10.sul.t-online.com with smtp id 17pCL8-00059d-02; Wed, 11 Sep 2002 20:35:51 +0200 Received: from puariko.homeip.net (520039812576-0001@[217.231.254.84]) by fmrl07.sul.t-online.com with esmtp id 17pCKz-14tYfYC; Wed, 11 Sep 2002 20:35:41 +0200 Date: Wed, 11 Sep 2002 20:35:32 +0200 From: Axel Thimm To: linux-xfs@oss.sgi.com, Chris Wedgwood , Andy Ritger , Austin Gonyou , Knut J Bjuland , joerg@infolinux.de, Seth Mos Cc: linux-bugs@nvidia.com Subject: Re: XFS & NVIDIA Bug? Message-ID: <20020911203532.A17044@bonzo.nirvana> References: <200209081305.52636.joergprante@netcologne.de> <20020907225041.A10340@bonzo.nirvana> <3D7AEB85.9F2FBA65@online.no> <20020907225041.A10340@bonzo.nirvana> <1031452601.22717.12.camel@UberGeek.coremetrics.com> <20020907220352.GA2594@tapu.f00f.org> <20020907225041.A10340@bonzo.nirvana> <20020907220352.GA2594@tapu.f00f.org> <20020907225041.A10340@bonzo.nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020907225041.A10340@bonzo.nirvana>; from Axel.Thimm@physik.fu-berlin.de on Sat, Sep 07, 2002 at 10:50:41PM +0200 X-Sender: 520039812576-0001@t-dialin.net X-archive-position: 343 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs On Sat, Sep 07, 2002 at 10:50:41PM +0200, Axel Thimm wrote: > I am using Jörg Prante's kernel patch set 2.4.19-jp14 from > http://infolinux.de/jp/, which includes among others > > o XFS for 2.4.19 > o rmap-13b after some further tests to narrow the possible causes down, the non-working combination seem to be XFS & NVIDIA & rmap-13b Upgrading to rmap-13c fixed the kernel Oops. Credits go to Knut J Bjuland for pointing out to me a race condition in rmap-13b. Why only that particular combination triggered that bug escapes me. And it only hit applications like vmware or Samba (nmbd). Thanks to all people for a lot of helpful remarks! > o O1-Scheduler > o low-latency patches > o preempt-kernel P.S. Jörg Prante's kernel patch set with this fix applied (rmap-13c) is really impressive concerning performance. > If I try to use NVIDIA's modules (the latest available are 1.0-2960), I get a > kernel BUG at filemap.c:236 in > > Trace; c012cc26 > Trace; c012ccee > Trace; c01b2de3 > Trace; c01c95e6 > Trace; c01d6399 > Trace; c0155efd > Trace; c013bb09 > Trace; c013bddc > Trace; c014e76f > Trace; c0108a3b > (the whole Oops is attached.) > > This happens reproducably with VMware, but also with Samba (nmbd), which is > pure userland. It causes severe filesystem corruption. > > Using the XFree86 nv driver keeps the system stable (and the NVIDIA card > useless). Using 2.4.18-4SGI_XFS_1.1 (with the root access fix applied) and the > NVIDIA module also works. > > The XFS FAQ mentions that any NVIDIA driver later than 1.0-1251 would fit. Do > maybe the newest NVIDIA modules break XFS again? -- Axel.Thimm@physik.fu-berlin.de From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:36:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:36:17 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIa9tG028866 for ; Wed, 11 Sep 2002 11:36:11 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id VAA12495; Wed, 11 Sep 2002 21:12:54 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8BIfeoq006056; Wed, 11 Sep 2002 20:41:40 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8BIfG8Q031734; Wed, 11 Sep 2002 20:41:16 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8BIfB27031733; Wed, 11 Sep 2002 20:41:11 +0200 Date: Wed, 11 Sep 2002 20:41:11 +0200 From: Andrea Arcangeli To: Austin Gonyou Cc: Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911184111.GY17868@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031768655.24629.23.camel@UberGeek.coremetrics.com> User-Agent: Mutt/1.3.27i X-archive-position: 344 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs was a collision between new xfs and new scheduler, you can use this fix in the meantime: --- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 2002 +++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 @@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( spin_unlock_irq(¤t->sigmask_lock); /* Migrate to the right CPU */ - current->cpus_allowed = 1UL << cpu; - while (smp_processor_id() != cpu) - schedule(); + set_cpus_allowed(current, 1UL << cpu); + if (cpu() != cpu) + BUG(); sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); also remeber to apply the O_DIRECT fixes for reiserfs and ext3 (that were left over after merging the new nfs stuff). all will be fixed in next -aa of course. --- 2.4.19pre3aa1/fs/reiserfs/inode.c.~1~ Tue Mar 12 00:07:18 2002 +++ 2.4.19pre3aa1/fs/reiserfs/inode.c Tue Mar 12 01:24:21 2002 @@ -2161,10 +2161,11 @@ } } -static int reiserfs_direct_io(int rw, struct inode *inode, +static int reiserfs_direct_io(int rw, struct file * filp, struct kiobuf *iobuf, unsigned long blocknr, int blocksize) { + struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; return generic_direct_IO(rw, inode, iobuf, blocknr, blocksize, reiserfs_get_block_direct_io) ; } --- 2.4.20pre5aa2/fs/ext3/inode.c.~1~ Mon Sep 9 02:38:08 2002 +++ 2.4.20pre5aa2/fs/ext3/inode.c Tue Sep 10 05:22:18 2002 @@ -1385,9 +1385,10 @@ static int ext3_releasepage(struct page } static int -ext3_direct_IO(int rw, struct inode *inode, struct kiobuf *iobuf, +ext3_direct_IO(int rw, struct file * filp, struct kiobuf *iobuf, unsigned long blocknr, int blocksize) { + struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; struct ext3_inode_info *ei = EXT3_I(inode); handle_t *handle = NULL; int ret; Andrea From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:41:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:41:06 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIertG029425 for ; Wed, 11 Sep 2002 11:41:01 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17pCTn-0001rI-00; Wed, 11 Sep 2002 19:44:47 +0100 Date: Wed, 11 Sep 2002 19:44:47 +0100 From: Christoph Hellwig To: Christian Guggenberger Cc: linux-kernel@vger.kernel.org, andrea@suse.de, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911194447.A7073@infradead.org> Mail-Followup-To: Christoph Hellwig , Christian Guggenberger , linux-kernel@vger.kernel.org, andrea@suse.de, linux-xfs@oss.sgi.com References: <20020911201602.A13655@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020911201602.A13655@pc9391.uni-regensburg.de>; from christian.guggenberger@physik.uni-regensburg.de on Wed, Sep 11, 2002 at 08:16:02PM +0200 X-archive-position: 345 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Wed, Sep 11, 2002 at 08:16:02PM +0200, Christian Guggenberger wrote: > Hi! > > just tried out 2.4.20-pre5aa2 with xfs enabled as module. But I can't load > the xfs Module... > modprobe xfs just won't work. Via top on another console I see two modpobe > processes, each consuming 99.9% CPU time. Then, after a minute or so, the > machine reboots... > > System is a Dell Precision with 2 Intel Xeons@2.2GHz and 2GB RDRAM and > hyper-threading enabled, OS is Debian/GNU Linux 3.0 with: > > gcc-2.95.4 20011002 (Debian prerelease) > ld-2.12.90.0.1 20020307 Debian/GNU Linux > > > I tried to disable HT, but then it was even worse. Then my machine crashed > hard after starting "modprobe xfs". Could you please try the following patch from Andrea? --- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 2002 +++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 @@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( spin_unlock_irq(¤t->sigmask_lock); /* Migrate to the right CPU */ - current->cpus_allowed = 1UL << cpu; - while (smp_processor_id() != cpu) - schedule(); + set_cpus_allowed(current, 1UL << cpu); + if (cpu() != cpu) + BUG(); sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:41:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:41:17 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIfDtG029501 for ; Wed, 11 Sep 2002 11:41:14 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id UAA14141; Wed, 11 Sep 2002 20:45:42 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pCU0-00046E-00; Wed, 11 Sep 2002 20:45:00 +0200 Date: Wed, 11 Sep 2002 20:45:00 +0200 From: Christian Guggenberger To: Austin Gonyou Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911204500.E13655@pc9391.uni-regensburg.de> References: <20020911202801.C13655@pc9391.uni-regensburg.de> <1031769317.24629.28.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <1031769317.24629.28.camel@UberGeek.coremetrics.com>; from austin@coremetrics.com on Mit, Sep 11, 2002 at 20:35:18 +0200 X-Mailer: Balsa 1.2.4 Lines: 18 X-archive-position: 346 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Am 11 Sep 2002 20:35:18 schrieb(en) Austin Gonyou: > Ahh..I see now. So, before the machine reboots, what do you get in > dmesg? > > Anything, an oops maybe? maybe do dmesg > ~/somefile so you can keep > them around after the reboot? > > Have to correct my first statement. The Machine crashes in both cases, HT enabled or not... But I didn't find any Output in dmesg. I'll now try Andrea's patches... thank you :) Christian From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:47:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:47:31 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIlTtG030507 for ; Wed, 11 Sep 2002 11:47:29 -0700 Received: (qmail 25307 invoked by uid 500); 11 Sep 2002 18:51:35 -0000 Subject: Re: 2.4.20pre5aa2 From: Austin Gonyou To: Christian Guggenberger Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com In-Reply-To: <20020911204500.E13655@pc9391.uni-regensburg.de> References: <20020911204500.E13655@pc9391.uni-regensburg.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1031770294.24635.31.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 11 Sep 2002 13:51:35 -0500 X-archive-position: 347 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs NP. Glad he was listening! As always!! :-D On Wed, 2002-09-11 at 13:45, Christian Guggenberger wrote: > Am 11 Sep 2002 20:35:18 schrieb(en) Austin Gonyou: > > Ahh..I see now. So, before the machine reboots, what do you get in > > dmesg? > > > > Anything, an oops maybe? maybe do dmesg > ~/somefile so you can keep > > them around after the reboot? > > > > > > Have to correct my first statement. The Machine crashes in both cases, > HT > enabled or not... > But I didn't find any Output in dmesg. > > I'll now try Andrea's patches... > > thank you :) > Christian -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 11 11:58:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 11:58:40 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BIwctG031179 for ; Wed, 11 Sep 2002 11:58:38 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA68278; Wed, 11 Sep 2002 14:03:00 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA87429; Wed, 11 Sep 2002 14:03:00 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8BIwuh13580; Wed, 11 Sep 2002 13:58:56 -0500 Message-Id: <200209111858.g8BIwuh13580@stout.americas.sgi.com> Date: Wed, 11 Sep 2002 13:58:56 -0500 Subject: TAKE - add error checks to linvfs_direct_IO X-archive-position: 348 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs This one is from Mike Ovsiannikov : "Looks like that linvfs_direct_IO() doesn't always checks return status. Below is my attempt to fix that." (Mike pointed out a couple other things, still looking at that) add error checks to linvfs_direct_IO Date: Wed Sep 11 11:55:11 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127147a linux/fs/xfs/linux/xfs_aops.c - 1.4 From owner-linux-xfs@oss.sgi.com Wed Sep 11 12:07:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 12:07:21 -0700 (PDT) Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BJ7FtG031788 for ; Wed, 11 Sep 2002 12:07:16 -0700 Received: from pc9391.physik.uni-regensburg.de (mail@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id VAA15690; Wed, 11 Sep 2002 21:11:48 +0200 (MET DST) Received: from loopback ([127.0.0.1] helo=pc9391 ident=guc28561) by pc9391.physik.uni-regensburg.de with esmtp (Exim 3.35 #1 (Debian)) id 17pCtG-0004Pj-00; Wed, 11 Sep 2002 21:11:06 +0200 Date: Wed, 11 Sep 2002 21:11:06 +0200 From: Christian Guggenberger To: Andrea Arcangeli Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org, hch@infradead.org Subject: Re: 2.4.20pre5aa2 Message-ID: <20020911211106.G13655@pc9391.uni-regensburg.de> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <20020911194447.A7073@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <20020911194447.A7073@infradead.org>; from hch@infradead.org on Mit, Sep 11, 2002 at 20:44:47 +0200 X-Mailer: Balsa 1.2.4 Lines: 31 X-archive-position: 349 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Am 11 Sep 2002 20:44:47 schrieb(en) Christoph Hellwig: > Could you please try the following patch from Andrea? > > --- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 > 05:17:46 2002 > +++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 > 2002 > @@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( > spin_unlock_irq(¤t->sigmask_lock); > > /* Migrate to the right CPU */ > - current->cpus_allowed = 1UL << cpu; > - while (smp_processor_id() != cpu) > - schedule(); > + set_cpus_allowed(current, 1UL << cpu); > + if (cpu() != cpu) > + BUG(); > > sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); > INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); > > andrea, I applied your patch to page_buf.c (but not the ext3/reiserfs stuff, because there's no need for me) and now everything seems to work fine! thank you! Christian ge From owner-linux-xfs@oss.sgi.com Wed Sep 11 12:33:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 12:33:33 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BJXStG000545 for ; Wed, 11 Sep 2002 12:33:28 -0700 Received: from erbenson.alaska.net (2-pm33.nwc.alaska.net [209.112.159.2]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8BJc1Bs030830 for ; Wed, 11 Sep 2002 11:38:01 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id E03433A0C for ; Wed, 11 Sep 2002 11:37:59 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id DBFB64104E2; Wed, 11 Sep 2002 11:37:59 -0800 (AKDT) Date: Wed, 11 Sep 2002 11:37:59 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020911193759.GJ714@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mFHiwr52TKrxpkjc" Content-Disposition: inline In-Reply-To: <20020911122332.GD17696@fruit.eu.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 350 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --mFHiwr52TKrxpkjc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 11, 2002 at 02:23:32PM +0200, Wessel Dankers wrote: > On 2002-09-10 23:18:24-0800, Ethan Benson wrote: > > On Tue, Sep 10, 2002 at 02:26:14PM -0700, Chris Wedgwood wrote: > > > On Tue, Sep 10, 2002 at 03:23:39PM -0500, Eric Sandeen wrote: > > > > mode =3D 0777 & ~current->fs->umask; >=20 > > why? symlink permissions are completly irrelevant. >=20 > They are not. Consider a sticky directory. what are you talking about? they are still irrelevant. > > i think if one were to set a standard uniform permission on symlinks > > it should be 444 or 555, symlinks by thier nature are readonly, the > > only way to alter them is unlink() and re symlink() so why pretend. >=20 > That's a change that needs to be at the VFS level. For now it would just > look bad for XFS to differ in behaviour. i don't believe so since the behavior is irrelevant. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --mFHiwr52TKrxpkjc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj1/m5cACgkQJKx7GixEevzLEACggHhtq5hUEYMCFdp+tT+GgR0C j5QAn2GwxiFcj5OxN3F+jpDUC4DJueqw =oPk5 -----END PGP SIGNATURE----- --mFHiwr52TKrxpkjc-- From owner-linux-xfs@oss.sgi.com Wed Sep 11 12:54:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 12:54:43 -0700 (PDT) Received: from imf08bis.bellsouth.net (mail108.mail.bellsouth.net [205.152.58.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BJsctG001591 for ; Wed, 11 Sep 2002 12:54:39 -0700 Received: from TAZ2 ([66.156.3.51]) by imf08bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2>; Wed, 11 Sep 2002 16:00:46 -0400 Date: Wed, 11 Sep 2002 15:57:31 -0400 From: Greg Freemyer Subject: re: TAKE - add error checks to linvfs_direct_IO To: Eric Sandeen cc: xfs mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8BJsdtG001593 X-archive-position: 351 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: freemyer@NorcrossGroup.com Precedence: bulk X-list: linux-xfs >> This one is from Mike Ovsiannikov : Does that mean that Altavista.com (also av.com) is using xfs to host their search engine? I don't remember seeing that on your list of high profile users. Greg ===== Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 v4, v5 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Sep 11 13:09:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 13:09:05 -0700 (PDT) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BK92tG004851 for ; Wed, 11 Sep 2002 13:09:02 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA36424 for ; Wed, 11 Sep 2002 15:13:31 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 17pDre-0001bq-00 for ; Wed, 11 Sep 2002 15:13:30 -0500 Date: Wed, 11 Sep 2002 15:13:30 -0500 From: Nathan Straz To: xfs mailing list Subject: Re: TAKE - add error checks to linvfs_direct_IO Message-ID: <20020911201330.GC26927@sgi.com> Mail-Followup-To: xfs mailing list References: <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020911200046.MNKD1852.imf08bis.bellsouth.net@TAZ2> User-Agent: Mutt/1.4i X-archive-position: 352 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Sep 11, 2002 at 03:57:31PM -0400, Greg Freemyer wrote: > >> This one is from Mike Ovsiannikov : > > Does that mean that Altavista.com (also av.com) is using xfs to host > their search engine? No it means that Mike, who as an email address at av.com, sent in a patch that we decided to apply. That's it. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:14:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:14:30 -0700 (PDT) Received: from homer.coredp.com (homer.coredp.com [216.94.116.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLENtG006795 for ; Wed, 11 Sep 2002 14:14:23 -0700 Received: from crepe.coredp.com (pop.coredp.com [216.94.116.214]) by homer.coredp.com (8.9.1/8.9.1) with ESMTP id RAA11211 for ; Wed, 11 Sep 2002 17:33:28 -0400 (EDT) Received: from coredp.com (localhost [127.0.0.1]) by crepe.coredp.com (SGI-8.9.3/8.9.3) with ESMTP id RAA80569 for ; Wed, 11 Sep 2002 17:33:28 -0400 (EDT) Message-ID: <3D7FB6A7.91B4A592@coredp.com> Date: Wed, 11 Sep 2002 17:33:27 -0400 From: Andrew Ho Organization: C.O.R.E. Digital Pictures Inc. X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: symbolic link Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 353 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrew@coredp.com Precedence: bulk X-list: linux-xfs Hello, In my system (redhat 7.2), if I boot the computer up to 2.4.9-13SGI_XFS_1.0.2smp kernel, even the directory is symbolic linked for 5 times from one mounted drive to another mounted drive, the files are visible in this symbolic linked directory. With the kernel which are 2.4.17, 2.4.18, the error message was "Too many levels of symbolic links". Even 2.4.19 with linux/fs/xfs/linux/xfs_iops.c - 1.173 update, I receive the same error message. The i-node number of this directory is 3003418. 2.4.9-13SGI_XFS_1.0.2smp : ls -i Test # Test is a symbolic linked directory 30038418 Test ls Test check.sh libglx.txt MP3 2.4.19-xfs : ls -i Test # Test is a symbolic linked directory 30038418 Test ls Test Test: Too many levels of symbolic links -- ..................................................................... Andrew Ho email: andrew@coredp.com c.o.r.e. digital pictures http://www.coredp.com ..................................................................... From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:23:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:23:30 -0700 (PDT) Received: from muriel.parsec.at (muriel.parsec.at [80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLNPtG007276 for ; Wed, 11 Sep 2002 14:23:26 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g8BLRt501965; Wed, 11 Sep 2002 23:27:55 +0200 Date: Wed, 11 Sep 2002 23:27:55 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Leo Qiu cc: , Subject: Re: [Acl-Devel] maximum ACL entries for getfacl In-Reply-To: <20020911194121.55934.qmail@web20903.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 354 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ag@bestbits.at Precedence: bulk X-list: linux-xfs On Wed, 11 Sep 2002, Leo Qiu wrote: > Hi, > > I am running libacl on Linux XFS. I found that I could > not have more than 16 ACL entries for one file. After > a little investigation, it seems to me that I can > actually set more than 16 ACL entries on a file, but I > can not get them. I am wondering why there is such a > limit for ACL. That was an XFS bug, and has been fixed a while ago. Your workaround is correct, though. The XFS guys will likely still recommend you to upgrade to a more recent version, because of other fixes. With XFS you will currently get no more than 25 ACL entries; with ext2/ext3 the limit is set to 32. This has so far been enough for everybody; if you seem to need bigger ACLs, please verify that you can't use groups instead. Regards, Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:44:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:44:15 -0700 (PDT) Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLi9tG007868 for ; Wed, 11 Sep 2002 14:44:10 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla2.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8BLmeIs021985; Wed, 11 Sep 2002 23:48:40 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8BLmeg02219; Wed, 11 Sep 2002 23:48:40 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 11 Sep 2002 23:48:40 +0200 (CEST) From: Seth Mos To: Andrew Ho cc: linux-xfs@oss.sgi.com Subject: Re: symbolic link In-Reply-To: <3D7FB6A7.91B4A592@coredp.com> Message-ID: <20020911234620.W2111-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 355 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Wed, 11 Sep 2002, Andrew Ho wrote: > Hello, > > In my system (redhat 7.2), if I boot the computer up to > 2.4.9-13SGI_XFS_1.0.2smp kernel, even the directory is > symbolic linked for 5 times from one mounted drive to another > mounted drive, the files are visible in this symbolic linked > directory. > > With the kernel which are 2.4.17, 2.4.18, the error message > was "Too many levels of symbolic links". Even 2.4.19 with > linux/fs/xfs/linux/xfs_iops.c - 1.173 update, I receive the > same error message. AFAIK that behaviour was "fixed" in the mainline kernel and thus XFS automatically follows that behaviour. They originally created this to make sure you can not loop through symlinks endlessly. I think that searching for patches about this on lkml might show you how to change this limit. I do not know the current limit for recursive symlinks. Cheers Seth From owner-linux-xfs@oss.sgi.com Wed Sep 11 14:48:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Sep 2002 14:48:54 -0700 (PDT) Received: from maynard.mail.mindspring.net (maynard.mail.mindspring.net [207.69.200.243]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8BLmntG008507 for ; Wed, 11 Sep 2002 14:48:49 -0700 Received: from user-11fa2a4.dsl.mindspring.com ([66.245.9.68] helo=[192.168.2.24]) by maynard.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17pFQE-0001wh-00; Wed, 11 Sep 2002 17:53:18 -0400 Subject: Re: [Acl-Devel] maximum ACL entries for getfacl From: John M Trostel To: Andreas Gruenbacher Cc: Leo Qiu , Acl-List , linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 11 Sep 2002 17:52:08 -0400 Message-Id: <1031781129.2163.6.camel@jtsdell> Mime-Version: 1.0 X-archive-position: 356 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: john.trostel@quantum.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-11 at 17:27, Andreas Gruenbacher wrote: > On Wed, 11 Sep 2002, Leo Qiu wrote: > > > Hi, > > > > I am running libacl on Linux XFS. I found that I could > > not have more than 16 ACL entries for one file. After > > a little investigation, it seems to me that I can > > actually set more than 16 ACL entries on a file, but I > > can not get them. I am wondering why there is such a > > limit for ACL. > > That was an XFS bug, and has been fixed a while ago. Your workaround is > correct, though. The XFS guys will likely still recommend you to upgrade > to a more recent version, because of other fixes. > > With XFS you will currently get no more than 25 ACL entries; with > ext2/ext3 the limit is set to 32. This has so far been enough for > everybody; if you seem to need bigger ACLs, please verify that you can't > use groups instead. > > > Regards, > Andreas. With the newer treatment of ACLs in XFS, the number can be increased beyond 25. I have a working setup using a 128 ACE limit. Let me know if you need that patch. (Although as Andreas says, people really ought to use groups instead at that point.) -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Thu Sep 12 02:21:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 02:21:56 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8C9LotG027933 for ; Thu, 12 Sep 2002 02:21:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA90563 for ; Thu, 12 Sep 2002 04:26:21 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA20550 for ; Thu, 12 Sep 2002 04:26:20 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CGfSq01525 for linux-xfs@oss.sgi.com; Thu, 12 Sep 2002 12:41:28 -0400 Resent-Message-Id: <200209121641.g8CGfSq01525@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA86126 for ; Thu, 12 Sep 2002 04:25:50 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CGews01515 for hch@sgi.com; Thu, 12 Sep 2002 12:40:58 -0400 Date: Thu, 12 Sep 2002 12:40:58 -0400 From: Christoph Hellwig Message-Id: <200209121640.g8CGews01515@dhcp212.munich.sgi.com> Subject: TAKE - Make generic_file_write changes more similar to 2.5 Resent-Date: Thu, 12 Sep 2002 12:41:28 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 357 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 12 02:24:18 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127219a linux/mm/filemap.c - 1.114 linux/kernel/ksyms.c - 1.136 linux/include/linux/fs.h - 1.158 - Backport the 2.5 version of generic_file_write_nolock and drop the XFS-specific do_generic_file_write. linux/fs/xfs/linux/xfs_lrw.c - 1.167 - Use generic_file_write_nolock instead of do_generic_file_write From owner-linux-xfs@oss.sgi.com Thu Sep 12 02:53:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 02:53:19 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8C9rFtG028600 for ; Thu, 12 Sep 2002 02:53:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA89019 for ; Thu, 12 Sep 2002 04:57:46 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA56237 for ; Thu, 12 Sep 2002 04:57:45 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CHCrw02817 for linux-xfs@oss.sgi.com; Thu, 12 Sep 2002 13:12:53 -0400 Resent-Message-Id: <200209121712.g8CHCrw02817@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA76212 for ; Thu, 12 Sep 2002 04:57:10 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8CHCHk02807 for hch@sgi.com; Thu, 12 Sep 2002 13:12:17 -0400 Date: Thu, 12 Sep 2002 13:12:17 -0400 From: Christoph Hellwig Message-Id: <200209121712.g8CHCHk02807@dhcp212.munich.sgi.com> Subject: TAKE - Fix migration of pagebuf I/O completion threads with the O(1) scheduler Resent-Date: Thu, 12 Sep 2002 13:12:53 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 358 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Fix from Andrea Arcangeli to not lockup the machine when XFS is combined with the O(1) scheduler patch. I had to add some ugly #ifdef magic to detect that case. Date: Thu Sep 12 02:54:15 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127220a linux/fs/xfs/pagebuf/page_buf.c - 1.58 - Fix migration of pagebuf I/O completion threads with the O(1) scheduler From owner-linux-xfs@oss.sgi.com Thu Sep 12 08:22:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 08:22:45 -0700 (PDT) Received: from muriel.parsec.at (muriel.parsec.at [80.120.166.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CFMbtG006784 for ; Thu, 12 Sep 2002 08:22:39 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g8CFQwt22014; Thu, 12 Sep 2002 17:26:59 +0200 Date: Thu, 12 Sep 2002 17:26:58 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: John M Trostel cc: Acl-List , Subject: Re: [Acl-Devel] maximum ACL entries for getfacl In-Reply-To: <1031781129.2163.6.camel@jtsdell> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 359 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ag@bestbits.at Precedence: bulk X-list: linux-xfs Hi, On 11 Sep 2002, John M Trostel wrote: > On Wed, 2002-09-11 at 17:27, Andreas Gruenbacher wrote: > > With XFS you will currently get no more than 25 ACL entries; with > > ext2/ext3 the limit is set to 32. This has so far been enough for > > everybody; if you seem to need bigger ACLs, please verify that you can't > > use groups instead. > > > > Regards, > > Andreas. > > With the newer treatment of ACLs in XFS, the number can be increased > beyond 25. I have a working setup using a 128 ACE limit. Let me know > if you need that patch. (Although as Andreas says, people really ought > to use groups instead at that point.) Did you also make sure this doesn't break Irix XFS filesystems? --Andreas. From owner-linux-xfs@oss.sgi.com Thu Sep 12 10:20:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 10:20:30 -0700 (PDT) Received: from homer.coredp.com (homer.coredp.com [216.94.116.130]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CHKRtG009964 for ; Thu, 12 Sep 2002 10:20:28 -0700 Received: from crepe.coredp.com (pop.coredp.com [216.94.116.214]) by homer.coredp.com (8.9.1/8.9.1) with ESMTP id NAA11697; Thu, 12 Sep 2002 13:39:54 -0400 (EDT) Received: from coredp.com (localhost [127.0.0.1]) by crepe.coredp.com (SGI-8.9.3/8.9.3) with ESMTP id NAA00376; Thu, 12 Sep 2002 13:39:54 -0400 (EDT) Message-ID: <3D80D16A.E3D8E63C@coredp.com> Date: Thu, 12 Sep 2002 13:39:54 -0400 From: Andrew Ho Organization: C.O.R.E. Digital Pictures Inc. X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: symbolic link References: <20020911234620.W2111-100000@xs1.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 360 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrew@coredp.com Precedence: bulk X-list: linux-xfs Seth Mos wrote: > > On Wed, 11 Sep 2002, Andrew Ho wrote: > > > Hello, > > > > In my system (redhat 7.2), if I boot the computer up to > > 2.4.9-13SGI_XFS_1.0.2smp kernel, even the directory is > > symbolic linked for 5 times from one mounted drive to another > > mounted drive, the files are visible in this symbolic linked > > directory. > > > > With the kernel which are 2.4.17, 2.4.18, the error message > > was "Too many levels of symbolic links". Even 2.4.19 with > > linux/fs/xfs/linux/xfs_iops.c - 1.173 update, I receive the > > same error message. > > AFAIK that behaviour was "fixed" in the mainline kernel and thus XFS > automatically follows that behaviour. They originally created this to make > sure you can not loop through symlinks endlessly. > > I think that searching for patches about this on lkml might show you how > to change this limit. I do not know the current limit for recursive > symlinks. > It is not the problem of the limit. I use the same machine with different kernel as I mentioned. I believe that it is the problem of the kernel codes. Will it be the VFS, hard link problems, etc ... Thanks, -- ..................................................................... Andrew Ho email: andrew@coredp.com c.o.r.e. digital pictures http://www.coredp.com ..................................................................... From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:08:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:09:02 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CN8utG022354 for ; Thu, 12 Sep 2002 16:08:56 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA08021 for ; Thu, 12 Sep 2002 16:13:31 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA12509; Fri, 13 Sep 2002 09:12:13 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA33148; Fri, 13 Sep 2002 09:12:12 +1000 (AEDT) Date: Fri, 13 Sep 2002 09:12:11 +1000 From: Nathan Scott To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020913091211.B133147@wobbly.melbourne.sgi.com> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1031753707.9726.1.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Sep 11, 2002 at 09:15:06AM -0500 X-archive-position: 361 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Wed, Sep 11, 2002 at 09:15:06AM -0500, Eric Sandeen wrote: > Ok, it sounds like there's enough going on here that I'll revert the mod > for now, until I'm sure there are no other implications. > > (Nathan had some concerns about acls as well...) Extended attributes, not ACLs. We may want to switch this behavior via a mount flag or something, to give either the IRIX or the Linux semantics (like we did for SGID) - we'll talk. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:23:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:23:11 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CNN1tG023500 for ; Thu, 12 Sep 2002 16:23:02 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8CNRYW25000; Thu, 12 Sep 2002 19:27:34 -0400 Message-ID: <3D81235B.6080809@rackable.com> Date: Thu, 12 Sep 2002 16:29:31 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Austin Gonyou , Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> Content-Type: multipart/mixed; boundary="------------030500010508020204010905" X-archive-position: 362 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------030500010508020204010905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Your patch seem to solve only some of the xfs issues for me. Before the patch my system hung when booting. This only occured I had xfs compiled into the kernel. After patching things seemed fine, but durning "dbench 32" the system locked. Upon rebooting and attempting to mount the filesystem I got this: XFS mounting filesystem md(9,2) Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) kernel BUG at page_buf.c:578! PS- The results of ksymoops are attached. Andrea Arcangeli wrote: >was a collision between new xfs and new scheduler, you can use this fix >in the meantime: > >--- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 2002 >+++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 >@@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( > spin_unlock_irq(¤t->sigmask_lock); > > /* Migrate to the right CPU */ >- current->cpus_allowed = 1UL << cpu; >- while (smp_processor_id() != cpu) >- schedule(); >+ set_cpus_allowed(current, 1UL << cpu); >+ if (cpu() != cpu) >+ BUG(); > > sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); > INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); > >also remeber to apply the O_DIRECT fixes for reiserfs and ext3 (that >were left over after merging the new nfs stuff). all will be fixed in >next -aa of course. > >--- 2.4.19pre3aa1/fs/reiserfs/inode.c.~1~ Tue Mar 12 00:07:18 2002 >+++ 2.4.19pre3aa1/fs/reiserfs/inode.c Tue Mar 12 01:24:21 2002 >@@ -2161,10 +2161,11 @@ > } > } > >-static int reiserfs_direct_io(int rw, struct inode *inode, >+static int reiserfs_direct_io(int rw, struct file * filp, > struct kiobuf *iobuf, unsigned long blocknr, > int blocksize) > { >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > return generic_direct_IO(rw, inode, iobuf, blocknr, blocksize, > reiserfs_get_block_direct_io) ; > } >--- 2.4.20pre5aa2/fs/ext3/inode.c.~1~ Mon Sep 9 02:38:08 2002 >+++ 2.4.20pre5aa2/fs/ext3/inode.c Tue Sep 10 05:22:18 2002 >@@ -1385,9 +1385,10 @@ static int ext3_releasepage(struct page > } > > static int >-ext3_direct_IO(int rw, struct inode *inode, struct kiobuf *iobuf, >+ext3_direct_IO(int rw, struct file * filp, struct kiobuf *iobuf, > unsigned long blocknr, int blocksize) > { >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > struct ext3_inode_info *ei = EXT3_I(inode); > handle_t *handle = NULL; > int ret; > >Andrea >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to majordomo@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ > > > > --------------030500010508020204010905 Content-Type: text/plain; name="xfs.opps" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs.opps" ksymoops 2.4.5 on i686 2.4.20-pre5aa2-fixed-xfs. Options used -V (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.20-pre5aa2-fixed-xfs/ (default) -m /boot/System.map-2.4.20-pre5aa2-fixed-xfs (default) kernel BUG at page_buf.c:578! invalid operand: 0000 2.4.20-pre5aa2-fixed-xfs #4 SMP Thu Sep 12 11:51:40 PDT 2002 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000001 ecx: 00000001 edx: 00000000 esi: c5e15a04 edi: c5e15980 ebp: 00000002 esp: c5c19a58 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 805, stackpage=c5c19000) Stack: c5c18000 00001000 00000000 00000001 00000000 00000005 000001f0 00000002 c5e15980 c5e15980 00002205 c5e20540 c02089c8 c5e15980 c5c117b4 00002205 13005f90 00000000 c5912d40 13005f90 00000000 c01f4d2d c5912d40 13005f90 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 42 02 95 ab 35 c0 0f b7 47 7c 81 4f 08 04 00 00 01 8d >>EIP; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== >>esi; c5e15a04 >>edi; c5e15980 >>esp; c5c19a58 <[ip_tables].data.end+116159/294761> Trace; c02089c8 Trace; c01f4d2d Trace; c01f45e1 Trace; c01f463a Trace; c01f58b2 Trace; c01f59f6 Trace; c01f5b5a Trace; c01f6744 Trace; c01f6c74 Trace; c01f6cc4 Trace; c01f6e45 Trace; c01efde7 Trace; c01f861c Trace; c01f776b Trace; c01f77b0 Trace; c01ff894 Trace; c01ff97b Trace; c0212ce6 Trace; c0148c81 Trace; c0148e9c Trace; c014dfb8 Trace; c015c145 Trace; c015c43b Trace; c015c29c Trace; c015c904 Trace; c0108d9b Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> 00000000 <_EIP>: Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== 0: 0f 0b ud2a <===== Code; c0208594 <_pagebuf_lookup_pages+2a4/2f0> 2: 42 inc %edx Code; c0208595 <_pagebuf_lookup_pages+2a5/2f0> 3: 02 95 ab 35 c0 0f add 0xfc035ab(%ebp),%dl Code; c020859b <_pagebuf_lookup_pages+2ab/2f0> 9: b7 47 mov $0x47,%bh Code; c020859d <_pagebuf_lookup_pages+2ad/2f0> b: 7c 81 jl ffffff8e <_EIP+0xffffff8e> Code; c020859f <_pagebuf_lookup_pages+2af/2f0> d: 4f dec %edi Code; c02085a0 <_pagebuf_lookup_pages+2b0/2f0> e: 08 04 00 or %al,(%eax,%eax,1) Code; c02085a3 <_pagebuf_lookup_pages+2b3/2f0> 11: 00 01 add %al,(%ecx) Code; c02085a5 <_pagebuf_lookup_pages+2b5/2f0> 13: 8d 00 lea (%eax),%eax --------------030500010508020204010905-- From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:41:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:41:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CNf1tG024427 for ; Thu, 12 Sep 2002 16:41:01 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA01069; Thu, 12 Sep 2002 18:45:31 -0500 (CDT) Received: from [192.168.1.101] (IDENT:1r2AFiycYRCll7S+TpGuaoKQJScZVz+P@cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id SAA24402; Thu, 12 Sep 2002 18:45:30 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Samuel Flory Cc: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com In-Reply-To: <3D81235B.6080809@rackable.com> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 12 Sep 2002 18:45:28 -0500 Message-Id: <1031874330.1236.3.camel@snafu> Mime-Version: 1.0 X-archive-position: 363 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-12 at 18:29, Samuel Flory wrote: > Your patch seem to solve only some of the xfs issues for me. Before > the patch my system hung when booting. This only occured I had xfs > compiled into the kernel. After patching things seemed fine, but > durning "dbench 32" the system locked. Upon rebooting and attempting to > mount the filesystem I got this: > XFS mounting filesystem md(9,2) > Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) > kernel BUG at page_buf.c:578! > > Line numbers in no way line up with the code I have in front of me, However, this appears to equate to a failure in the address space remapping code. This is not a failure I have ever seen in our code base. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 12 16:59:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 16:59:39 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8CNxZtG025408 for ; Thu, 12 Sep 2002 16:59:35 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D046W26677; Thu, 12 Sep 2002 20:04:06 -0400 Message-ID: <3D812BEB.3040903@rackable.com> Date: Thu, 12 Sep 2002 17:06:03 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <1031874330.1236.3.camel@snafu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 364 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Line 578 is BUG(); below: mapit: pb->pb_flags |= _PBF_MEM_ALLOCATED; if (all_mapped) { pb->pb_flags |= _PBF_ALL_PAGES_MAPPED; /* A single page buffer is always mappable */ if (page_count == 1) { pb->pb_addr = (caddr_t) page_address(pb->pb_pages[0]) + pb->pb_offset; pb->pb_flags |= PBF_MAPPED; } else if (flags & PBF_MAPPED) { if (as_list_len > 64) purge_addresses(); pb->pb_addr = vmap(pb->pb_pages, page_count); if (!pb->pb_addr) BUG(); pb->pb_addr += pb->pb_offset; pb->pb_flags |= PBF_MAPPED | _PBF_ADDR_ALLOCATED; } } /* If some pages were found with data in them * we are not in PBF_NONE state. */ if (good_pages != 0) { pb->pb_flags &= ~(PBF_NONE); if (good_pages != page_count) { pb->pb_flags |= PBF_PARTIAL; } } PB_TRACE(pb, PB_TRACE_REC(look_pg), good_pages); return rval; } Stephen Lord wrote: >On Thu, 2002-09-12 at 18:29, Samuel Flory wrote: > > >> Your patch seem to solve only some of the xfs issues for me. Before >>the patch my system hung when booting. This only occured I had xfs >>compiled into the kernel. After patching things seemed fine, but >>durning "dbench 32" the system locked. Upon rebooting and attempting to >>mount the filesystem I got this: >>XFS mounting filesystem md(9,2) >>Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) >>kernel BUG at page_buf.c:578! >> >> >> >> > >Line numbers in no way line up with the code I have in front of me, >However, this appears to equate to a failure in the address space >remapping code. This is not a failure I have ever seen in our code >base. > >Steve > > > > From owner-linux-xfs@oss.sgi.com Thu Sep 12 17:18:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 17:18:17 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D0I9tG026048 for ; Thu, 12 Sep 2002 17:18:10 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id CAA13424; Fri, 13 Sep 2002 02:55:04 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8D0Nhoq024281; Fri, 13 Sep 2002 02:23:43 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8D0NI8Q021453; Fri, 13 Sep 2002 02:23:18 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8D0NGr5021452; Fri, 13 Sep 2002 02:23:16 +0200 Date: Fri, 13 Sep 2002 02:23:16 +0200 From: Andrea Arcangeli To: Samuel Flory Cc: Austin Gonyou , Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913002316.GG11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D81235B.6080809@rackable.com> User-Agent: Mutt/1.3.27i X-archive-position: 365 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 12, 2002 at 04:29:31PM -0700, Samuel Flory wrote: > Your patch seem to solve only some of the xfs issues for me. Before > the patch my system hung when booting. This only occured I had xfs > compiled into the kernel. After patching things seemed fine, but > durning "dbench 32" the system locked. Upon rebooting and attempting to > mount the filesystem I got this: > XFS mounting filesystem md(9,2) > Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) > kernel BUG at page_buf.c:578! > > > PS- The results of ksymoops are attached. that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it must return -ENOMEM to userspace instead, or it can try to recollect and release some of the other vmalloced entries. Most probably you run into an address space shortage, not a real ram shortage, so to workaround it you can recompile with CONFIG_2G and it'll probably work, also dropping the gap page in vmalloc may help workaround it (there's no config option for it though). It could be also a vmap leak, maybe a missing vfree, just some idea. > > Andrea Arcangeli wrote: > > >was a collision between new xfs and new scheduler, you can use this fix > >in the meantime: > > > >--- 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c.~1~ Wed Sep 11 05:17:46 > >2002 > >+++ 2.4.20pre5aa3/fs/xfs/pagebuf/page_buf.c Wed Sep 11 06:00:35 2002 > >@@ -2055,9 +2055,9 @@ pagebuf_iodone_daemon( > > spin_unlock_irq(¤t->sigmask_lock); > > > > /* Migrate to the right CPU */ > >- current->cpus_allowed = 1UL << cpu; > >- while (smp_processor_id() != cpu) > >- schedule(); > >+ set_cpus_allowed(current, 1UL << cpu); > >+ if (cpu() != cpu) > >+ BUG(); > > > > sprintf(current->comm, "pagebuf_io_CPU%d", bind_cpu); > > INIT_LIST_HEAD(&pagebuf_iodone_tq[cpu]); > > > >also remeber to apply the O_DIRECT fixes for reiserfs and ext3 (that > >were left over after merging the new nfs stuff). all will be fixed in > >next -aa of course. > > > >--- 2.4.19pre3aa1/fs/reiserfs/inode.c.~1~ Tue Mar 12 00:07:18 2002 > >+++ 2.4.19pre3aa1/fs/reiserfs/inode.c Tue Mar 12 01:24:21 2002 > >@@ -2161,10 +2161,11 @@ > > } > >} > > > >-static int reiserfs_direct_io(int rw, struct inode *inode, > >+static int reiserfs_direct_io(int rw, struct file * filp, > > struct kiobuf *iobuf, unsigned long blocknr, > > int blocksize) > >{ > >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > > return generic_direct_IO(rw, inode, iobuf, blocknr, blocksize, > > reiserfs_get_block_direct_io) ; > >} > >--- 2.4.20pre5aa2/fs/ext3/inode.c.~1~ Mon Sep 9 02:38:08 2002 > >+++ 2.4.20pre5aa2/fs/ext3/inode.c Tue Sep 10 05:22:18 2002 > >@@ -1385,9 +1385,10 @@ static int ext3_releasepage(struct page > >} > > > >static int > >-ext3_direct_IO(int rw, struct inode *inode, struct kiobuf *iobuf, > >+ext3_direct_IO(int rw, struct file * filp, struct kiobuf *iobuf, > > unsigned long blocknr, int blocksize) > >{ > >+ struct inode * inode = filp->f_dentry->d_inode->i_mapping->host; > > struct ext3_inode_info *ei = EXT3_I(inode); > > handle_t *handle = NULL; > > int ret; > > > >Andrea > >- > >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > >the body of a message to majordomo@vger.kernel.org > >More majordomo info at http://vger.kernel.org/majordomo-info.html > >Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > > > > ksymoops 2.4.5 on i686 2.4.20-pre5aa2-fixed-xfs. Options used > -V (specified) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.20-pre5aa2-fixed-xfs/ (default) > -m /boot/System.map-2.4.20-pre5aa2-fixed-xfs (default) > > kernel BUG at page_buf.c:578! > invalid operand: 0000 2.4.20-pre5aa2-fixed-xfs #4 SMP Thu Sep 12 11:51:40 PDT 2002 > CPU: 1 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010246 > eax: 00000000 ebx: 00000001 ecx: 00000001 edx: 00000000 > esi: c5e15a04 edi: c5e15980 ebp: 00000002 esp: c5c19a58 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 805, stackpage=c5c19000) > Stack: c5c18000 00001000 00000000 00000001 00000000 00000005 000001f0 00000002 > c5e15980 c5e15980 00002205 c5e20540 c02089c8 c5e15980 c5c117b4 00002205 > 13005f90 00000000 c5912d40 13005f90 00000000 c01f4d2d c5912d40 13005f90 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] > Code: 0f 0b 42 02 95 ab 35 c0 0f b7 47 7c 81 4f 08 04 00 00 01 8d > > > >>EIP; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== > > >>esi; c5e15a04 > >>edi; c5e15980 > >>esp; c5c19a58 <[ip_tables].data.end+116159/294761> > > Trace; c02089c8 > Trace; c01f4d2d > Trace; c01f45e1 > Trace; c01f463a > Trace; c01f58b2 > Trace; c01f59f6 > Trace; c01f5b5a > Trace; c01f6744 > Trace; c01f6c74 > Trace; c01f6cc4 > Trace; c01f6e45 > Trace; c01efde7 > Trace; c01f861c > Trace; c01f776b > Trace; c01f77b0 > Trace; c01ff894 > Trace; c01ff97b > Trace; c0212ce6 > Trace; c0148c81 > Trace; c0148e9c > Trace; c014dfb8 > Trace; c015c145 > Trace; c015c43b > Trace; c015c29c > Trace; c015c904 > Trace; c0108d9b > > Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> > 00000000 <_EIP>: > Code; c0208592 <_pagebuf_lookup_pages+2a2/2f0> <===== > 0: 0f 0b ud2a <===== > Code; c0208594 <_pagebuf_lookup_pages+2a4/2f0> > 2: 42 inc %edx > Code; c0208595 <_pagebuf_lookup_pages+2a5/2f0> > 3: 02 95 ab 35 c0 0f add 0xfc035ab(%ebp),%dl > Code; c020859b <_pagebuf_lookup_pages+2ab/2f0> > 9: b7 47 mov $0x47,%bh > Code; c020859d <_pagebuf_lookup_pages+2ad/2f0> > b: 7c 81 jl ffffff8e <_EIP+0xffffff8e> > Code; c020859f <_pagebuf_lookup_pages+2af/2f0> > d: 4f dec %edi > Code; c02085a0 <_pagebuf_lookup_pages+2b0/2f0> > e: 08 04 00 or %al,(%eax,%eax,1) > Code; c02085a3 <_pagebuf_lookup_pages+2b3/2f0> > 11: 00 01 add %al,(%ecx) > Code; c02085a5 <_pagebuf_lookup_pages+2b5/2f0> > 13: 8d 00 lea (%eax),%eax > Andrea From owner-linux-xfs@oss.sgi.com Thu Sep 12 17:43:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 17:43:24 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D0hItG026676 for ; Thu, 12 Sep 2002 17:43:18 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA02449; Thu, 12 Sep 2002 19:47:52 -0500 (CDT) Received: from [192.168.1.101] (IDENT:vbS4jLV5dwrL4SsD07YZ/BkWBnnHf/oy@cf-vpn-sw-corp-64-62.corp.sgi.com [134.15.64.62]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id TAA50065; Thu, 12 Sep 2002 19:47:50 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Andrea Arcangeli Cc: Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com In-Reply-To: <20020913002316.GG11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 12 Sep 2002 19:47:48 -0500 Message-Id: <1031878070.1236.29.camel@snafu> Mime-Version: 1.0 X-archive-position: 366 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-12 at 19:23, Andrea Arcangeli wrote: > > that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it > must return -ENOMEM to userspace instead, or it can try to recollect and > release some of the other vmalloced entries. Most probably you run into > an address space shortage, not a real ram shortage, so to workaround it > you can recompile with CONFIG_2G and it'll probably work, also dropping > the gap page in vmalloc may help workaround it (there's no config option > for it though). It could be also a vmap leak, maybe a missing vfree, > just some idea. > We hold vmalloced space for very short periods of time, in fact filesystem recovery and large extended attributes are the only cases. In this case we should be attempting to remap 2 pages together. The only way out of this would be to fail the whole mount at this point. I suspect a leak elsewhere. Samuel, when you mounted xfs and it oopsed, was it shortly after bootup? Also, how far did your dbench run get before it hung? I tried the kernel, but I paniced during startup - then I realized I did not apply the patch to fix the xfs/scheduler interactions first. How much memory is in the machine by the way? And Andrea, is the vmalloc space size reduced in the 3G user space configuration? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 12 17:49:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 17:49:35 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D0nWtG027161 for ; Thu, 12 Sep 2002 17:49:32 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id DAA13793; Fri, 13 Sep 2002 03:26:29 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8D0t5oq024336; Fri, 13 Sep 2002 02:55:05 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8D0se8Q022919; Fri, 13 Sep 2002 02:54:40 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8D0seG8022918; Fri, 13 Sep 2002 02:54:40 +0200 Date: Fri, 13 Sep 2002 02:54:40 +0200 From: Andrea Arcangeli To: Stephen Lord Cc: Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913005440.GJ11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031878070.1236.29.camel@snafu> User-Agent: Mutt/1.3.27i X-archive-position: 367 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: > How much memory is in the machine by the way? And Andrea, is the > vmalloc space size reduced in the 3G user space configuration? it's not reduced, it's the usual 128m. BTW, I forgot to say that to really take advantage of CONFIG_2G one should increase __VMALLOC_RESERVE too, it's not directly in function of the CONFIG_2G. Andrea From owner-linux-xfs@oss.sgi.com Thu Sep 12 18:12:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 18:12:25 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D1CItG032362 for ; Thu, 12 Sep 2002 18:12:19 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D1GrW30034; Thu, 12 Sep 2002 21:16:53 -0400 Message-ID: <3D813CFB.7050200@rackable.com> Date: Thu, 12 Sep 2002 18:18:51 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Austin Gonyou , Christian Guggenberger , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 368 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Andrea Arcangeli wrote: >On Thu, Sep 12, 2002 at 04:29:31PM -0700, Samuel Flory wrote: > > >> Your patch seem to solve only some of the xfs issues for me. Before >>the patch my system hung when booting. This only occured I had xfs >>compiled into the kernel. After patching things seemed fine, but >>durning "dbench 32" the system locked. Upon rebooting and attempting to >>mount the filesystem I got this: >>XFS mounting filesystem md(9,2) >>Starting XFS recovery on filesystem: md(9,2) (dev: 9/2) >>kernel BUG at page_buf.c:578! >> >> >>PS- The results of ksymoops are attached. >> >> > >that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it >must return -ENOMEM to userspace instead, or it can try to recollect and >release some of the other vmalloced entries. Most probably you run into >an address space shortage, not a real ram shortage, so to workaround it >you can recompile with CONFIG_2G and it'll probably work, also dropping >the gap page in vmalloc may help workaround it (there's no config option >for it though). It could be also a vmap leak, maybe a missing vfree, >just some idea. > > > The system has 4G of ram, and 4G of swap. So real memory is not an issue. The system is a intended to be an nfs server. As a result nfs performance is my only real concern. I should really use CONFIG_3GB as I'm not doing much in user space other a tftp, and dhcp server. In any case the system isn't in production so I can leave it as is till monday. From owner-linux-xfs@oss.sgi.com Thu Sep 12 18:20:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 18:20:35 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D1KWtG008271 for ; Thu, 12 Sep 2002 18:20:32 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D1P6W30381; Thu, 12 Sep 2002 21:25:06 -0400 Message-ID: <3D813EE8.6090700@rackable.com> Date: Thu, 12 Sep 2002 18:27:04 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 369 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Stephen Lord wrote: >On Thu, 2002-09-12 at 19:23, Andrea Arcangeli wrote: > > >>that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it >>must return -ENOMEM to userspace instead, or it can try to recollect and >>release some of the other vmalloced entries. Most probably you run into >>an address space shortage, not a real ram shortage, so to workaround it >>you can recompile with CONFIG_2G and it'll probably work, also dropping >>the gap page in vmalloc may help workaround it (there's no config option >>for it though). It could be also a vmap leak, maybe a missing vfree, >>just some idea. >> >> >> > >We hold vmalloced space for very short periods of time, in fact >filesystem recovery and large extended attributes are the only >cases. In this case we should be attempting to remap 2 pages >together. The only way out of this would be to fail the whole >mount at this point. I suspect a leak elsewhere. > >Samuel, when you mounted xfs and it oopsed, was it shortly after bootup? > Yes I'd just logged in and manually mounted it. >Also, how far did your dbench run get before it hung? I tried the >kernel, but I paniced during startup - then I realized I did not >apply the patch to fix the xfs/scheduler interactions first. > > It looked around 1/4 to 1/2 done with dbench 32. I'm not sure if it was the 1st or second run. I run dbench from a script: sync sync ./dbench 2 sync sync ./dbench 4 sync sync ./dbench 8 sync sync ./dbench 16 sync sync ./dbench 32 sync sync ./dbench 64 sync sync I generally use this script narrow down which configurations seem to be most promising. >How much memory is in the machine by the way? > 4G ram, and 4G swap. From owner-linux-xfs@oss.sgi.com Thu Sep 12 19:07:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 19:07:51 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D27ktG024642 for ; Thu, 12 Sep 2002 19:07:46 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D2CGW32418; Thu, 12 Sep 2002 22:12:16 -0400 Message-ID: <3D8149F6.9060702@rackable.com> Date: Thu, 12 Sep 2002 19:14:14 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) Andrea Arcangeli wrote: >On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: > > >>How much memory is in the machine by the way? And Andrea, is the >>vmalloc space size reduced in the 3G user space configuration? >> >> > >it's not reduced, it's the usual 128m. > >BTW, I forgot to say that to really take advantage of CONFIG_2G one >should increase __VMALLOC_RESERVE too, it's not directly in function of >the CONFIG_2G. > So how much do you recommend increasing it? Currently it's: include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) From owner-linux-xfs@oss.sgi.com Thu Sep 12 19:07:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Sep 2002 19:07:51 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D27htG024631 for ; Thu, 12 Sep 2002 19:07:44 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8D2CBW32414; Thu, 12 Sep 2002 22:12:11 -0400 Message-ID: <3D8149F1.4010008@rackable.com> Date: Thu, 12 Sep 2002 19:14:09 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <3D813EE8.6090700@rackable.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 370 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Stephen is there any reason to leave the system in it's current state? (IE You guys want the output of some tool.) Or shall I give it a go at a kernel with CONFIG_3GB, and maybe play with vmalloc settings? Samuel Flory wrote: > Stephen Lord wrote: > >> On Thu, 2002-09-12 at 19:23, Andrea Arcangeli wrote: >> >> >>> that seems a bug in xfs, it BUG() if vmap fails, it must not BUG(), it >>> must return -ENOMEM to userspace instead, or it can try to recollect >>> and >>> release some of the other vmalloced entries. Most probably you run into >>> an address space shortage, not a real ram shortage, so to workaround it >>> you can recompile with CONFIG_2G and it'll probably work, also dropping >>> the gap page in vmalloc may help workaround it (there's no config >>> option >>> for it though). It could be also a vmap leak, maybe a missing vfree, >>> just some idea. >>> >>> >> >> >> We hold vmalloced space for very short periods of time, in fact >> filesystem recovery and large extended attributes are the only >> cases. In this case we should be attempting to remap 2 pages >> together. The only way out of this would be to fail the whole >> mount at this point. I suspect a leak elsewhere. >> >> Samuel, when you mounted xfs and it oopsed, was it shortly after bootup? >> > > Yes I'd just logged in and manually mounted it. > >> Also, how far did your dbench run get before it hung? I tried the >> kernel, but I paniced during startup - then I realized I did not >> apply the patch to fix the xfs/scheduler interactions first. >> >> > It looked around 1/4 to 1/2 done with dbench 32. I'm not sure if it > was the 1st or second run. I run dbench from a script: > sync > sync > ./dbench 2 > sync > sync > ./dbench 4 > sync > sync > ./dbench 8 > sync > sync > ./dbench 16 > sync > sync > ./dbench 32 > sync > sync > ./dbench 64 > sync > sync > > > I generally use this script narrow down which configurations seem to > be most promising. > >> How much memory is in the machine by the way? > > 4G ram, and 4G swap. > > > > From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:10:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:10:41 -0700 (PDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8AZtG002973 for ; Fri, 13 Sep 2002 01:10:36 -0700 Received: from attbi.com ([24.60.116.36]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020913060250.CYEU16614.sccrmhc03.attbi.com@attbi.com> for ; Fri, 13 Sep 2002 06:02:50 +0000 Message-ID: <3D817F8A.6020205@attbi.com> Date: Fri, 13 Sep 2002 02:02:50 -0400 From: Clem Taylor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020908 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: ls segfaults, kernel does NULL pointer dereference... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 371 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: clemtaylor@attbi.com Precedence: bulk X-list: linux-xfs I came home to find my 1.1TB disk array in a sick state, a drive is failing... When I do an ls on the volume, ls segfaults and the log shows that the kernel tried to dereference a NULL pointer. I'm running 2.4.19-rc1-xfs on a dual Athlon with a 3ware 7xxx controller and 6 160G Maxtor drives. I repaired the drive (and ordered a new one) and after reboot everything seems to be okay. It does seem a little strange that XFS would fail this way.... Here's what ksymoops says... Any ideas? --Clem <1>Unable to handle kernel NULL pointer dereference at virtual address 0000010e c01f2130 *pde = 00000000 Oops: 0000 CPU: 1 EIP: 0010:[] Tainted: PF EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: c03c9440 edx: 00000000 esi: d8311ae4 edi: f7dae000 ebp: d0aabe48 esp: d0aabe08 ds: 0018 es: 0018 ss: 0018 Process ls (pid: 2695, stackpage=d0aab000) Stack: d8311af8 c03c9440 000001f0 00000000 f7d56240 00000012 f7dae000 00000004 00000000 00000000 00000000 01000100 00000000 00000000 d0aabebc f4f15e50 d0aabe98 c020b495 f7dae000 00000000 01000100 00000000 00000000 d0aabebc Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 26 01 00 00 00 74 27 89 34 24 c7 44 24 04 84 00 00 >>EIP; c01f2130 <===== Trace; c020b495 Trace; c01f2716 Trace; c02105f3 Trace; c021d5b3 Trace; c014a0a2 Trace; c014a83d Trace; c014ae91 <__user_walk+61/70> Trace; c014728e Trace; c01177e0 Trace; c01092ab Code; c01f2130 00000000 <_EIP>: Code; c01f2130 <===== 0: 66 83 bb 26 01 00 00 cmpw $0x0,0x126(%ebx) <===== Code; c01f2137 7: 00 Code; c01f2138 8: 74 27 je 31 <_EIP+0x31> Code; c01f213a a: 89 34 24 mov %esi,(%esp,1) Code; c01f213d d: c7 44 24 04 84 00 00 movl $0x84,0x4(%esp,1) Code; c01f2144 14: 00 From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:20:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:20:59 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8KutG003483 for ; Fri, 13 Sep 2002 01:20:57 -0700 Received: from auto-nb1.xs4all.nl (host-4.coltex.demon.nl [212.238.252.68]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8D8PYsW078945; Fri, 13 Sep 2002 10:25:34 +0200 (CEST) Message-Id: <4.3.2.7.2.20020913102232.03d193f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Sep 2002 10:24:22 +0200 To: Clem Taylor , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: ls segfaults, kernel does NULL pointer dereference... In-Reply-To: <3D817F8A.6020205@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 372 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 02:02 13-9-2002 -0400, Clem Taylor wrote: >I came home to find my 1.1TB disk array in a sick state, a drive is >failing... When I do an ls on the volume, ls segfaults and the log shows >that the kernel tried to dereference a NULL pointer. > >I'm running 2.4.19-rc1-xfs on a dual Athlon with a 3ware 7xxx controller >and 6 160G Maxtor drives. I repaired the drive (and ordered a new one) and >after reboot everything seems to be okay. It does seem a little strange >that XFS would fail this way.... Normally XFS would detect corruption and shutdown the fs. Did you see anything about this in the logs? What extra modules/patches do you have loaded? Is the 3ware controller loaded with the latest firmware and drivers? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:24:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:24:21 -0700 (PDT) Received: from relay.dstl.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8ODtG004006 for ; Fri, 13 Sep 2002 01:24:14 -0700 Received: (qmail 24487 invoked from network); 13 Sep 2002 09:28:51 +0100 Received: from warlock.dstl.gov.uk (192.5.29.10) by relay.dera.gov.uk with SMTP; 13 Sep 2002 09:28:51 +0100 Subject: Re: ls segfaults, kernel does NULL pointer dereference... From: Tony Gale To: Clem Taylor Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D817F8A.6020205@dstl.gov.uk> References: <3D817F8A.6020205@dstl.gov.uk> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4NWM+GuKK7bv1cGRuh8g" X-Mailer: Ximian Evolution 1.0.8.99 Date: 13 Sep 2002 09:28:52 +0100 Message-Id: <1031905732.316.1.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 X-archive-position: 373 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gale@syntax.dstl.gov.uk Precedence: bulk X-list: linux-xfs --=-4NWM+GuKK7bv1cGRuh8g Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2002-09-13 at 07:02, Clem Taylor wrote: > EIP: 0010:[] Tainted: PF What has the kernel been tainted by? -tony --=-4NWM+GuKK7bv1cGRuh8g Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iQCVAwUAPYGhxB/0GZs/Z0FlAQKe5wP/RXU//1vJcJ6ckvl9EmEZNbOrN+Pw4xsG KCB6WPGD3VzC3vRZ4T+1I5w8GM8VO9VdDFwwxqGwVgVeIEw9v5VJsizKykEDMPvq vfODV2Wx5igsbSskU9LVqixFgh213ACimJlT4hlnQTB7fa/GGM1TXDstCDn8iKeB bhoDT7Lna/s= =iBzZ -----END PGP SIGNATURE----- --=-4NWM+GuKK7bv1cGRuh8g-- From owner-linux-xfs@oss.sgi.com Fri Sep 13 01:50:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 01:50:51 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8D8ojtG004789 for ; Fri, 13 Sep 2002 01:50:45 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 4ED9E1438D; Fri, 13 Sep 2002 10:55:20 +0200 (MEST) Date: Fri, 13 Sep 2002 10:55:19 +0200 From: Andi Kleen To: Clem Taylor Cc: linux-xfs@oss.sgi.com Subject: Re: ls segfaults, kernel does NULL pointer dereference... Message-ID: <20020913105519.A21554@wotan.suse.de> References: <3D817F8A.6020205@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D817F8A.6020205@attbi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 374 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 02:02:50AM -0400, Clem Taylor wrote: > I came home to find my 1.1TB disk array in a sick state, a drive is > failing... When I do an ls on the volume, ls segfaults and the log shows > that the kernel tried to dereference a NULL pointer. > > I'm running 2.4.19-rc1-xfs on a dual Athlon with a 3ware 7xxx controller > and 6 160G Maxtor drives. I repaired the drive (and ordered a new one) and > after reboot everything seems to be okay. It does seem a little strange > that XFS would fail this way.... > Looks like a bug in xfs_iget's error handling. When a read error occurs during getting the inode xfs_iget_core doesn't insert a vnode behaviour and later code which assumes that the behaviour is there fails. This patch should fix it at least for this case. It may be safer to always insert a behaviour even in the error case, but one would hope that all callers of xfs_iget handle errors properly. --- linux/fs/xfs/xfs_iget.c-o Tue Aug 27 21:00:43 2002 +++ linux/fs/xfs/xfs_iget.c Fri Sep 13 10:53:58 2002 @@ -493,6 +493,10 @@ goto retry; } + if (is_bad_inode(inode)) { + iput(inode); + return EIO; + } bdp = vn_bhv_lookup(VN_BHV_HEAD(vp), &xfs_vnodeops); ip = XFS_BHVTOI(bdp); if (lock_flags != 0) { -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 13 06:04:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 06:04:20 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DD4EtG009595 for ; Fri, 13 Sep 2002 06:04:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA21783 for ; Fri, 13 Sep 2002 08:08:51 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA16185 for ; Fri, 13 Sep 2002 08:08:49 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKNvP26542 for linux-xfs@oss.sgi.com; Fri, 13 Sep 2002 16:23:57 -0400 Resent-Message-Id: <200209132023.g8DKNvP26542@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA61047 for ; Fri, 13 Sep 2002 07:57:46 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKCrE25712 for hch@sgi.com; Fri, 13 Sep 2002 16:12:53 -0400 Date: Fri, 13 Sep 2002 16:12:53 -0400 From: Christoph Hellwig Message-Id: <200209132012.g8DKCrE25712@dhcp212.munich.sgi.com> Subject: TAKE - Fix up comments: Pagebuf is only used for metadata nowdays Resent-Date: Fri, 13 Sep 2002 16:23:56 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 375 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Sep 13 05:57:01 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127345a linux/fs/xfs/pagebuf/page_buf_locking.c - 1.29 linux/fs/xfs/pagebuf/page_buf.c - 1.59 - Fix up comments: Pagebuf is only used for metadata nowdays From owner-linux-xfs@oss.sgi.com Fri Sep 13 06:32:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 06:32:28 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DDWQtG010319 for ; Fri, 13 Sep 2002 06:32:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA21640 for ; Fri, 13 Sep 2002 08:37:02 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA99866 for ; Fri, 13 Sep 2002 08:37:01 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKq8929852 for linux-xfs@oss.sgi.com; Fri, 13 Sep 2002 16:52:08 -0400 Resent-Message-Id: <200209132052.g8DKq8929852@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id IAA90126 for ; Fri, 13 Sep 2002 08:36:29 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DKpaM29843 for hch@sgi.com; Fri, 13 Sep 2002 16:51:36 -0400 Date: Fri, 13 Sep 2002 16:51:36 -0400 From: Christoph Hellwig Message-Id: <200209132051.g8DKpaM29843@dhcp212.munich.sgi.com> Subject: TAKE - Fix the scheduler fix Resent-Date: Fri, 13 Sep 2002 16:52:08 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 376 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs I fixed it for the O(1) scheduler but broke it for the stock one, duh. Found by Nathan Scott. Date: Fri Sep 13 06:34:53 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127348a linux/fs/xfs/pagebuf/page_buf.c - 1.60 - Add back missing current->cpus_allowed = 1UL << cpu; in the pagebuf initialization for the old scheduler. Tidy up check for new scheduler a little and comment it properly. From owner-linux-xfs@oss.sgi.com Fri Sep 13 06:58:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 06:58:19 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DDwDtG010969 for ; Fri, 13 Sep 2002 06:58:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA21159 for ; Fri, 13 Sep 2002 09:02:50 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA96045 for ; Fri, 13 Sep 2002 09:02:48 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8DLHui31155 for linux-xfs@oss.sgi.com; Fri, 13 Sep 2002 17:17:56 -0400 Date: Fri, 13 Sep 2002 17:17:56 -0400 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: TAKE - Return -ENOMEM on vmap failure in _pagebuf_lookup_pages] Message-ID: <20020913171756.A31081@dhcp212.munich.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 377 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs This handles the problem Samuel saw more gracefully, but the cause of the vmap failure is still not solved. (Which is like to be outside XFS) Date: Fri Sep 13 06:58:21 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127349a linux/fs/xfs/pagebuf/page_buf.c - 1.61 - Return -ENOMEM on vmap failure in _pagebuf_lookup_pages From owner-linux-xfs@oss.sgi.com Fri Sep 13 09:32:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 09:32:35 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DGWQtG014861 for ; Fri, 13 Sep 2002 09:32:27 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id PAA30903; Fri, 13 Sep 2002 15:25:39 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8DCsGoq025550; Fri, 13 Sep 2002 14:54:16 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8DCro8Q022902; Fri, 13 Sep 2002 14:53:50 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8DCrjEn022901; Fri, 13 Sep 2002 14:53:45 +0200 Date: Fri, 13 Sep 2002 14:53:45 +0200 From: Andrea Arcangeli To: Samuel Flory Cc: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913125345.GO11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8149F6.9060702@rackable.com> User-Agent: Mutt/1.3.27i X-archive-position: 378 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 12, 2002 at 07:14:14PM -0700, Samuel Flory wrote: > include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) > include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) > > > Andrea Arcangeli wrote: > > >On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: > > > > > >>How much memory is in the machine by the way? And Andrea, is the > >>vmalloc space size reduced in the 3G user space configuration? > >> > >> > > > >it's not reduced, it's the usual 128m. > > > >BTW, I forgot to say that to really take advantage of CONFIG_2G one > >should increase __VMALLOC_RESERVE too, it's not directly in function of > >the CONFIG_2G. > > > > So how much do you recommend increasing it? Currently it's: > include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) > include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to (512 << 20) and see if it helps. If it only happens a bit later then it's most probably an address space leak, should be easy to track down some debugging instrumentation. Andrea From owner-linux-xfs@oss.sgi.com Fri Sep 13 11:21:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 11:22:01 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DILttG016747 for ; Fri, 13 Sep 2002 11:21:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA24433 for ; Fri, 13 Sep 2002 13:26:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA15955 for ; Fri, 13 Sep 2002 13:26:32 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8DINgZ25682; Fri, 13 Sep 2002 13:23:42 -0500 Message-Id: <200209131823.g8DINgZ25682@jen.americas.sgi.com> Date: Fri, 13 Sep 2002 13:23:42 -0500 Subject: TAKE - remove dead code paths from create/mkdir/link/symlink To: linux-xfs@oss.sgi.com X-archive-position: 379 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The vfs layer locking in linux means that there were several code paths in the new inode creation paths which could never happen. We only get into the filesystem's create paths if there is nothing there, these paths were checking for an existing name. Date: Fri Sep 13 11:24:43 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127368a linux/fs/xfs/xfs_vnodeops.c - 1.563 From owner-linux-xfs@oss.sgi.com Fri Sep 13 12:13:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 12:13:18 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DJDCtG021788 for ; Fri, 13 Sep 2002 12:13:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA25145; Fri, 13 Sep 2002 14:17:49 -0500 (CDT) Received: from [192.168.1.101] (IDENT:5UD84r2pYEHcoZJLaoAv2VpZkYC2TAYM@mtv-vpn-sw-corp-0-43.corp.sgi.com [134.15.0.43]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA43110; Fri, 13 Sep 2002 14:17:42 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Samuel Flory Cc: Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com In-Reply-To: <3D813CFB.7050200@rackable.com> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <3D813CFB.7050200@rackable.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 13 Sep 2002 14:17:42 -0500 Message-Id: <1031944671.1534.34.camel@snafu> Mime-Version: 1.0 X-archive-position: 380 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-12 at 20:18, Samuel Flory wrote: > > The system has 4G of ram, and 4G of swap. So real memory is not an > issue. The system is a intended to be an nfs server. As a result nfs > performance is my only real concern. I should really use CONFIG_3GB as > I'm not doing much in user space other a tftp, and dhcp server. > > In any case the system isn't in production so I can leave it as is > till monday. > So, after backing out 00_net-softirq (this was killing my networking and NFS setup for some reason) and applying the new scheduler related fix in xfs, I have had this kernel up a few hours running dbench and a bunch of other things, it has not hung once or exhibited any other problems. Having said that, my environment is different, I do not have 4G of memory, I have 128M, and I also do not have md - not enough disks right now to do that. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Sep 13 12:59:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 12:59:35 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DJxWtG022973 for ; Fri, 13 Sep 2002 12:59:32 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 34BE41D7219; Fri, 13 Sep 2002 13:04:15 -0700 (PDT) Date: Fri, 13 Sep 2002 13:04:15 -0700 From: Chris Wedgwood To: Nathan Scott Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020913200415.GA19984@tapu.f00f.org> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> <20020913091211.B133147@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020913091211.B133147@wobbly.melbourne.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 381 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 09:12:11AM +1000, Nathan Scott wrote: > Extended attributes, not ACLs. We may want to switch this behavior > via a mount flag or something, to give either the IRIX or the Linux > semantics (like we did for SGID) - we'll talk. What differences exist right now? --cw From owner-linux-xfs@oss.sgi.com Fri Sep 13 13:46:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 13:46:35 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DKkTtG023934 for ; Fri, 13 Sep 2002 13:46:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA26815 for ; Fri, 13 Sep 2002 15:51:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA84033 for ; Fri, 13 Sep 2002 15:51:06 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8DKkhV22107; Fri, 13 Sep 2002 15:46:43 -0500 Message-Id: <200209132046.g8DKkhV22107@stout.americas.sgi.com> Date: Fri, 13 Sep 2002 15:46:43 -0500 Subject: TAKE - Fix xfs_iget error handling X-archive-position: 382 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs (from Andi Kleen) xfs_iget error handling Date: Fri Sep 13 13:50:44 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127385a linux/fs/xfs/xfs_iget.c - 1.171 From owner-linux-xfs@oss.sgi.com Fri Sep 13 13:47:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 13:47:14 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DKlAtG024169 for ; Fri, 13 Sep 2002 13:47:11 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA25434; Fri, 13 Sep 2002 15:51:48 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id PAA32477; Fri, 13 Sep 2002 15:51:47 -0500 (CDT) Subject: Re: TAKE - change symlink perms to 777 From: Eric Sandeen To: Chris Wedgwood Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020913200415.GA19984@tapu.f00f.org> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> <20020913091211.B133147@wobbly.melbourne.sgi.com> <20020913200415.GA19984@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 13 Sep 2002 15:47:24 -0500 Message-Id: <1031950045.14984.14.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 383 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Irix/XFS symlinks have the umask applied, other linux filesystems just make them 777. -Eric On Fri, 2002-09-13 at 15:04, Chris Wedgwood wrote: > On Fri, Sep 13, 2002 at 09:12:11AM +1000, Nathan Scott wrote: > > > Extended attributes, not ACLs. We may want to switch this behavior > > via a mount flag or something, to give either the IRIX or the Linux > > semantics (like we did for SGID) - we'll talk. > > What differences exist right now? > > > --cw -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Fri Sep 13 13:53:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 13:53:57 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DKrotG025078 for ; Fri, 13 Sep 2002 13:53:50 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id NAA04916 for ; Fri, 13 Sep 2002 13:58:28 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id GAA21411; Sat, 14 Sep 2002 06:57:11 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id GAA36856; Sat, 14 Sep 2002 06:57:10 +1000 (AEDT) Date: Sat, 14 Sep 2002 06:57:10 +1000 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020914065710.A90915@wobbly.melbourne.sgi.com> References: <200209111343.IAA10993@fsgi158.americas.sgi.com> <1031753707.9726.1.camel@stout.americas.sgi.com> <20020913091211.B133147@wobbly.melbourne.sgi.com> <20020913200415.GA19984@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020913200415.GA19984@tapu.f00f.org>; from cw@f00f.org.com on Fri, Sep 13, 2002 at 01:04:15PM -0700 X-archive-position: 384 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 01:04:15PM -0700, Chris Wedgwood wrote: > On Fri, Sep 13, 2002 at 09:12:11AM +1000, Nathan Scott wrote: > > > Extended attributes, not ACLs. We may want to switch this behavior > > via a mount flag or something, to give either the IRIX or the Linux > > semantics (like we did for SGID) - we'll talk. > > What differences exist right now? > No differences exist right now because Eric has backed out the change. See the cvs log for Eric's change (its a one-liner), cheers. btw, I think some mail relay (possibly inside sgi) is botching sending mail to you from me - I've tried to send you a reply on some other (unrelated) mail before and it always seems to bounce. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Sep 13 14:03:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 14:03:13 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DL3BtG025987 for ; Fri, 13 Sep 2002 14:03:11 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8DL7jv05699; Fri, 13 Sep 2002 17:07:45 -0400 Message-ID: <3D825422.8000007@rackable.com> Date: Fri, 13 Sep 2002 14:09:54 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 385 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Andrea Arcangeli wrote: > > >you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to >(512 << 20) and see if it helps. If it only happens a bit later then >it's most probably an address space leak, should be easy to track down >some debugging instrumentation. > > It seems to be working for me now. I'm getting about 200 on dbench 4, and 90 on dbench 64. (Note you need to increase your log size to get these kinda of numbers.) Now I get to see how fast I can read files via nfs. From owner-linux-xfs@oss.sgi.com Fri Sep 13 14:13:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 14:13:44 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8DLDdtG026620 for ; Fri, 13 Sep 2002 14:13:40 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id XAA08338; Fri, 13 Sep 2002 23:50:44 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8DLJIoq026487; Fri, 13 Sep 2002 23:19:18 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8DLIq8Q017605; Fri, 13 Sep 2002 23:18:52 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8DLIiS7017602; Fri, 13 Sep 2002 23:18:44 +0200 Date: Fri, 13 Sep 2002 23:18:44 +0200 From: Andrea Arcangeli To: Samuel Flory Cc: Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020913211844.GP11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D825422.8000007@rackable.com> User-Agent: Mutt/1.3.27i X-archive-position: 386 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Fri, Sep 13, 2002 at 02:09:54PM -0700, Samuel Flory wrote: > Andrea Arcangeli wrote: > > > > > > >you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to > >(512 << 20) and see if it helps. If it only happens a bit later then > >it's most probably an address space leak, should be easy to track down > >some debugging instrumentation. > > > > > > > It seems to be working for me now. I'm getting about 200 on dbench 4, > and 90 on dbench 64. (Note you need to increase your log size to get > these kinda of numbers.) Now I get to see how fast I can read files via > nfs. btw, if you run into troubles with networking with aa2 try to backout the last net-softirq patch, not sure why yet but the last modification I did malfunctions with some nic. Couldn't reproduce it here, but I'll look into that next week and I'll fix it too for the next -aa. So, returning to xfs, it is possible dbench really generates lots of simultaneous vmaps because of its concurrency, so I would suggest to add an atomic counter increased at every vmap/vmalloc and decreased at every vfree and to check it after every increase storing the max value in a sysctl, to see what's the max concurrency you reach with the vmaps. (you can also export the counter via the sysctl, to verify for no memleaks after unmounting xfs) Andrea From owner-linux-xfs@oss.sgi.com Fri Sep 13 22:04:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Sep 2002 22:04:20 -0700 (PDT) Received: from issv0171.isis.de (issv0171.isis.de [195.158.131.223]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8E54HtG031711 for ; Fri, 13 Sep 2002 22:04:17 -0700 Received: (qmail 5548 invoked by uid 1010); 10 Sep 2002 19:32:56 -0000 Received: from unknown (HELO knecht.alpha) ([195.158.156.135]) (envelope-sender ) by mail.isis.de (qmail-ldap-1.03) with SMTP for ; 10 Sep 2002 19:32:56 -0000 Received: from athlet (athlet.alpha [192.168.1.101]) by knecht.alpha (Postfix) with ESMTP id 3F2A96D08; Tue, 10 Sep 2002 21:32:54 +0200 (CEST) Date: Tue, 10 Sep 2002 21:32:51 +0200 From: thomas X-Mailer: The Bat! (v1.61) Reply-To: thomas X-Priority: 3 (Normal) Message-ID: <1019359078.20020910213251@huno.net> To: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: raid1 (u)mount error In-Reply-To: <20020910192023.GA5470@tapu.f00f.org> References: <527280437.20020910155814@huno.net> <20020910182241.GA5230@tapu.f00f.org> <1031682497.22845.97.camel@jen.americas.sgi.com> <20020910184228.GA5323@tapu.f00f.org> <1031683668.22845.102.camel@jen.americas.sgi.com> <20020910185723.GA5375@tapu.f00f.org> <1298234671.20020910211407@huno.net> <20020910192023.GA5470@tapu.f00f.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 387 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tom@huno.net Precedence: bulk X-list: linux-xfs >> nope / is reiserfs. > and this is /dev/md0 for you? or something else? sorry, i guess i wasn't clear enough in my first post :) situation is like this: +[~]: df -Th Filesystem Type Size Used Avail Use% Mounted on /dev/hda1 reiserfs 2.2G 430M 1.8G 20% / /dev/hdc1 reiserfs 2.2G 1.6G 634M 72% /var /dev/md0 xfs 75G 69G 5.9G 93% /data +[~]: cat /proc/mdstat Personalities : [raid1] read_ahead 1024 sectors md0 : active raid1 hdc5[0] hda5[1] 78123904 blocks [2/2] [UU] all the stuff that i thought might be also responsible for this (sysvinit, mount, raidttols, ...) is already upgraded to latest version. now if there is a chance that cvs *might* help here i'm on my way to grab it. can i patch cvs with 2.4.19 or do i have to get 2.4.20-pre5? thomas From owner-linux-xfs@oss.sgi.com Sat Sep 14 07:36:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Sep 2002 07:36:21 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8EEaFtG005364 for ; Sat, 14 Sep 2002 07:36:15 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA31253; Sat, 14 Sep 2002 09:40:54 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-39.corp.sgi.com [134.15.64.39]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id JAA22754; Sat, 14 Sep 2002 09:40:52 -0500 (CDT) Subject: Re: 2.4.20pre5aa2 From: Stephen Lord To: Andrea Arcangeli Cc: Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel Mailing List , linux-xfs@oss.sgi.com In-Reply-To: <20020913211844.GP11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> <20020913211844.GP11605@dualathlon.random> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Sep 2002 09:39:24 -0500 Message-Id: <1032014367.1050.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 388 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote: > So, returning to xfs, it is possible dbench really generates lots of > simultaneous vmaps because of its concurrency, so I would suggest to add > an atomic counter increased at every vmap/vmalloc and decreased at every > vfree and to check it after every increase storing the max value in a > sysctl, to see what's the max concurrency you reach with the vmaps. (you > can also export the counter via the sysctl, to verify for no memleaks > after unmounting xfs) > > Andrea There are no vmaps during normal operation on xfs unless you are setting extended attributes of more than 4K in size, or you used some more obscure mkfs options. Only filesystem recovery will use it otherwise. Steve From owner-linux-xfs@oss.sgi.com Sat Sep 14 07:53:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Sep 2002 07:54:02 -0700 (PDT) Received: from mailcity.com (fes3-mail.whowhere.com [209.202.220.160] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8EErxtG005916 for ; Sat, 14 Sep 2002 07:53:59 -0700 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Sat, 14 Sep 2002 14:58:32 -0000 To: jackie50002@lycos.com Date: Sat, 14 Sep 2002 10:58:32 -0400 From: "JACKIE SIDEBE MODISE" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: jackie50002@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 Subject: FUND MANAGEMENT X-Sender-Ip: 216.139.164.204 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit X-archive-position: 389 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jackie50002@lycos.com Precedence: bulk X-list: linux-xfs From ; Jackie Sidebe Modise FUND MANAGEMENT Eventually I have made up my mind to contact you with humility for your assistance in matter of urgent important. I am Jackie Sidebe Modise, legal wife of Comrade Joe Modise,late leader of Umkhonto we Sizwe (MK),renowed freedom fighters, first minister of defence during Nelson Mandela Government of National Unity 1994 and owner of conglomorate of business. Our family made name in Gold Industry of South Africa. Unfortunately, my husband died after retiring from office and his death though linked to cancer but has traces of severe pressures from the new Government who wanted to probe his activities. Anyway nothing really got on the way about the probe proir his death but Government succeeded in frozening the family bank account and business assets while the immediate/larger family wallow! in porverty. However as the last,closest and legimate wife before he died I was opportuned to be in pocession of valuables including valued sum of US$42 million which I personally moved out during controversies with Government just after his death. This fortune I carefully deposited with a Security Company as PERSONAL EFFECT and I now want a trusted foreigner to represent me reclaim the funds for investment overseas. For obvious security reasons, I do not want to place this fund with established financial institution with the family name. It is my desire that this is handled as quietly as possible without possibility of any leakage to the public, government or even other family members hence I must be out of the scene while the transaction lasts. I have a lawyer to handle the matter and I have briefed him with full powers and confidence to lead and guide the transaction to a success. All evidence of the deposits is with! him too therefore I request you stand to receive the deposits and keep under your custody the funds for good management. MY LAWYER IS: STEPHEN AKIM ANCIENT CHAMBERS TEL.873-762-135441 Or Fax: 873-762-135442 Email. ancientchambers@ureach.com If you agree to act as my fund manager, the funds is safe with a private security company coded and lodged in with a fictitious name. Upon a favorable response from you, you will be adviced with the steps involve. No risk is on this because it has no record but you must respect my position.Your commission shall be 15% of the total sum as first payment plus annual 10% of the after tax returns on investment for the first 5 years but this is negotiable. If you are capable and willing to participate in this transaction quickly contact my email lawyer asap and if for any reason you are not disposed let me know still so I make alternative arrangement. I look forward to your earliest reply and do not forget the principles of secrecy and confidentiality. In any case, keep these Best regards Mrs Jackie Sidebe Modise _____________________________________________________________ Play the Elvis® Scratch & Win for your chance to instantly win $10,000 Cash - a 2003 Harley Davidson® Sportster® - 1 of 25,000 CD's - and more! http://r.lycos.com/r/sagel_mail_scratch_tl/http://win.ipromotions.com/lycos_020801/index.asp?tc=7087 From owner-linux-xfs@oss.sgi.com Sun Sep 15 03:55:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 03:55:49 -0700 (PDT) Received: from fruit.eu.org (qmailr@d5111f5b.cable.wanadoo.nl [213.17.31.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FAthtG020267 for ; Sun, 15 Sep 2002 03:55:44 -0700 Received: (qmail 15373 invoked by uid 500); 15 Sep 2002 11:00:30 -0000 Date: Sun, 15 Sep 2002 13:00:30 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020915110030.GH17696@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> <20020911193759.GJ714@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020911193759.GJ714@plato.local.lan> User-Agent: Mutt/1.4i X-oi: oi X-archive-position: 390 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-11 11:37:59-0800, Ethan Benson wrote: > > They are not. Consider a sticky directory. > what are you talking about? they are still irrelevant. Usually, sticky directories check unlink() authorisation by looking at the access bits of the file itself. It seems that Linux currently always returns EPERM when you try to delete a symlink that is not owned by you if it's in a sticky directory. It wasn't like that the last time I tested it, so I was basing my statement on outdated assumptions. Sorry. You are right, symlink permissions are completly irrelevant. Even readlink() isn't thwarted by them. -- wsl@fruit.eu.org From owner-linux-xfs@oss.sgi.com Sun Sep 15 04:08:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 04:08:50 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FB8itG021220 for ; Sun, 15 Sep 2002 04:08:44 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id B988314732; Sun, 15 Sep 2002 13:13:27 +0200 (MEST) Date: Sun, 15 Sep 2002 13:13:24 +0200 From: Andi Kleen To: Stephen Lord Cc: Andrea Arcangeli , Samuel Flory , Austin Gonyou , Christian Guggenberger , Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020915131324.A13516@wotan.suse.de> References: <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> <20020913211844.GP11605@dualathlon.random> <1032014367.1050.2.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032014367.1050.2.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 391 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Sat, Sep 14, 2002 at 09:39:24AM -0500, Steve Lord wrote: > On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote: > > > So, returning to xfs, it is possible dbench really generates lots of > > simultaneous vmaps because of its concurrency, so I would suggest to add > > an atomic counter increased at every vmap/vmalloc and decreased at every > > vfree and to check it after every increase storing the max value in a > > sysctl, to see what's the max concurrency you reach with the vmaps. (you > > can also export the counter via the sysctl, to verify for no memleaks > > after unmounting xfs) > > > > Andrea > > There are no vmaps during normal operation on xfs unless you are > setting extended attributes of more than 4K in size, or you > used some more obscure mkfs options. Only filesystem recovery will > use it otherwise. Perhaps the original poster used those obscure mkfs options? What option will trigger huge allocations ? -Andi From owner-linux-xfs@oss.sgi.com Sun Sep 15 05:07:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 05:07:43 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FC7btG027403 for ; Sun, 15 Sep 2002 05:07:37 -0700 Received: from erbenson.alaska.net (104-pm18.nwc.alaska.net [209.112.142.104]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8FCCPBs072604 for ; Sun, 15 Sep 2002 04:12:26 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id EC14F3A0A for ; Sun, 15 Sep 2002 04:12:24 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 52E974104E2; Sun, 15 Sep 2002 04:12:24 -0800 (AKDT) Date: Sun, 15 Sep 2002 04:12:24 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020915121224.GA1746@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> <20020911193759.GJ714@plato.local.lan> <20020915110030.GH17696@fruit.eu.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: <20020915110030.GH17696@fruit.eu.org> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 392 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 15, 2002 at 01:00:30PM +0200, Wessel Dankers wrote: > On 2002-09-11 11:37:59-0800, Ethan Benson wrote: > > > They are not. Consider a sticky directory. > > what are you talking about? they are still irrelevant. >=20 > Usually, sticky directories check unlink() authorisation by looking at the > access bits of the file itself. you are wrong, sticky directories check the ownership of the file and only allow unlink() if the file owner matches the uid of the user attempting unlink(), or if the user owns the sticky directory, or the user is root. the file's permissions have absolutly nothing to do with it.=20=20 and if they did forcing symlinks to mode 777 would be a security hole since it would allow any user to always delete them in sticky dirs. > It seems that Linux currently always returns EPERM when you try to delete= a > symlink that is not owned by you if it's in a sticky directory. It wasn't > like that the last time I tested it, so I was basing my statement on > outdated assumptions. Sorry. i have never heard of symlinks being treated special in this manner, they are just files like anything else. > You are right, symlink permissions are completly irrelevant. Even > readlink() isn't thwarted by them. from chmod(1) chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2EeSgACgkQJKx7GixEevzLGQCbBIx3vQCtyASzyaHb0m4OyFuW DQsAnAyuiQsDYGqbGbhUHgIJM1X7u+RN =UH+l -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-linux-xfs@oss.sgi.com Sun Sep 15 08:30:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 08:30:29 -0700 (PDT) Received: from fruit.eu.org (qmailr@d5111f5b.cable.wanadoo.nl [213.17.31.91]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FFUDtG028933 for ; Sun, 15 Sep 2002 08:30:13 -0700 Received: (qmail 16326 invoked by uid 500); 15 Sep 2002 15:35:02 -0000 Date: Sun, 15 Sep 2002 17:35:02 +0200 From: Wessel Dankers To: linux-xfs@oss.sgi.com Cc: Ethan Benson Subject: Re: TAKE - change symlink perms to 777 Message-ID: <20020915153502.GI17696@fruit.eu.org> Mail-Followup-To: linux-xfs@oss.sgi.com, Ethan Benson References: <200209102023.g8AKNdB29305@stout.americas.sgi.com> <20020910212614.GA10273@tapu.f00f.org> <20020911071824.GG714@plato.local.lan> <20020911122332.GD17696@fruit.eu.org> <20020911193759.GJ714@plato.local.lan> <20020915110030.GH17696@fruit.eu.org> <20020915121224.GA1746@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020915121224.GA1746@plato.local.lan> User-Agent: Mutt/1.4i X-oi: oi X-archive-position: 393 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: wsl@fruit.eu.org Precedence: bulk X-list: linux-xfs On 2002-09-15 04:12:24-0800, Ethan Benson wrote: > you are wrong, sticky directories check the ownership of the file and > only allow unlink() if the file owner matches the uid of the user > attempting unlink(), or if the user owns the sticky directory, or the > user is root. the file's permissions have absolutly nothing to do > with it. Apparently Linux differs from Solaris in this respect (which seems to be where I remembered the semantics from): merry:/tmp% uname -a SunOS merry 5.8 Generic sun4m sparc merry:/tmp% id uid=100(wsl) gid=1(other) groups=1(other) merry:/tmp% ls -l foo -rw-rw-rw- 1 nobody nobody 4 Sep 15 17:12 foo merry:/tmp% rm foo merry:/tmp% ls -l foo foo: No such file or directory Solaris disallows unlinking other people's symlinks though. Again, I apologize for the noise. > from chmod(1) > > [snip] from shred(1) CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective: * log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, Ext3, etc.) ^^^ Manpages aren't always 100% reliable (although your excerpt was certainly correct). Regards, -- wsl@fruit.eu.org From owner-linux-xfs@oss.sgi.com Sun Sep 15 12:32:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Sep 2002 12:32:12 -0700 (PDT) Received: from host.greatconnect.com (host.greatconnect.com [209.239.40.135]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8FJW4tG031866 for ; Sun, 15 Sep 2002 12:32:05 -0700 Received: from rackable.com (adsl-67-114-192-42.dsl.pltn13.pacbell.net [67.114.192.42]) by host.greatconnect.com (8.10.2/8.10.2) with ESMTP id g8FJagv20311; Sun, 15 Sep 2002 15:36:43 -0400 Message-ID: <3D84E1E8.1070408@rackable.com> Date: Sun, 15 Sep 2002 12:39:20 -0700 From: Samuel Flory User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andi Kleen CC: Stephen Lord , Andrea Arcangeli , Austin Gonyou , Christian Guggenberger , Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D825422.8000007@rackable.com> <20020913211844.GP11605@dualathlon.random> <1032014367.1050.2.camel@laptop.americas.sgi.com> <20020915131324.A13516@wotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 394 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sflory@rackable.com Precedence: bulk X-list: linux-xfs Andi Kleen wrote: >On Sat, Sep 14, 2002 at 09:39:24AM -0500, Steve Lord wrote: > > >>On Fri, 2002-09-13 at 16:18, Andrea Arcangeli wrote: >> >> >> >>>So, returning to xfs, it is possible dbench really generates lots of >>>simultaneous vmaps because of its concurrency, so I would suggest to add >>>an atomic counter increased at every vmap/vmalloc and decreased at every >>>vfree and to check it after every increase storing the max value in a >>>sysctl, to see what's the max concurrency you reach with the vmaps. (you >>>can also export the counter via the sysctl, to verify for no memleaks >>>after unmounting xfs) >>> >>>Andrea >>> >>> >>There are no vmaps during normal operation on xfs unless you are >>setting extended attributes of more than 4K in size, or you >>used some more obscure mkfs options. Only filesystem recovery will >>use it otherwise. >> >> > >Perhaps the original poster used those obscure mkfs options? What option >will trigger huge allocations ? > I did not use any special options on the filesystem that had the issue. From owner-linux-xfs@oss.sgi.com Mon Sep 16 01:39:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 01:39:32 -0700 (PDT) Received: from [173.161.112.145] (adsl-nk-A2434.hitron.net [203.79.163.148]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8G8dPtG011930 for ; Mon, 16 Sep 2002 01:39:26 -0700 Received: from [173.161.162.145] by [173.161.26.145] with SMTP (MDaemon.v2.7.SP4.R) for ; Fri, 18 Feb 2000 09:36:51 +0800 From: mlpi_uy_rff03dw@amazon.com To: linux-xfs@oss.sgi.com Subject: =?ISO-8859-1?Q?=B1=A1=BD=EC=A5=CE=AB~?= =?ISO-8859-1?Q?=BA=F4=B8=F4=C1=CA=AA=AB=B0=D3=AB=B0?= Reply-To: n3qv_coe_e3cbiy@bloomberg.com Date: 14 Sep 2002 21:39:16 +0800 Received: from login_0216.mailservice.net (mx.service.net[206.232.231.77] (may be forged)) by [192.201.131.147] (8.8.5/8.7.3) with SMTP id XAA03254; ¬P´Á¥| 22 ¤K¤ë 2002 06:16:37 -0700 (EDT) Reply-To: receive_adm@topservice.net X-PMFLAGS: 10326341.10 X-UIDL: 10293217_192832.222 Comments: Authenticated Sender is Message-Id: <57269272_90816187> MIME-Version: 1.0 Content-Type: text/html Content-Transfer-Encoding: 8bit X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com X-Return-Path: mlpi_uy_rff03dw@amazon.com X-archive-position: 395 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mlpi_uy_rff03dw@amazon.com Precedence: bulk X-list: linux-xfs µL¼ÐÃD¤å¥ó

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

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

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

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

¶i¤J

 

From owner-linux-xfs@oss.sgi.com Mon Sep 16 04:38:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 04:38:17 -0700 (PDT) Received: from rtsoft.rtsoft.msk.ru (Rtsoft-MTUInform-GW.mtu.ru [195.34.37.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GBbxtG025272 for ; Mon, 16 Sep 2002 04:38:10 -0700 Received: from mail by rtsoft.rtsoft.msk.ru with local (Exim 3.12 #1 (Debian)) id 17quHC-00050B-00; Mon, 16 Sep 2002 15:42:50 +0400 Received: from [192.168.100.40] (helo=develop.dev.rtsoft.msk.ru) by rtsoft.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17quHC-000502-00 for ; Mon, 16 Sep 2002 15:42:50 +0400 Received: from becha.dev.rtsoft.msk.ru ([192.168.100.169] helo=rtsoft.msk.ru) by develop.dev.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17quH6-0002Rh-00 for ; Mon, 16 Sep 2002 15:42:44 +0400 Message-ID: <3D85C8D5.6030901@rtsoft.msk.ru> Date: Mon, 16 Sep 2002 16:04:37 +0400 From: Frasenyak Dmitrij User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011031 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Need information about XFS tests Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-KAV: KavKeeper passed X-archive-position: 396 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sed@rtsoft.msk.ru Precedence: bulk X-list: linux-xfs Hello I'm looking for any documentation about XFS tests included in CVS tree. I've searched over sgi site and Internet but found only small remarks in the headers of scripts. Thank you. From owner-linux-xfs@oss.sgi.com Mon Sep 16 05:50:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 05:50:56 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GCortG026789 for ; Mon, 16 Sep 2002 05:50:54 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA28196; Mon, 16 Sep 2002 07:55:42 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA44586; Mon, 16 Sep 2002 07:55:41 -0500 (CDT) Date: Mon, 16 Sep 2002 07:50:53 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Frasenyak Dmitrij cc: linux-xfs@oss.sgi.com Subject: Re: Need information about XFS tests In-Reply-To: <3D85C8D5.6030901@rtsoft.msk.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 397 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs There is no comprehensive documentation, I'm afraid. Do you have a specific question? -Eric On Mon, 16 Sep 2002, Frasenyak Dmitrij wrote: > Hello > I'm looking for any documentation about XFS tests included in CVS tree. > I've searched over sgi site and Internet but found only small remarks > in the headers of scripts. > > Thank you. > > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 16 07:41:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 07:41:58 -0700 (PDT) Received: from rtsoft.rtsoft.msk.ru (Rtsoft-MTUInform-GW.mtu.ru [195.34.37.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GEfotG032634 for ; Mon, 16 Sep 2002 07:41:51 -0700 Received: from mail by rtsoft.rtsoft.msk.ru with local (Exim 3.12 #1 (Debian)) id 17qx9A-0005bA-00; Mon, 16 Sep 2002 18:46:44 +0400 Received: from [192.168.100.40] (helo=develop.dev.rtsoft.msk.ru) by rtsoft.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17qx99-0005b1-00 for ; Mon, 16 Sep 2002 18:46:43 +0400 Received: from becha.dev.rtsoft.msk.ru ([192.168.100.169] helo=rtsoft.msk.ru) by develop.dev.rtsoft.msk.ru with esmtp (Exim 3.12 #1 (Debian)) id 17qx97-0002kY-00 for ; Mon, 16 Sep 2002 18:46:41 +0400 Message-ID: <3D85F3F2.7060407@rtsoft.msk.ru> Date: Mon, 16 Sep 2002 19:08:34 +0400 From: Frasenyak Dmitrij User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011031 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re[2]: Need information about XFS tests References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-KAV: KavKeeper passed X-archive-position: 398 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sed@rtsoft.msk.ru Precedence: bulk X-list: linux-xfs Yes 1 Do tests (placed in CVS tree) check all XFS/Linux functionality ? 2 Do i need SMP to build test environment ? 3 How can i obtain read access to bug-track system ? For example: i want to know what do the test N003 do but the only information available ( from xfscvs/linux-2.4-xfs/cmd/xfstests/003 ): ... # XFS QA Test No. 003 # $Id: 1.1 $ # # exercise xfs_db bug #784078 ... Thank you. Dmitrij. Eric Sandeen wrote: > There is no comprehensive documentation, I'm afraid. Do you have a specific > question? > > -Eric > > On Mon, 16 Sep 2002, Frasenyak Dmitrij wrote: > > >>Hello >>I'm looking for any documentation about XFS tests included in CVS tree. >>I've searched over sgi site and Internet but found only small remarks >>in the headers of scripts. >> >> Thank you. >> >> >> >> >> >> > > > > From owner-linux-xfs@oss.sgi.com Mon Sep 16 07:50:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 07:50:07 -0700 (PDT) Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GEo3tG000710 for ; Mon, 16 Sep 2002 07:50:03 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA04927; Mon, 16 Sep 2002 09:54:52 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 17qxH2-0004fk-00; Mon, 16 Sep 2002 09:54:52 -0500 Date: Mon, 16 Sep 2002 09:54:52 -0500 From: Nathan Straz To: Frasenyak Dmitrij Cc: linux-xfs@oss.sgi.com Subject: Re: Need information about XFS tests Message-ID: <20020916145452.GA16333@sgi.com> Mail-Followup-To: Frasenyak Dmitrij , linux-xfs@oss.sgi.com References: <3D85F3F2.7060407@rtsoft.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D85F3F2.7060407@rtsoft.msk.ru> User-Agent: Mutt/1.4i X-archive-position: 399 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 07:08:34PM +0400, Frasenyak Dmitrij wrote: > Yes > 1 Do tests (placed in CVS tree) check all XFS/Linux functionality ? No, they target a subset of XFS specific functionality. > 2 Do i need SMP to build test environment ? No. > 3 How can i obtain read access to bug-track system ? > For example: i want to know what do the test N003 do but the > only information available ( from > xfscvs/linux-2.4-xfs/cmd/xfstests/003 ): > > ... > # XFS QA Test No. 003 > # $Id: 1.1 $ > # > # exercise xfs_db bug #784078 > ... I don't think that's likely. 784078 was a bug in relation to xfs_db core dumping with certain combinations of commands. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Sep 16 08:03:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 08:03:50 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GF3ktG001339 for ; Mon, 16 Sep 2002 08:03:46 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8GF8eq18539 for ; Mon, 16 Sep 2002 11:08:40 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8GF8eH18533 for ; Mon, 16 Sep 2002 11:08:40 -0400 Date: Mon, 16 Sep 2002 11:08:40 -0400 (EDT) From: Benito Venegas To: Subject: kernel src to compile In-Reply-To: <200209131823.g8DINgZ25682@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 400 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Good morning team: (bad morning for me, but I hope you have better than mine) I have a problem in one of my servers. Kernel Panic, only I have latest line, due Kernel Panic debug message was too big for my console (nfs_ related problem I think) grrrrrr..I ate don;t have good logs.... Does any of you guys have a kernel-2.4.18 or higher version in format src.rpm ready to compile? or at least > 2.4.9-31 that I am using today. Usually I do by myself, but I have to fix other issues in other server. I would appreciate your help team. Thanks Notes: Pe2450 1 CPU; current kernel 2.4.9-31SGI_XFS;nfs client only; a lot of I/O through NFS. Perc card (aacraid.o), Intel pro 1000 (e1000.o). Other servers don't have this problem :/ Seth, Jason?? Thanks again Vene.- From owner-linux-xfs@oss.sgi.com Mon Sep 16 08:32:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 08:32:36 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GFWVtG002776 for ; Mon, 16 Sep 2002 08:32:32 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA45259; Mon, 16 Sep 2002 10:37:21 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-13.corp.sgi.com [134.15.64.13]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id KAA35373; Mon, 16 Sep 2002 10:37:20 -0500 (CDT) Subject: RE: Re-occurance of NFS server panics From: Stephen Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 10:35:43 -0500 Message-Id: <1032190545.1051.80.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 401 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-16 at 09:52, Ian D. Hardy wrote: > Steve +, > > Sorry to bother you again. You may remember that we've corresponded > several times over the past ~9months with regards to kernel memory > allocation problems and fragmented files (see bellow). > > We had a period of relative stability, however the last few weeks we > have gone back to a situation of having one or more crashes/hangs every > week and are now having to again review our continued use of XFS. > Therefore any update on progress towards a fix for these problems would > be very useful (I'd hate to go though the pain of converting our ~1Tbyte > filesystem to Reiser of ext3 if there are fixes immanent). > > We have been running a 2.4.18 XFS CVS kernel from Mid May for some time > now, I'm just in the process of compiling and testing the current 2.4.19 > XFS CVS, is this likely to help? (looking through the list archive I > can't find anything of direct relevance but may have missed something). > > We appear to be running at a lower overall system fragmentation level > now (currently 13% in the past it has been 28% or more), though I guess > it is possible for only a couple of large very fragmented files to > result in kernel memory allocation problems and still have reasonably > low overall FS fragmentation levels? > > Unfortunately the NFS load on our server is such that it is > difficult/impossible to predict times of light NFS load in which to run > fsr and as reported before we've had several incidents of filesystem > corruption and the kernel taking the FS offline running fsr under a NFS > load. > > Thanks for your time (BTW: We've persevered with XFS for so long as it > seems to give better performance for our workload than ext3 or ReiserFS, > however, stability is again becoming a problem). > Nothing immediately rings a bell, there have been some recent changes which fixed some hangs HP was having in doing large scale NFS benchmarking. These might be beneficial to you. The last oops output I have from you looked like this: >>EIP; c012ff76 <===== Trace; c01fd146 Trace; c01fd1a4 Trace; c01d04f0 Trace; c01a6996 Trace; c01a5f12 Trace; c01d6474 Trace; c01fd2e0 Trace; c01aac14 Trace; c01cf962 Trace; c01e6e22 Trace; c01e6340 Trace; c026cf44 Trace; c01f696e Trace; c01e6340 Trace; c014f45c Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> Trace; f8d2b348 <[nfsd]nfsd+1b8/370> Trace; c01057ea Code; c012ff76 00000000 <_EIP>: Code; c012ff76 <===== 0: 0f 0b ud2a <===== Code; c012ff78 2: 83 c4 08 add $0x8,%esp Code; c012ff7a 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx Code; c012ff80 b: 8b 2c 1a mov (%edx,%ebx,1),%ebp Code; c012ff84 e: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c012ff88 12: b8 00 00 00 00 mov $0x0,%eax Is this still what you see? This one does bear the symptoms of a problem which was fixed a while ago - memory was freed into the wrong pool. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 16 08:59:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 08:59:28 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GFxLtG003687 for ; Mon, 16 Sep 2002 08:59:21 -0700 Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8GG44jv058354; Mon, 16 Sep 2002 12:04:04 -0400 Received: from nighthawk.sr71.net (sig-9-65-11-88.mts.ibm.com [9.65.11.88]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8GG41c0037022; Mon, 16 Sep 2002 10:04:01 -0600 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g8GG3iS00553; Mon, 16 Sep 2002 09:03:44 -0700 Message-ID: <3D8600DD.1010707@us.ibm.com> Date: Mon, 16 Sep 2002 09:03:41 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Samuel Flory , Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> X-Enigmail-Version: 0.65.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig55ED74C752FF075D8DF4EEE1" X-archive-position: 402 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: linux-xfs This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig55ED74C752FF075D8DF4EEE1 Content-Type: multipart/mixed; boundary="------------010502070400000809040600" This is a multi-part message in MIME format. --------------010502070400000809040600 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Andrea Arcangeli wrote: > On Thu, Sep 12, 2002 at 07:14:14PM -0700, Samuel Flory wrote: > >>Andrea Arcangeli wrote: >> >>>On Thu, Sep 12, 2002 at 07:47:48PM -0500, Stephen Lord wrote: >>> >>>>How much memory is in the machine by the way? And Andrea, is the >>>>vmalloc space size reduced in the 3G user space configuration? >>> >>>it's not reduced, it's the usual 128m. >>> >>>BTW, I forgot to say that to really take advantage of CONFIG_2G one >>>should increase __VMALLOC_RESERVE too, it's not directly in function of >>>the CONFIG_2G. >>> >> >>So how much do you recommend increasing it? Currently it's: >>include/asm-i386/page.h:#define __VMALLOC_RESERVE (128 << 20) >>include/asm/page.h:#define __VMALLOC_RESERVE (128 << 20) > > > you can try to compile with CONFIG_3G and to set __VMALLOC_RESERVE to > (512 << 20) and see if it helps. If it only happens a bit later then > it's most probably an address space leak, should be easy to track down > some debugging instrumentation. I just produced this little patch for 2.5. It should provide a bit of the extra information that you were looking for. It adds some entries to /proc/meminfo that look like this: VMalTotal: 92123 kB VmalUsed: 1264 kB VMalChunk: 80315 kB Total available, total used, and largest chunk available. It is simple enough that a backport shouldn't be any problem at all. Anybody interested? -- Dave Hansen haveblue@us.ibm.com --------------010502070400000809040600 Content-Type: text/plain; name="vmalloc-stats-2.5.34-mm4-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vmalloc-stats-2.5.34-mm4-2.patch" diff -ur linux-2.5.34-mm4/fs/proc/proc_misc.c linux-2.5.34-mm4-vmalloc-stats/fs/proc/proc_misc.c --- linux-2.5.34-mm4/fs/proc/proc_misc.c Sat Sep 14 21:23:54 2002 +++ linux-2.5.34-mm4-vmalloc-stats/fs/proc/proc_misc.c Sat Sep 14 22:38:12 2002 @@ -38,6 +38,7 @@ #include #include #include +#include #include #include @@ -128,6 +129,40 @@ return proc_calc_metrics(page, start, off, count, eof, len); } +struct vmalloc_info { + unsigned long used; + unsigned long largest_chunk; +}; + +static struct vmalloc_info get_vmalloc_info(void) +{ + unsigned long prev_end = VMALLOC_START; + struct vm_struct* vma; + struct vmalloc_info vmi; + vmi.used = 0; + + read_lock(&vmlist_lock); + + if(!vmlist) + vmi.largest_chunk = (VMALLOC_END-VMALLOC_START); + else + vmi.largest_chunk = 0; + + for (vma = vmlist; vma; vma = vma->next) { + unsigned long free_area_size = + (unsigned long)vma->addr - prev_end; + vmi.used += vma->size; + if (vmi.largest_chunk < free_area_size ) + vmi.largest_chunk = free_area_size; + prev_end = vma->size + (unsigned long)vma->addr; + } + if(VMALLOC_END-prev_end > vmi.largest_chunk) + vmi.largest_chunk = VMALLOC_END-prev_end; + + read_unlock(&vmlist_lock); + return vmi; +} + extern atomic_t vm_committed_space; static int meminfo_read_proc(char *page, char **start, off_t off, @@ -138,6 +173,8 @@ struct page_state ps; unsigned long inactive; unsigned long active; + unsigned long vmtot; + struct vmalloc_info vmi; get_page_state(&ps); get_zone_counts(&active, &inactive); @@ -150,6 +187,11 @@ si_swapinfo(&i); committed = atomic_read(&vm_committed_space); + vmtot = (VMALLOC_END-VMALLOC_START)>>10; + vmi = get_vmalloc_info(); + vmi.used >>= 10; + vmi.largest_chunk >>= 10; + /* * Tagged format, for easy grepping and expansion. */ @@ -174,7 +216,10 @@ "Slab: %8lu kB\n" "Committed_AS: %8u kB\n" "PageTables: %8lu kB\n" - "ReverseMaps: %8lu\n", + "ReverseMaps: %8lu\n" + "VmalTotal: %8lu kB\n" + "VmalUsed: %8lu kB\n" + "VmalChunk: %8lu kB\n", K(i.totalram), K(i.freeram), K(i.sharedram), @@ -195,7 +240,10 @@ K(ps.nr_slab), K(committed), K(ps.nr_page_table_pages), - ps.nr_reverse_maps + ps.nr_reverse_maps, + vmtot, + vmi.used, + vmi.largest_chunk ); #ifdef CONFIG_HUGETLB_PAGE --------------010502070400000809040600-- --------------enig55ED74C752FF075D8DF4EEE1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9hgDgzEzj1xe3kRwRAnnSAJ9k24P5uAG4Vt4clXIAoJIaXStaJwCfbGOX fYjGEmkIOfEBLzm5wtbktWA= =BQRo -----END PGP SIGNATURE----- --------------enig55ED74C752FF075D8DF4EEE1-- From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:06:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:06:15 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GG6DtG004211 for ; Mon, 16 Sep 2002 09:06:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA43698 for ; Mon, 16 Sep 2002 11:11:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA95115 for ; Mon, 16 Sep 2002 11:11:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8GG7f818454; Mon, 16 Sep 2002 11:07:41 -0500 Message-Id: <200209161607.g8GG7f818454@jen.americas.sgi.com> Date: Mon, 16 Sep 2002 11:07:41 -0500 Subject: TAKE - merge xfs up to 2.5.35 To: linux-xfs@oss.sgi.com X-archive-position: 403 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The xfs part of the change, rest of the kernel comes in the next message. Date: Mon Sep 16 09:10:25 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127481a linux/fs/xfs/linux/xfs_lrw.c - 1.166 linux/fs/xfs/support/time.h - 1.7 linux/fs/xfs/linux/xfs_aops.c - 1.5 From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:13:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:13:25 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGDLtG005063 for ; Mon, 16 Sep 2002 09:13:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA43819 for ; Mon, 16 Sep 2002 11:18:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id LAA43294 for ; Mon, 16 Sep 2002 11:18:10 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8GGEqc18523; Mon, 16 Sep 2002 11:14:52 -0500 Message-Id: <200209161614.g8GGEqc18523@jen.americas.sgi.com> Date: Mon, 16 Sep 2002 11:14:52 -0500 Subject: TAKE - merge xfs up to 2.5.35 To: linux-xfs@oss.sgi.com X-archive-position: 404 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs The rest of the tree Date: Mon Sep 16 09:14:28 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127483a linux/drivers/ide/pci/pdc202xx.c - 1.1 linux/arch/um/os-Linux/tty.c - 1.1 linux/arch/um/ptproxy/Makefile - 1.1 linux/drivers/ide/setup-pci.c - 1.1 linux/drivers/ide/ppc/swarm.c - 1.1 linux/drivers/ide/ppc/pmac.c - 1.1 linux/drivers/ide/ppc/mpc8xx.c - 1.1 linux/drivers/ide/ppc/Makefile - 1.1 linux/include/asm-ppc64/hvcall.h - 1.1 linux/drivers/ide/pci/via82cxxx.h - 1.1 linux/drivers/ide/pci/via82cxxx.c - 1.1 linux/drivers/ide/pci/trm290.h - 1.1 linux/drivers/ide/pci/trm290.c - 1.1 linux/drivers/ide/pci/slc90e66.h - 1.1 linux/drivers/ide/pci/slc90e66.c - 1.1 linux/drivers/ide/pci/sl82c105.h - 1.1 linux/drivers/ide/pci/sl82c105.c - 1.1 linux/drivers/ide/pci/sis5513.h - 1.1 linux/drivers/ide/pci/sis5513.c - 1.1 linux/drivers/ide/pci/siimage.h - 1.1 linux/drivers/ide/pci/siimage.c - 1.1 linux/drivers/ide/pci/serverworks.h - 1.1 linux/drivers/ide/pci/serverworks.c - 1.1 linux/drivers/ide/pci/rz1000.h - 1.1 linux/drivers/ide/pci/rz1000.c - 1.1 linux/drivers/ide/pci/piix.h - 1.1 linux/drivers/ide/pci/piix.c - 1.1 linux/drivers/ide/pci/pdcadma.h - 1.1 linux/drivers/ide/pci/pdcadma.c - 1.1 linux/drivers/ide/pci/pdc202xx_old.h - 1.1 linux/drivers/ide/pci/pdc202xx_old.c - 1.1 linux/drivers/ide/pci/pdc202xx_new.h - 1.1 linux/drivers/ide/pci/pdc202xx_new.c - 1.1 linux/drivers/ide/pci/pdc202xx.h - 1.1 linux/include/asm-ppc64/kmap_types.h - 1.1 linux/drivers/ide/pci/opti621.h - 1.1 linux/drivers/ide/pci/opti621.c - 1.1 linux/drivers/ide/pci/nvidia.h - 1.1 linux/drivers/ide/pci/nvidia.c - 1.1 linux/drivers/ide/pci/ns87415.h - 1.1 linux/drivers/ide/pci/ns87415.c - 1.1 linux/drivers/ide/pci/it8172.h - 1.1 linux/drivers/ide/pci/it8172.c - 1.1 linux/drivers/ide/pci/hpt366.h - 1.1 linux/drivers/ide/pci/hpt366.c - 1.1 linux/drivers/ide/pci/hpt34x.h - 1.1 linux/drivers/ide/pci/hpt34x.c - 1.1 linux/drivers/ide/pci/generic.h - 1.1 linux/drivers/ide/pci/generic.c - 1.1 linux/drivers/ide/pci/cy82c693.h - 1.1 linux/drivers/ide/pci/cy82c693.c - 1.1 linux/drivers/ide/pci/cs5530.h - 1.1 linux/drivers/ide/pci/cs5530.c - 1.1 linux/drivers/ide/pci/cmd64x.h - 1.1 linux/drivers/ide/pci/cmd64x.c - 1.1 linux/include/asm-um/vga.h - 1.1 linux/include/asm-um/user.h - 1.1 linux/include/asm-um/unistd.h - 1.1 linux/include/asm-um/unaligned.h - 1.1 linux/include/asm-um/uaccess.h - 1.1 linux/include/asm-um/types.h - 1.1 linux/include/asm-um/tlbflush.h - 1.1 linux/include/asm-um/tlb.h - 1.1 linux/include/asm-um/timex.h - 1.1 linux/include/asm-um/thread_info.h - 1.1 linux/include/asm-um/termios.h - 1.1 linux/include/asm-um/termbits.h - 1.1 linux/include/asm-um/system-ppc.h - 1.1 linux/include/asm-um/system-i386.h - 1.1 linux/include/asm-um/system-generic.h - 1.1 linux/include/asm-um/suspend.h - 1.1 linux/include/asm-um/string.h - 1.1 linux/include/asm-um/statfs.h - 1.1 linux/include/asm-um/stat.h - 1.1 linux/include/asm-um/spinlock.h - 1.1 linux/include/asm-um/softirq.h - 1.1 linux/include/asm-um/sockios.h - 1.1 linux/include/asm-um/socket.h - 1.1 linux/include/asm-um/smplock.h - 1.1 linux/include/asm-um/smp.h - 1.1 linux/include/asm-um/signal.h - 1.1 linux/drivers/ide/pci/cmd640.h - 1.1 linux/drivers/ide/pci/cmd640.c - 1.1 linux/drivers/ide/pci/amd74xx.h - 1.1 linux/drivers/ide/pci/amd74xx.c - 1.1 linux/drivers/ide/pci/alim15x3.h - 1.1 linux/drivers/ide/pci/alim15x3.c - 1.1 linux/drivers/ide/pci/aec62xx.h - 1.1 linux/drivers/ide/pci/aec62xx.c - 1.1 linux/drivers/ide/pci/adma100.h - 1.1 linux/drivers/ide/pci/adma100.c - 1.1 linux/drivers/ide/pci/Makefile - 1.1 linux/drivers/ide/legacy/umc8672.c - 1.1 linux/drivers/ide/legacy/qd65xx.h - 1.1 linux/drivers/ide/legacy/qd65xx.c - 1.1 linux/drivers/ide/legacy/q40ide.c - 1.1 linux/drivers/ide/legacy/pdc4030.h - 1.1 linux/drivers/ide/legacy/pdc4030.c - 1.1 linux/drivers/ide/legacy/macide.c - 1.1 linux/drivers/ide/legacy/ide-cs.c - 1.1 linux/drivers/ide/legacy/ht6560b.c - 1.1 linux/drivers/ide/legacy/hd.c - 1.1 linux/drivers/ide/legacy/gayle.c - 1.1 linux/drivers/ide/legacy/falconide.c - 1.1 linux/include/asm-um/siginfo.h - 1.1 linux/include/asm-um/sigcontext-ppc.h - 1.1 linux/drivers/ide/legacy/dtc2278.c - 1.1 linux/drivers/ide/legacy/buddha.c - 1.1 linux/drivers/ide/legacy/ali14xx.c - 1.1 linux/drivers/ide/legacy/Makefile - 1.1 linux/include/asm-um/a.out.h - 1.1 linux/include/asm-um/arch-signal-i386.h - 1.1 linux/include/asm-um/archparam-i386.h - 1.1 linux/include/asm-um/archparam-ppc.h - 1.1 linux/drivers/ide/ide-lib.c - 1.1 linux/arch/um/Makefile - 1.1 linux/arch/um/Makefile-i386 - 1.1 linux/arch/um/Makefile-ia64 - 1.1 linux/arch/um/Makefile-os-Linux - 1.1 linux/arch/um/Makefile-ppc - 1.1 linux/arch/um/boot/Makefile - 1.1 linux/arch/um/config.in - 1.1 linux/arch/um/config.release - 1.1 linux/arch/um/config_block.in - 1.1 linux/arch/um/config_char.in - 1.1 linux/arch/um/config_net.in - 1.1 linux/arch/um/config_scsi.in - 1.1 linux/arch/um/defconfig - 1.1 linux/arch/um/drivers/Makefile - 1.1 linux/arch/um/drivers/chan_kern.c - 1.1 linux/arch/um/drivers/chan_user.c - 1.1 linux/arch/um/drivers/daemon.h - 1.1 linux/arch/um/drivers/daemon_kern.c - 1.1 linux/arch/um/drivers/daemon_kern.h - 1.1 linux/arch/um/drivers/daemon_user.c - 1.1 linux/arch/um/drivers/fd.c - 1.1 linux/arch/um/drivers/harddog_kern.c - 1.1 linux/arch/um/drivers/harddog_user.c - 1.1 linux/arch/um/drivers/hostaudio_kern.c - 1.1 linux/arch/um/drivers/hostaudio_user.c - 1.1 linux/arch/um/drivers/line.c - 1.1 linux/arch/um/drivers/mcast.h - 1.1 linux/arch/um/drivers/mcast_kern.c - 1.1 linux/arch/um/drivers/mcast_kern.h - 1.1 linux/arch/um/drivers/mcast_user.c - 1.1 linux/arch/um/drivers/mconsole_kern.c - 1.1 linux/arch/um/drivers/mconsole_user.c - 1.1 linux/arch/um/drivers/mmapper_kern.c - 1.1 linux/arch/um/drivers/net_kern.c - 1.1 linux/arch/um/drivers/net_user.c - 1.1 linux/arch/um/drivers/null.c - 1.1 linux/arch/um/drivers/port.h - 1.1 linux/arch/um/drivers/port_kern.c - 1.1 linux/arch/um/drivers/port_user.c - 1.1 linux/arch/um/drivers/pty.c - 1.1 linux/arch/um/drivers/slip.h - 1.1 linux/arch/um/drivers/slip_kern.c - 1.1 linux/arch/um/drivers/slip_kern.h - 1.1 linux/arch/um/drivers/slip_user.c - 1.1 linux/arch/um/drivers/ssl.c - 1.1 linux/arch/um/drivers/ssl.h - 1.1 linux/arch/um/drivers/stdio_console.c - 1.1 linux/arch/um/drivers/stdio_console.h - 1.1 linux/arch/um/drivers/tty.c - 1.1 linux/arch/um/drivers/ubd_kern.c - 1.1 linux/arch/um/drivers/ubd_user.c - 1.1 linux/arch/um/drivers/xterm.c - 1.1 linux/arch/um/include/2_5compat.h - 1.1 linux/arch/um/include/Makefile - 1.1 linux/arch/um/include/chan_kern.h - 1.1 linux/arch/um/include/chan_user.h - 1.1 linux/arch/um/include/debug.h - 1.1 linux/arch/um/include/frame.h - 1.1 linux/arch/um/include/frame_kern.h - 1.1 linux/arch/um/include/frame_user.h - 1.1 linux/arch/um/include/helper.h - 1.1 linux/arch/um/include/hostaudio.h - 1.1 linux/arch/um/include/init.h - 1.1 linux/arch/um/include/initrd.h - 1.1 linux/arch/um/include/irq_user.h - 1.1 linux/arch/um/include/kern.h - 1.1 linux/arch/um/include/kern_util.h - 1.1 linux/arch/um/include/line.h - 1.1 linux/arch/um/include/mconsole.h - 1.1 linux/arch/um/include/mconsole_kern.h - 1.1 linux/arch/um/include/mem.h - 1.1 linux/arch/um/include/mem_user.h - 1.1 linux/arch/um/include/net_kern.h - 1.1 linux/arch/um/include/net_user.h - 1.1 linux/arch/um/include/os.h - 1.1 linux/arch/um/include/process.h - 1.1 linux/arch/um/include/ptrace_user.h - 1.1 linux/arch/um/include/sigcontext.h - 1.1 linux/arch/um/include/sigio.h - 1.1 linux/arch/um/include/signal_kern.h - 1.1 linux/arch/um/include/signal_user.h - 1.1 linux/arch/um/include/syscall_user.h - 1.1 linux/arch/um/include/sysdep-i386/frame.h - 1.1 linux/arch/um/include/sysdep-i386/frame_kern.h - 1.1 linux/arch/um/include/sysdep-i386/frame_user.h - 1.1 linux/arch/um/include/sysdep-i386/ptrace.h - 1.1 linux/arch/um/include/sysdep-i386/ptrace_user.h - 1.1 linux/arch/um/include/sysdep-i386/sigcontext.h - 1.1 linux/arch/um/include/sysdep-i386/syscalls.h - 1.1 linux/arch/um/include/sysdep-ia64/ptrace.h - 1.1 linux/arch/um/include/sysdep-ia64/sigcontext.h - 1.1 linux/arch/um/include/sysdep-ia64/syscalls.h - 1.1 linux/arch/um/include/sysdep-ppc/ptrace.h - 1.1 linux/arch/um/include/sysdep-ppc/sigcontext.h - 1.1 linux/arch/um/include/sysdep-ppc/syscalls.h - 1.1 linux/arch/um/include/sysrq.h - 1.1 linux/arch/um/include/tlb.h - 1.1 linux/arch/um/include/ubd_user.h - 1.1 linux/arch/um/include/umid.h - 1.1 linux/arch/um/include/umn.h - 1.1 linux/arch/um/include/user.h - 1.1 linux/arch/um/include/user_util.h - 1.1 linux/arch/um/kernel/Makefile - 1.1 linux/arch/um/kernel/config.c.in - 1.1 linux/arch/um/kernel/exec_kern.c - 1.1 linux/arch/um/kernel/exec_user.c - 1.1 linux/arch/um/kernel/exitcode.c - 1.1 linux/arch/um/kernel/frame.c - 1.1 linux/arch/um/kernel/frame_kern.c - 1.1 linux/arch/um/kernel/gmon_syms.c - 1.1 linux/arch/um/kernel/gprof_syms.c - 1.1 linux/arch/um/kernel/helper.c - 1.1 linux/arch/um/kernel/init_task.c - 1.1 linux/arch/um/kernel/initrd_kern.c - 1.1 linux/arch/um/kernel/initrd_user.c - 1.1 linux/arch/um/kernel/irq.c - 1.1 linux/arch/um/kernel/irq_user.c - 1.1 linux/arch/um/kernel/ksyms.c - 1.1 linux/arch/um/kernel/mem.c - 1.1 linux/arch/um/kernel/mem_user.c - 1.1 linux/arch/um/kernel/mprot.h - 1.1 linux/arch/um/kernel/process.c - 1.1 linux/arch/um/kernel/process_kern.c - 1.1 linux/arch/um/kernel/ptrace.c - 1.1 linux/arch/um/kernel/reboot.c - 1.1 linux/arch/um/kernel/resource.c - 1.1 linux/arch/um/kernel/setup.c - 1.1 linux/arch/um/kernel/sigio_kern.c - 1.1 linux/arch/um/kernel/sigio_user.c - 1.1 linux/arch/um/kernel/signal_kern.c - 1.1 linux/arch/um/kernel/signal_user.c - 1.1 linux/arch/um/kernel/smp.c - 1.1 linux/arch/um/kernel/sys_call_table.c - 1.1 linux/arch/um/kernel/syscall_kern.c - 1.1 linux/arch/um/kernel/syscall_user.c - 1.1 linux/arch/um/kernel/sysrq.c - 1.1 linux/arch/um/kernel/time.c - 1.1 linux/arch/um/kernel/time_kern.c - 1.1 linux/arch/um/kernel/tlb.c - 1.1 linux/arch/um/kernel/trap_kern.c - 1.1 linux/arch/um/kernel/trap_user.c - 1.1 linux/arch/um/kernel/tty_log.c - 1.1 linux/arch/um/kernel/uaccess_user.c - 1.1 linux/arch/um/kernel/um_arch.c - 1.1 linux/arch/um/kernel/umid.c - 1.1 linux/arch/um/kernel/unmap.c - 1.1 linux/arch/um/kernel/user_syms.c - 1.1 linux/arch/um/kernel/user_util.c - 1.1 linux/arch/um/link.ld.in - 1.1 linux/arch/um/main.c - 1.1 linux/arch/um/os-Linux/Makefile - 1.1 linux/arch/um/os-Linux/drivers/Makefile - 1.1 linux/arch/um/os-Linux/drivers/etap.h - 1.1 linux/arch/um/os-Linux/drivers/etap_kern.h - 1.1 linux/arch/um/os-Linux/drivers/ethertap_kern.c - 1.1 linux/arch/um/os-Linux/drivers/ethertap_user.c - 1.1 linux/arch/um/os-Linux/drivers/tuntap.h - 1.1 linux/arch/um/os-Linux/drivers/tuntap_kern.c - 1.1 linux/arch/um/os-Linux/drivers/tuntap_kern.h - 1.1 linux/arch/um/os-Linux/drivers/tuntap_user.c - 1.1 linux/arch/um/os-Linux/file.c - 1.1 linux/arch/um/os-Linux/include/file.h - 1.1 linux/arch/um/os-Linux/process.c - 1.1 linux/arch/um/sys-i386/ksyms.c - 1.1 linux/drivers/ide/ide-iops.c - 1.1 linux/arch/um/ptproxy/proxy.c - 1.1 linux/arch/um/ptproxy/ptproxy.h - 1.1 linux/arch/um/ptproxy/ptrace.c - 1.1 linux/arch/um/ptproxy/sysdep.c - 1.1 linux/arch/um/ptproxy/sysdep.h - 1.1 linux/arch/um/ptproxy/wait.c - 1.1 linux/arch/um/ptproxy/wait.h - 1.1 linux/arch/um/sys-i386/Makefile - 1.1 linux/arch/um/sys-i386/bugs.c - 1.1 linux/arch/um/sys-i386/fault.c - 1.1 linux/include/asm-um/pgtable.h - 1.1 linux/arch/um/sys-i386/ldt.c - 1.1 linux/arch/um/sys-i386/ptrace.c - 1.1 linux/arch/um/sys-i386/ptrace_user.c - 1.1 linux/arch/um/sys-i386/sigcontext.c - 1.1 linux/arch/um/sys-i386/syscalls.c - 1.1 linux/arch/um/sys-i386/sysrq.c - 1.1 linux/arch/um/sys-i386/util/Makefile - 1.1 linux/arch/um/sys-i386/util/mk_sc.c - 1.1 linux/arch/um/sys-i386/util/mk_thread_kern.c - 1.1 linux/arch/um/sys-i386/util/mk_thread_user.c - 1.1 linux/arch/um/sys-ia64/Makefile - 1.1 linux/arch/um/sys-ppc/Makefile - 1.1 linux/arch/um/sys-ppc/misc.S - 1.1 linux/arch/um/sys-ppc/miscthings.c - 1.1 linux/arch/um/sys-ppc/ptrace.c - 1.1 linux/arch/um/sys-ppc/ptrace_user.c - 1.1 linux/arch/um/sys-ppc/sigcontext.c - 1.1 linux/arch/um/sys-ppc/sysrq.c - 1.1 linux/arch/um/util/Makefile - 1.1 linux/arch/um/util/mk_task_kern.c - 1.1 linux/arch/um/util/mk_task_user.c - 1.1 linux/include/asm-um/sigcontext-i386.h - 1.1 linux/include/asm-um/sigcontext-generic.h - 1.1 linux/include/asm-um/shmparam.h - 1.1 linux/include/asm-um/shmbuf.h - 1.1 linux/include/asm-um/serial.h - 1.1 linux/include/asm-um/sembuf.h - 1.1 linux/include/asm-um/semaphore.h - 1.1 linux/include/asm-um/segment.h - 1.1 linux/include/asm-um/scatterlist.h - 1.1 linux/include/asm-um/rwsem.h - 1.1 linux/include/asm-um/rwlock.h - 1.1 linux/include/asm-um/rmap.h - 1.1 linux/include/asm-um/resource.h - 1.1 linux/include/asm-um/ptrace-i386.h - 1.1 linux/include/asm-um/ptrace-generic.h - 1.1 linux/include/asm-um/processor-ppc.h - 1.1 linux/include/asm-um/processor-i386.h - 1.1 linux/include/asm-um/processor-generic.h - 1.1 linux/include/asm-um/posix_types.h - 1.1 linux/include/asm-um/poll.h - 1.1 linux/include/asm-um/bitops.h - 1.1 linux/include/asm-um/pgalloc.h - 1.1 linux/include/asm-um/percpu.h - 1.1 linux/include/asm-um/pci.h - 1.1 linux/include/asm-um/param.h - 1.1 linux/include/asm-um/atomic.h - 1.1 linux/include/asm-um/locks.h - 1.1 linux/include/asm-um/boot.h - 1.1 linux/include/asm-um/page_offset.h - 1.1 linux/include/asm-um/bugs.h - 1.1 linux/include/asm-um/byteorder.h - 1.1 linux/include/asm-um/page.h - 1.1 linux/include/asm-um/cache.h - 1.1 linux/include/asm-um/cacheflush.h - 1.1 linux/include/asm-um/checksum.h - 1.1 linux/include/asm-um/namei.h - 1.1 linux/include/asm-um/cobalt.h - 1.1 linux/include/asm-um/current.h - 1.1 linux/include/asm-um/mtrr.h - 1.1 linux/include/asm-um/msgbuf.h - 1.1 linux/include/asm-um/delay.h - 1.1 linux/include/asm-um/module.h - 1.1 linux/include/asm-um/desc.h - 1.1 linux/include/asm-um/mmu_context.h - 1.1 linux/include/asm-um/mmu.h - 1.1 linux/include/asm-um/mman.h - 1.1 linux/include/asm-um/mca_dma.h - 1.1 linux/include/asm-um/kmap_types.h - 1.1 linux/include/asm-um/linux_logo.h - 1.1 linux/include/asm-um/linkage.h - 1.1 linux/include/asm-um/hw_irq.h - 1.1 linux/include/asm-um/keyboard.h - 1.1 linux/include/asm-um/irq_vectors.h - 1.1 linux/include/asm-um/irq.h - 1.1 linux/include/asm-um/ipcbuf.h - 1.1 linux/include/asm-um/ipc.h - 1.1 linux/include/asm-um/ioctls.h - 1.1 linux/include/asm-um/ioctl.h - 1.1 linux/include/asm-um/io.h - 1.1 linux/include/asm-um/init.h - 1.1 linux/include/asm-um/ide.h - 1.1 linux/include/asm-um/highmem.h - 1.1 linux/include/asm-um/div64.h - 1.1 linux/drivers/ide/arm/Makefile - 1.1 linux/drivers/ide/arm/icside.c - 1.1 linux/drivers/ide/arm/rapide.c - 1.1 linux/include/asm-um/hdreg.h - 1.1 linux/include/asm-um/hardirq.h - 1.1 linux/include/asm-um/floppy.h - 1.1 linux/include/asm-um/fcntl.h - 1.1 linux/include/asm-um/errno.h - 1.1 linux/include/asm-um/elf.h - 1.1 linux/include/asm-um/dma.h - 1.1 linux/net/ipv4/tcp_input.c - 1.41 linux/net/ipv4/ip_options.c - 1.7 linux/net/core/dev.c - 1.59 linux/net/802/psnap.c - 1.9 linux/net/802/p8022.c - 1.10 linux/mm/vmscan.c - 1.111 linux/mm/swap_state.c - 1.48 linux/mm/swap.c - 1.25 linux/mm/page_alloc.c - 1.90 linux/mm/filemap.c - 1.133 linux/kernel/time.c - 1.12 linux/kernel/sys.c - 1.39 linux/kernel/softirq.c - 1.29 linux/kernel/signal.c - 1.40 linux/kernel/sched.c - 1.81 linux/kernel/ksyms.c - 1.163 linux/kernel/fork.c - 1.69 linux/kernel/exit.c - 1.53 linux/kernel/capability.c - 1.10 linux/ipc/shm.c - 1.57 linux/init/main.c - 1.90 linux/include/linux/uio.h - 1.3 linux/include/linux/timex.h - 1.6 linux/include/linux/time.h - 1.8 linux/include/linux/serial.h - 1.16 linux/include/linux/sched.h - 1.82 linux/include/linux/pci.h - 1.64 linux/include/linux/nfsd/nfsfh.h - 1.14 linux/include/linux/nfsd/export.h - 1.14 linux/include/linux/nfsd/auth.h - 1.3 linux/include/linux/mm.h - 1.99 linux/include/linux/lockd/xdr.h - 1.6 linux/include/linux/lockd/sm_inter.h - 1.3 linux/include/linux/lockd/lockd.h - 1.8 linux/include/linux/lockd/bind.h - 1.4 linux/include/linux/hdreg.h - 1.27 linux/include/linux/fs.h - 1.190 linux/include/linux/blkdev.h - 1.67 linux/include/linux/atari_rootsec.h - 1.3 linux/include/asm-sparc64/unistd.h - 1.24 linux/include/asm-sparc64/spinlock.h - 1.13 linux/include/asm-sparc64/pgtable.h - 1.38 linux/include/asm-sparc64/ide.h - 1.17 linux/include/asm-sparc64/hardirq.h - 1.18 linux/include/asm-sparc/unistd.h - 1.22 linux/include/asm-sparc/system.h - 1.14 linux/include/asm-sparc/spinlock.h - 1.11 linux/include/asm-sparc/pgtable.h - 1.29 linux/include/asm-sparc/irq.h - 1.9 linux/include/asm-sparc/hardirq.h - 1.15 linux/include/asm-ppc/unistd.h - 1.25 linux/include/asm-ppc/spinlock.h - 1.16 linux/include/asm-ppc/pgtable.h - 1.38 linux/include/asm-ppc/ide.h - 1.21 linux/include/asm-ppc/atomic.h - 1.11 linux/include/asm-mips/pgtable.h - 1.19 linux/include/asm-m68k/pgtable.h - 1.17 linux/include/asm-i386/unistd.h - 1.27 linux/include/asm-i386/pgtable.h - 1.38 linux/include/asm-i386/mtrr.h - 1.6 linux/include/asm-i386/ide.h - 1.13 linux/include/asm-i386/hardirq.h - 1.22 linux/include/asm-i386/fixmap.h - 1.11 linux/include/asm-arm/pgtable.h - 1.28 linux/include/asm-alpha/system.h - 1.23 linux/include/asm-alpha/signal.h - 1.5 linux/include/asm-alpha/pgtable.h - 1.37 linux/fs/ufs/super.c - 1.35 linux/fs/super.c - 1.92 linux/fs/read_write.c - 1.24 linux/fs/proc/inode.c - 1.25 linux/fs/proc/base.c - 1.42 linux/fs/nfsd/vfs.c - 1.56 linux/fs/nfsd/nfsfh.c - 1.45 linux/fs/nfsd/nfsctl.c - 1.34 linux/fs/nfsd/lockd.c - 1.11 linux/fs/nfsd/export.c - 1.40 linux/fs/nfs/symlink.c - 1.18 linux/fs/nfs/proc.c - 1.16 linux/fs/nfs/nfs3xdr.c - 1.14 linux/fs/nfs/nfs2xdr.c - 1.17 linux/fs/nfs/mount_clnt.c - 1.8 linux/fs/nfs/inode.c - 1.52 linux/fs/nfs/file.c - 1.35 linux/fs/nfs/dir.c - 1.44 linux/fs/locks.c - 1.32 linux/fs/lockd/xdr.c - 1.15 linux/fs/lockd/svcsubs.c - 1.10 linux/fs/lockd/svcproc.c - 1.13 linux/fs/lockd/svclock.c - 1.16 linux/fs/lockd/svc.c - 1.20 linux/fs/lockd/mon.c - 1.11 linux/fs/lockd/lockd_syms.c - 1.7 linux/fs/lockd/host.c - 1.9 linux/fs/lockd/clntlock.c - 1.13 linux/fs/inode.c - 1.81 linux/fs/fcntl.c - 1.25 linux/fs/ext2/inode.c - 1.53 linux/fs/ext2/file.c - 1.22 linux/fs/exec.c - 1.64 linux/fs/buffer.c - 1.133 linux/fs/block_dev.c - 1.58 linux/drivers/scsi/ide-scsi.c - 1.45 linux/drivers/pci/proc.c - 1.29 linux/drivers/pci/pci.c - 1.61 linux/drivers/pci/Makefile - 1.24 linux/drivers/net/ni65.c - 1.16 linux/drivers/net/hamradio/scc.c - 1.26 linux/drivers/net/de600.c - 1.18 linux/drivers/net/at1700.c - 1.20 linux/drivers/net/apne.c - 1.11 linux/drivers/net/3c505.c - 1.28 linux/drivers/char/tty_io.c - 1.51 linux/drivers/char/sysrq.c - 1.28 linux/drivers/char/lp.c - 1.34 linux/drivers/char/keyboard.c - 1.28 linux/drivers/char/ftape/zftape/zftape_syms.c - 1.4 linux/drivers/char/ftape/lowlevel/ftape_syms.c - 1.4 linux/drivers/char/ftape/lowlevel/Makefile - 1.6 linux/drivers/char/Makefile - 1.72 linux/drivers/char/Config.in - 1.66 linux/drivers/cdrom/cdrom.c - 1.46 linux/drivers/block/ll_rw_blk.c - 1.112 linux/drivers/block/floppy.c - 1.48 linux/arch/sparc64/prom/misc.c - 1.14 linux/arch/sparc64/mm/init.c - 1.49 linux/arch/sparc64/kernel/time.c - 1.23 linux/arch/sparc64/kernel/systbls.S - 1.32 linux/arch/sparc64/kernel/sys_sparc32.c - 1.56 linux/arch/sparc64/kernel/signal32.c - 1.26 linux/arch/sparc64/kernel/signal.c - 1.24 linux/arch/sparc64/kernel/setup.c - 1.34 linux/arch/sparc64/kernel/process.c - 1.41 linux/arch/sparc64/kernel/init_task.c - 1.9 linux/arch/sparc64/kernel/entry.S - 1.27 linux/arch/sparc64/defconfig - 1.75 linux/arch/sparc/prom/misc.c - 1.5 linux/arch/sparc/mm/sun4c.c - 1.37 linux/arch/sparc/mm/srmmu.c - 1.37 linux/arch/sparc/kernel/unaligned.c - 1.8 linux/arch/sparc/kernel/time.c - 1.19 linux/arch/sparc/kernel/tick14.c - 1.3 linux/arch/sparc/kernel/tadpole.c - 1.4 linux/arch/sparc/kernel/systbls.S - 1.26 linux/arch/sparc/kernel/sparc-stub.c - 1.10 linux/arch/sparc/kernel/signal.c - 1.27 linux/arch/sparc/kernel/setup.c - 1.25 linux/arch/sparc/kernel/process.c - 1.31 linux/arch/sparc/kernel/pcic.c - 1.23 linux/arch/sparc/kernel/init_task.c - 1.8 linux/arch/sparc/kernel/entry.S - 1.14 linux/arch/sparc/kernel/ebus.c - 1.15 linux/arch/sparc/kernel/check_asm.sh - 1.7 linux/arch/sparc/kernel/Makefile - 1.17 linux/arch/sparc/defconfig - 1.34 linux/arch/sparc/config.in - 1.43 linux/arch/ppc/kernel/time.c - 1.21 linux/arch/ppc/kernel/setup.c - 1.50 linux/arch/ppc/kernel/process.c - 1.42 linux/arch/ppc/kernel/pci.c - 1.29 linux/arch/ppc/kernel/misc.S - 1.46 linux/arch/ppc/kernel/irq.c - 1.39 linux/arch/i386/kernel/vm86.c - 1.17 linux/arch/i386/kernel/time.c - 1.25 linux/arch/i386/kernel/io_apic.c - 1.44 linux/arch/i386/kernel/entry.S - 1.62 linux/arch/i386/config.in - 1.89 linux/arch/alpha/kernel/signal.c - 1.18 linux/arch/alpha/Makefile - 1.19 linux/Rules.make - 1.30 linux/Makefile - 1.216 linux/CREDITS - 1.87 linux/include/linux/ide.h - 1.62 linux/include/asm-ppc/hdreg.h - 1.3 linux/include/asm-i386/hdreg.h - 1.2 linux/include/asm-arm/hdreg.h - 1.3 linux/include/asm-alpha/hdreg.h - 1.2 linux/drivers/char/dz.c - 1.16 linux/drivers/char/raw.c - 1.28 linux/include/asm-i386/apic.h - 1.18 linux/fs/partitions/check.c - 1.51 linux/arch/alpha/kernel/pci.c - 1.23 linux/arch/sparc64/kernel/power.c - 1.10 linux/arch/sparc64/kernel/pci.c - 1.30 linux/arch/sh/Makefile - 1.12 linux/include/asm-sh/pgtable.h - 1.26 linux/include/asm-i386/kmap_types.h - 1.11 linux/fs/udf/udfdecl.h - 1.21 linux/include/linux/acpi.h - 1.28 linux/arch/i386/kernel/smpboot.c - 1.46 linux/include/linux/pci_ids.h - 1.73 linux/drivers/net/pcmcia/3c574_cs.c - 1.20 linux/drivers/net/pcmcia/fmvj18x_cs.c - 1.17 linux/drivers/net/pcmcia/smc91c92_cs.c - 1.16 linux/include/linux/highmem.h - 1.26 linux/include/asm-sh/hdreg.h - 1.3 linux/include/asm-i386/highmem.h - 1.14 linux/drivers/pci/pci.ids - 1.52 linux/drivers/net/pcmcia/aironet4500_cs.c - 1.14 linux/kernel/timer.c - 1.29 linux/arch/i386/kernel/acpi.c - 1.29 linux/drivers/net/arcnet/arcnet.c - 1.13 linux/include/asm-sparc/ide.h - 1.14 linux/arch/ia64/Makefile - 1.18 linux/include/asm-ia64/pgtable.h - 1.19 linux/fs/lockd/xdr4.c - 1.10 linux/fs/lockd/svc4proc.c - 1.9 linux/include/asm-mips64/pgtable.h - 1.15 linux/arch/mips64/Makefile - 1.12 linux/drivers/ide/via82cxxx.c - 1.34 linux/drivers/ide/umc8672.c - 1.10 linux/drivers/ide/trm290.c - 1.17 linux/drivers/ide/sl82c105.c - 1.17 linux/drivers/ide/sis5513.c - 1.25 linux/drivers/ide/rz1000.c - 1.11 linux/drivers/ide/rapide.c - 1.9 linux/drivers/ide/q40ide.c - 1.8 linux/drivers/ide/piix.c - 1.30 linux/drivers/ide/pdc4030.h - 1.3 linux/drivers/ide/pdc4030.c - 1.22 linux/drivers/ide/pdc202xx.c - 1.28 linux/drivers/ide/opti621.c - 1.16 linux/drivers/ide/ns87415.c - 1.15 linux/drivers/ide/macide.c - 1.7 linux/drivers/ide/ide_modes.h - 1.8 linux/drivers/ide/ide.c - 1.65 linux/drivers/ide/ide-tape.c - 1.36 linux/drivers/ide/ide-proc.c - 1.22 linux/drivers/ide/ide-probe.c - 1.36 linux/drivers/ide/ide-pnp.c - 1.10 linux/drivers/ide/ide-pmac.c - 1.22 linux/drivers/ide/ide-pci.c - 1.34 linux/drivers/ide/ide-geometry.c - 1.17 linux/drivers/ide/ide-floppy.c - 1.35 linux/drivers/ide/ide-dma.c - 1.29 linux/drivers/ide/ide-disk.c - 1.47 linux/drivers/ide/ide-cs.c - 1.13 linux/drivers/ide/ide-cd.c - 1.47 linux/drivers/ide/icside.c - 1.23 linux/drivers/ide/ht6560b.c - 1.14 linux/drivers/ide/hpt366.c - 1.25 linux/drivers/ide/hpt34x.c - 1.19 linux/drivers/ide/hd.c - 1.29 linux/drivers/ide/gayle.c - 1.10 linux/drivers/ide/falconide.c - 1.8 linux/drivers/ide/dtc2278.c - 1.12 linux/drivers/ide/cy82c693.c - 1.17 linux/drivers/ide/cs5530.c - 1.16 linux/drivers/ide/cmd64x.c - 1.21 linux/drivers/ide/cmd640.c - 1.15 linux/drivers/ide/buddha.c - 1.13 linux/drivers/ide/alim15x3.c - 1.22 linux/drivers/ide/ali14xx.c - 1.14 linux/drivers/ide/Makefile - 1.28 linux/drivers/ide/Config.in - 1.32 linux/Documentation/DocBook/kernel-api.tmpl - 1.22 linux/net/ipv4/netfilter/ipt_owner.c - 1.8 linux/fs/ramfs/inode.c - 1.30 linux/fs/nfs/nfs3proc.c - 1.14 linux/drivers/ide/aec62xx.c - 1.15 linux/drivers/s390/net/iucv.h - 1.5 linux/include/asm-s390/pgtable.h - 1.15 linux/drivers/usb/storage/usb.h - 1.16 linux/drivers/usb/storage/usb.c - 1.28 linux/drivers/usb/storage/transport.c - 1.26 linux/drivers/usb/storage/protocol.c - 1.10 linux/drivers/acpi/include/acpiosxf.h - 1.11 linux/include/asm-sparc/kmap_types.h - 1.9 linux/include/asm-sparc/highmem.h - 1.7 linux/drivers/input/input.c - 1.14 linux/drivers/md/raid5.c - 1.33 linux/drivers/char/toshiba.c - 1.5 linux/drivers/md/md.c - 1.54 linux/include/asm-ppc/highmem.h - 1.10 linux/drivers/ide/slc90e66.c - 1.11 linux/mm/oom_kill.c - 1.17 linux/drivers/usb/serial/belkin_sa.c - 1.23 linux/drivers/usb/serial/belkin_sa.h - 1.5 linux/include/asm-parisc/hdreg.h - 1.2 linux/include/asm-parisc/pgtable.h - 1.6 linux/mm/shmem.c - 1.45 linux/drivers/acpi/acpi_ksyms.c - 1.10 linux/drivers/usb/storage/unusual_devs.h - 1.12 linux/include/asm-s390x/pgtable.h - 1.11 linux/include/asm-cris/pgtable.h - 1.11 linux/drivers/acpi/Config.in - 1.8 linux/drivers/acpi/debugger/dbcmds.c - 1.9 linux/drivers/acpi/debugger/dbdisply.c - 1.10 linux/drivers/acpi/debugger/dbexec.c - 1.7 linux/drivers/acpi/debugger/dbfileio.c - 1.10 linux/drivers/acpi/debugger/dbhistry.c - 1.6 linux/drivers/acpi/debugger/dbinput.c - 1.7 linux/drivers/acpi/debugger/dbstats.c - 1.8 linux/drivers/acpi/debugger/dbutils.c - 1.8 linux/drivers/acpi/debugger/dbxface.c - 1.8 linux/drivers/ieee1394/sbp2.c - 1.10 linux/drivers/ide/serverworks.c - 1.17 linux/drivers/ide/it8172.c - 1.14 linux/drivers/ide/ide-adma.c - 1.4 linux/drivers/ide/amd74xx.c - 1.17 linux/arch/ppc/mm/pgtable.c - 1.8 linux/drivers/ide/qd65xx.h - 1.5 linux/drivers/ide/qd65xx.c - 1.13 linux/drivers/char/serial_tx3912.c - 1.6 linux/Documentation/input/ff.txt - 1.3 linux/drivers/md/multipath.c - 1.13 linux/drivers/acpi/kdb/README.txt - 1.2 linux/drivers/acpi/kdb/kdbm_acpi.c - 1.2 linux/drivers/acpi/debugger/Makefile - 1.4 linux/fs/namespace.c - 1.22 linux/drivers/ide/ide-m8xx.c - 1.7 linux/net/ipv6/netfilter/ip6t_owner.c - 1.2 linux/net/8021q/vlan.c - 1.5 linux/fs/ext3/file.c - 1.6 linux/fs/ext3/inode.c - 1.19 linux/drivers/hotplug/pci_hotplug.h - 1.2 linux/drivers/hotplug/cpqphp_proc.c - 1.4 linux/drivers/hotplug/cpqphp_pci.c - 1.5 linux/drivers/hotplug/cpqphp_nvram.c - 1.3 linux/drivers/hotplug/cpqphp_ctrl.c - 1.3 linux/drivers/hotplug/cpqphp_core.c - 1.6 linux/drivers/hotplug/cpqphp.h - 1.2 linux/include/linux/bio.h - 1.13 linux/fs/driverfs/inode.c - 1.21 linux/include/linux/init_task.h - 1.12 linux/drivers/ide/ide-taskfile.c - 1.20 linux/drivers/ide/pdcadma.c - 1.7 linux/drivers/char/Config.help - 1.10 linux/drivers/pnp/pnpbios_core.c - 1.12 linux/drivers/input/serio/serport.c - 1.5 linux/Documentation/filesystems/directory-locking - 1.3 linux/Documentation/filesystems/porting - 1.13 linux/arch/alpha/kernel/init_task.c - 1.2 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.5 linux/sound/pci/cs46xx/cs46xx.c - 1.10 linux/arch/ppc/platforms/pmac_time.c - 1.2 linux/arch/ppc/platforms/prep_pci.c - 1.4 linux/sound/oss/cs46xx.c - 1.4 linux/include/asm-x86_64/pgtable.h - 1.7 linux/include/asm-x86_64/ide.h - 1.6 linux/include/asm-x86_64/hdreg.h - 1.2 linux/include/asm-ppc64/hardirq.h - 1.5 linux/arch/ppc64/mm/fault.c - 1.5 linux/arch/ppc64/mm/init.c - 1.8 linux/include/asm-ppc64/elf.h - 1.3 linux/include/asm-ppc64/eeh.h - 1.3 linux/include/asm-ppc64/delay.h - 1.3 linux/include/asm-ppc64/io.h - 1.3 linux/arch/ppc64/config.in - 1.10 linux/arch/ppc64/defconfig - 1.8 linux/arch/ppc64/kernel/align.c - 1.4 linux/arch/ppc64/kernel/chrp_setup.c - 1.6 linux/arch/ppc64/kernel/eeh.c - 1.4 linux/arch/ppc64/kernel/entry.S - 1.7 linux/arch/ppc64/kernel/head.S - 1.6 linux/arch/ppc64/kernel/iSeries_pci.c - 1.5 linux/arch/ppc64/kernel/iSeries_setup.c - 1.6 linux/arch/ppc64/kernel/idle.c - 1.6 linux/arch/ppc64/kernel/init_task.c - 1.2 linux/arch/ppc64/kernel/ioctl32.c - 1.6 linux/arch/ppc64/kernel/irq.c - 1.6 linux/arch/ppc64/kernel/lmb.c - 1.3 linux/arch/ppc64/kernel/misc.S - 1.7 linux/arch/ppc64/kernel/mk_defs.c - 1.7 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.6 linux/arch/ppc64/kernel/pSeries_pci.c - 1.6 linux/arch/ppc64/kernel/pci.c - 1.5 linux/arch/ppc64/kernel/pci_dma.c - 1.4 linux/arch/ppc64/kernel/pci_dn.c - 1.4 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.7 linux/arch/ppc64/kernel/process.c - 1.7 linux/arch/ppc64/kernel/prom.c - 1.7 linux/arch/ppc64/kernel/ptrace.c - 1.3 linux/arch/ppc64/kernel/ptrace32.c - 1.4 linux/arch/ppc64/kernel/ras.c - 1.2 linux/arch/ppc64/kernel/rtas.c - 1.4 linux/arch/ppc64/kernel/setup.c - 1.7 linux/arch/ppc64/kernel/signal.c - 1.8 linux/arch/ppc64/kernel/smp.c - 1.9 linux/arch/ppc64/kernel/sys32.S - 1.3 linux/arch/ppc64/kernel/sys_ppc32.c - 1.7 linux/arch/ppc64/kernel/syscalls.c - 1.4 linux/arch/ppc64/kernel/time.c - 1.7 linux/arch/ppc64/kernel/traps.c - 1.6 linux/arch/ppc64/xmon/xmon.c - 1.6 linux/include/asm-ppc64/lmb.h - 1.4 linux/include/asm-ppc64/machdep.h - 1.6 linux/include/asm-ppc64/mmu.h - 1.5 linux/include/asm-ppc64/user.h - 1.2 linux/include/asm-ppc64/unistd.h - 1.6 linux/include/asm-ppc64/spinlock.h - 1.5 linux/include/asm-ppc64/smp.h - 1.5 linux/include/asm-ppc64/rtas.h - 1.4 linux/include/asm-ppc64/prom.h - 1.3 linux/include/asm-ppc64/processor.h - 1.8 linux/include/asm-ppc64/ppcdebug.h - 1.4 linux/include/asm-ppc64/pgtable.h - 1.6 linux/include/asm-ppc64/pgalloc.h - 1.6 linux/include/asm-ppc64/page.h - 1.7 linux/fs/jfs/jfs_metapage.h - 1.6 linux/drivers/hotplug/ibmphp_res.c - 1.3 linux/drivers/hotplug/ibmphp_pci.c - 1.2 linux/fs/jfs/jfs_logmgr.h - 1.8 linux/drivers/hotplug/ibmphp_hpc.c - 1.5 linux/drivers/hotplug/ibmphp_ebda.c - 1.4 linux/drivers/hotplug/ibmphp_core.c - 1.6 linux/drivers/hotplug/ibmphp.h - 1.3 linux/fs/jfs/file.c - 1.11 linux/fs/jfs/inode.c - 1.13 linux/fs/jfs/jfs_btree.h - 1.3 linux/fs/jfs/jfs_defragfs.h - 1.3 linux/fs/jfs/jfs_dinode.h - 1.3 linux/fs/jfs/jfs_dmap.c - 1.8 linux/fs/jfs/jfs_dmap.h - 1.3 linux/fs/jfs/jfs_dtree.c - 1.8 linux/fs/jfs/jfs_dtree.h - 1.4 linux/fs/jfs/jfs_extent.c - 1.5 linux/fs/jfs/jfs_incore.h - 1.10 linux/fs/jfs/jfs_imap.h - 1.5 linux/fs/jfs/jfs_imap.c - 1.8 linux/fs/jfs/jfs_filsys.h - 1.3 linux/fs/jfs/namei.c - 1.12 linux/fs/jfs/jfs_xtree.h - 1.3 linux/fs/jfs/jfs_xtree.c - 1.6 linux/fs/jfs/jfs_logmgr.c - 1.16 linux/fs/jfs/super.c - 1.14 linux/fs/jfs/jfs_mount.c - 1.10 linux/fs/jfs/jfs_txnmgr.c - 1.15 linux/fs/jfs/jfs_txnmgr.h - 1.5 linux/fs/jfs/jfs_types.h - 1.4 linux/fs/jfs/jfs_umount.c - 1.6 linux/fs/jfs/jfs_unicode.c - 1.3 linux/fs/jfs/jfs_unicode.h - 1.4 linux/fs/jfs/jfs_metapage.c - 1.11 linux/drivers/net/tg3.h - 1.9 linux/drivers/net/tg3.c - 1.10 linux/drivers/usb/image/microtek.c - 1.3 linux/drivers/usb/core/hcd.c - 1.10 linux/drivers/usb/core/inode.c - 1.8 linux/drivers/usb/host/ehci-dbg.c - 1.6 linux/drivers/usb/host/ehci-hcd.c - 1.8 linux/drivers/usb/host/ehci-hub.c - 1.4 linux/drivers/usb/host/ehci-q.c - 1.9 linux/drivers/usb/host/ehci-sched.c - 1.8 linux/drivers/usb/host/ehci.h - 1.4 linux/drivers/usb/host/ohci-dbg.c - 1.7 linux/drivers/usb/host/ohci-hcd.c - 1.10 linux/drivers/usb/host/ohci-mem.c - 1.4 linux/drivers/usb/host/ohci-q.c - 1.11 linux/drivers/usb/host/ohci.h - 1.7 linux/drivers/usb/image/hpusbscsi.c - 1.5 linux/drivers/usb/image/scanner.c - 1.9 linux/drivers/usb/media/se401.c - 1.8 linux/drivers/usb/media/se401.h - 1.2 linux/drivers/usb/net/usbnet.c - 1.9 linux/drivers/usb/net/pegasus.h - 1.6 linux/drivers/usb/net/kaweth.c - 1.8 linux/mm/pdflush.c - 1.6 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.2 linux/scripts/mkcompile_h - 1.5 linux/drivers/usb/host/uhci-hcd.c - 1.8 linux/drivers/usb/host/uhci-hcd.h - 1.3 linux/arch/i386/pci/common.c - 1.5 linux/arch/i386/pci/i386.c - 1.2 linux/drivers/pci/hotplug.c - 1.4 linux/drivers/pci/probe.c - 1.6 linux/fs/fs-writeback.c - 1.6 linux/include/linux/page-flags.h - 1.8 linux/arch/i386/pci/pci.h - 1.3 linux/arch/i386/pci/visws.c - 1.2 linux/mm/page-writeback.c - 1.10 linux/include/linux/buffer_head.h - 1.9 linux/include/linux/backing-dev.h - 1.2 linux/kernel/suspend.c - 1.11 linux/fs/mpage.c - 1.7 linux/drivers/char/hvc_console.c - 1.5 linux/drivers/acpi/ac.c - 1.3 linux/drivers/acpi/battery.c - 1.4 linux/drivers/acpi/bus.c - 1.7 linux/drivers/acpi/pci_root.c - 1.5 linux/drivers/acpi/pci_link.c - 1.4 linux/drivers/acpi/button.c - 1.3 linux/drivers/acpi/pci_irq.c - 1.5 linux/drivers/acpi/system.c - 1.8 linux/drivers/acpi/osl.c - 1.5 linux/drivers/usb/class/usb-midi.c - 1.4 linux/arch/i386/kernel/cpu/intel.c - 1.5 linux/net/llc/llc_if.c - 1.4 linux/include/net/llc_sap.h - 1.3 linux/include/net/llc_if.h - 1.2 linux/include/net/llc_s_ev.h - 1.3 linux/include/net/llc_pdu.h - 1.4 linux/include/net/llc_main.h - 1.3 linux/include/linux/llc.h - 1.2 linux/net/llc/llc_sock.c - 1.3 linux/net/llc/llc_sap.c - 1.4 linux/net/llc/llc_s_ac.c - 1.3 linux/net/llc/llc_mac.c - 1.4 linux/include/net/llc_mac.h - 1.3 linux/net/llc/llc_actn.c - 1.3 linux/net/llc/llc_pdu.c - 1.4 linux/net/llc/llc_c_ac.c - 1.4 linux/net/llc/llc_c_ev.c - 1.4 linux/net/llc/llc_main.c - 1.4 linux/net/llc/llc_conn.c - 1.4 linux/include/net/llc_c_st.h - 1.2 linux/include/net/llc_c_ev.h - 1.3 linux/include/net/llc_conn.h - 1.3 linux/include/net/llc_evnt.h - 1.3 linux/drivers/acpi/toshiba_acpi.c - 1.2 linux/drivers/input/serio/i8042-io.h - 1.3 linux/drivers/input/serio/q40kbd.c - 1.3 linux/fs/direct-io.c - 1.5 linux/drivers/usb/input/hid-lgff.c - 1.3 linux/include/asm-ppc64/ptrace-common.h - 1.2 linux/mm/rmap.c - 1.6 linux/include/asm-generic/rmap.h - 1.2 linux/include/asm-i386/rmap.h - 1.2 linux/include/asm-ppc64/mmzone.h - 1.4 linux/fs/jfs/resize.c - 1.4 linux/drivers/serial/sunzilog.c - 1.2 linux/drivers/serial/sunsu.c - 1.2 linux/drivers/usb/misc/Config.in - 1.2 linux/include/linux/pagevec.h - 1.3 linux/drivers/input/misc/pcspkr.c - 1.2 linux/fs/aio.c - 1.3 linux/arch/i386/kernel/cpu/mtrr/generic.c - 1.2 linux/drivers/ide/ide-swarm.c - 1.2 linux/drivers/ide/adma100.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/cyrix.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/main.c - 1.2 linux/arch/i386/kernel/cpu/mtrr/mtrr.h - 1.2 linux/arch/i386/kernel/cpu/mtrr/state.c - 1.2 linux/include/linux/aio.h - 1.2 linux/fs/jfs/jfs_xattr.h - 1.2 linux/fs/jfs/xattr.c - 1.3 linux/arch/i386/mm/discontig.c - 1.2 linux/arch/i386/kernel/numaq.c - 1.2 linux/include/asm-i386/mmzone.h - 1.2 linux/include/asm-i386/numaq.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:14:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:14:50 -0700 (PDT) Received: from penguin.e-mind.com ([195.223.140.120]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGEktG005496 for ; Mon, 16 Sep 2002 09:14:47 -0700 Received: from athlon.random (cda1.e-mind.com [195.223.140.107] (may be forged)) by penguin.e-mind.com (8.9.1a/8.9.1/Debian/GNU) with ESMTP id SAA18016; Mon, 16 Sep 2002 18:52:16 +0200 Received: from dualathlon.random (dualathlon.random [192.168.1.12]) by athlon.random (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8GGKaoq000719; Mon, 16 Sep 2002 18:20:36 +0200 Received: from dualathlon.random (localhost [127.0.0.1]) by dualathlon.random (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id g8GGKA8Q008617; Mon, 16 Sep 2002 18:20:10 +0200 Received: (from andrea@localhost) by dualathlon.random (8.12.3/8.12.3/Submit) id g8GGK1MU008616; Mon, 16 Sep 2002 18:20:01 +0200 Date: Mon, 16 Sep 2002 18:20:01 +0200 From: Andrea Arcangeli To: Dave Hansen Cc: Samuel Flory , Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 Message-ID: <20020916162001.GK11605@dualathlon.random> References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D8600DD.1010707@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8600DD.1010707@us.ibm.com> User-Agent: Mutt/1.3.27i X-archive-position: 405 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrea@suse.de Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 09:03:41AM -0700, Dave Hansen wrote: > + vmi = get_vmalloc_info(); hmm, not sure if it's better to slowdown vmalloc instead of /proc/meminfo and to keep meminfo o1. In theory vmalloc should be used only for persistent infrequent allocations, so meminfo has a chance to be recalled more frequently with monitors like xosview during workloads. Admittedly in final production with no monitoring meminfo is going to never be recalled, however I like the idea to keep meminfo very quick. Andrea From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:34:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:35:02 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGYutG006211 for ; Mon, 16 Sep 2002 09:34:57 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8GGdjlN195228; Mon, 16 Sep 2002 12:39:46 -0400 Received: from nighthawk.sr71.net (sig-9-65-11-88.mts.ibm.com [9.65.11.88]) by northrelay01.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8GGdfm5165384; Mon, 16 Sep 2002 12:39:42 -0400 Received: from us.ibm.com (nighthawk [127.0.0.1]) by nighthawk.sr71.net (8.11.6/8.11.6) with ESMTP id g8GGdWS00755; Mon, 16 Sep 2002 09:39:32 -0700 Message-ID: <3D860943.9070903@us.ibm.com> Date: Mon, 16 Sep 2002 09:39:31 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (compatible; MSIE5.5; Windows 98; X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Arcangeli CC: Samuel Flory , Stephen Lord , Austin Gonyou , Christian Guggenberger , Linux Kernel , linux-xfs@oss.sgi.com Subject: Re: 2.4.20pre5aa2 References: <20020911201602.A13655@pc9391.uni-regensburg.de> <1031768655.24629.23.camel@UberGeek.coremetrics.com> <20020911184111.GY17868@dualathlon.random> <3D81235B.6080809@rackable.com> <20020913002316.GG11605@dualathlon.random> <1031878070.1236.29.camel@snafu> <20020913005440.GJ11605@dualathlon.random> <3D8149F6.9060702@rackable.com> <20020913125345.GO11605@dualathlon.random> <3D8600DD.1010707@us.ibm.com> <20020916162001.GK11605@dualathlon.random> X-Enigmail-Version: 0.65.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 406 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: haveblue@us.ibm.com Precedence: bulk X-list: linux-xfs Andrea Arcangeli wrote: > On Mon, Sep 16, 2002 at 09:03:41AM -0700, Dave Hansen wrote: > >>+ vmi = get_vmalloc_info(); > > hmm, not sure if it's better to slowdown vmalloc instead of > /proc/meminfo and to keep meminfo o1. In theory vmalloc should be used > only for persistent infrequent allocations, so meminfo has a chance to > be recalled more frequently with monitors like xosview during workloads. > Admittedly in final production with no monitoring meminfo is going to > never be recalled, however I like the idea to keep meminfo very quick. When I first set out to do it, I modified vmalloc. But, I decided that it would probably be easier to get a patch in that didn't modify vmalloc itself. The used calculation is much easier (used += requested_size), but the largest free chunk gets harder to do. I think that this would have required vfree to get into the game as well. It seemed much easier to just make meminfo do a little more work. -- Dave Hansen haveblue@us.ibm.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 09:56:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 09:56:48 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GGuitG006844 for ; Mon, 16 Sep 2002 09:56:44 -0700 Received: from vk-clued0.fnal.gov ([131.225.224.23]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0H2J00L8BJARFP@smtp.fnal.gov> for linux-xfs@oss.sgi.com; Mon, 16 Sep 2002 12:01:39 -0500 (CDT) Date: Mon, 16 Sep 2002 12:01:39 -0500 (CDT) From: vkuznet Subject: XFS mount failure To: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 407 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vkuznet@fnal.gov Precedence: bulk X-list: linux-xfs Hi, we do have 3Ware RAID machine where XFS is using. After unexpected reboot we cannot longer mount our XFS filesystem. Here the /var/log/messages Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold exceeded: Port #6. Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - can't mount Any idea how to fix the problem. We do have Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 i686 unknown patched kernel with XFS. Thanks, Valentin. P.S. could you please reply me directly I'm not currently in a mailing list. From owner-linux-xfs@oss.sgi.com Mon Sep 16 10:13:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 10:13:09 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GHD4tG007469 for ; Mon, 16 Sep 2002 10:13:04 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA43123; Mon, 16 Sep 2002 12:17:54 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-13.corp.sgi.com [134.15.64.13]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id MAA61752; Mon, 16 Sep 2002 12:17:53 -0500 (CDT) Subject: RE: Re-occurance of NFS server panics From: Stephen Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 12:16:14 -0500 Message-Id: <1032196576.9808.149.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 408 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > Steve, > > Thanks for the quick response. I don't always get a Oops output > (sometimes the server just hangs and requires a reboot). However as it > happens the server has just crashed again with the following Oops > (through 'ksymoops'): This one suggests heap corruption more than anything else. Steve > > EFLAGS: 00010016 > eax: 5a2cf071 ebx: 003a0dc0 ecx: f7ee3dd0 edx: c200b060 > esi: ce837000 edi: ce8372b4 ebp: ce837ce0 esp: f7ee1f38 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=f7ee1000) > Stack: f7ee0000 00000009 f7ee3dd0 f7ee3c00 00000000 00000007 00000000 > 00000000 > 00000000 c200b060 00000020 000001d0 00000006 00000000 c01325d9 > c036aa70 > 00000006 000001d0 c036aa70 00000000 c013268c 00000020 c036aa70 > 00000002 > Call Trace: [] [] [] [] > [] > [] [] [] [] > Code: 0f 0b 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 2c 5a 01 ca 87 42 > > >>EIP; c013127e <===== > Trace; c01325d8 > Trace; c013268c > Trace; c0132730 > Trace; c01327a6 > Trace; c01328e0 > Trace; c0132840 > Trace; c0105000 <_stext+0/0> > Trace; c0105836 > Trace; c0132840 > Code; c013127e > 00000000 <_EIP>: > Code; c013127e <===== > 0: 0f 0b ud2a <===== > Code; c0131280 > 2: 8b 44 24 24 mov 0x24(%esp,1),%eax > Code; c0131284 > 6: 89 ea mov %ebp,%edx > Code; c0131286 > 8: 8b 48 18 mov 0x18(%eax),%ecx > Code; c0131288 > b: b8 71 f0 2c 5a mov $0x5a2cf071,%eax > Code; c013128e > 10: 01 ca add %ecx,%edx > Code; c0131290 > 12: 87 42 00 xchg %eax,0x0(%edx) > > Entering kdb (current=0xf7ee0000, pid 5) on processor 1 Oops: invalid > operand > eax = 0x5a2cf071 ebx = 0x003a0dc0 ecx = 0xf7ee3dd0 edx = 0xc200b060 > esi = 0xce837000 edi = 0xce8372b4 esp = 0xf7ee1f38 eip = 0xc013127e > ebp = 0xce837ce0 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 > > ->====================================================================== > > This is a different trace to the last one I posted, this new one makes > no direct reference to XFS which may mean that it is not XFS related (in > which case apologies....) or that it was another non XFS process > (kswapd) that ran into difficulty in obtaining kernel memory as a result > of XFS/extent issues. I seem to remember that the was an issue with the > XFS/KDB implementation around the time of the CVS kernel I'm currently > using. (No, the server shouldn't be running out of memory, it has 1Gbyte > RAM and does nothing but NFS serving, it normally has ~957684K cached). > > If I remember correctly we have tried the fix you refer to regarding > memory getting freed to the wrong pool: > > > > > Only happens under high memory pressure, Ian, I think this was > > your original oops. > > > > Date: Wed Mar 20 11:06:42 PST 2002 > > Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline > > > > The following file(s) were checked into: > > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > > > Modid: 2.4.x-xfs:slinx:114531a > > linux/fs/xfs_support/kmem.c - 1.22 > > - Fix the case where we used vmalloc to allocate memory under > pressure, > > we need to free it that way > > Anyway, I think I need to get the current 2.4.19-XFS tree installed even > if this doesn't fix the problem it will give us a better base to work > from. > > Regards > > Ian Hardy > > -----Original Message----- > From: Stephen Lord [mailto:lord@sgi.com] > Sent: 16 September 2002 16:36 > To: I.D.Hardy@soton.ac.uk > Cc: linux-xfs@oss.sgi.com > Subject: RE: Re-occurance of NFS server panics > > > On Mon, 2002-09-16 at 09:52, Ian D. Hardy wrote: > > Steve +, > > > > Sorry to bother you again. You may remember that we've corresponded > > several times over the past ~9months with regards to kernel memory > > allocation problems and fragmented files (see bellow). > > > > We had a period of relative stability, however the last few weeks we > > have gone back to a situation of having one or more crashes/hangs > > every week and are now having to again review our continued use of > > XFS. Therefore any update on progress towards a fix for these > > problems would be very useful (I'd hate to go though the pain of > > converting our ~1Tbyte filesystem to Reiser of ext3 if there are fixes > > > immanent). > > > > We have been running a 2.4.18 XFS CVS kernel from Mid May for some > > time now, I'm just in the process of compiling and testing the current > > > 2.4.19 XFS CVS, is this likely to help? (looking through the list > > archive I can't find anything of direct relevance but may have missed > > something). > > > > We appear to be running at a lower overall system fragmentation level > > now (currently 13% in the past it has been 28% or more), though I > > guess it is possible for only a couple of large very fragmented files > > to result in kernel memory allocation problems and still have > > reasonably low overall FS fragmentation levels? > > > > Unfortunately the NFS load on our server is such that it is > > difficult/impossible to predict times of light NFS load in which to > > run fsr and as reported before we've had several incidents of > > filesystem corruption and the kernel taking the FS offline running fsr > > > under a NFS load. > > > > Thanks for your time (BTW: We've persevered with XFS for so long as it > > > seems to give better performance for our workload than ext3 or > > ReiserFS, however, stability is again becoming a problem). > > > > Nothing immediately rings a bell, there have been some recent changes > which fixed some hangs HP was having in doing large scale NFS > benchmarking. These might be beneficial to you. The last oops output I > have from you looked like this: > > >>EIP; c012ff76 <===== > Trace; c01fd146 > Trace; c01fd1a4 > Trace; c01d04f0 > Trace; c01a6996 > Trace; c01a5f12 > Trace; c01d6474 > Trace; c01fd2e0 > Trace; c01aac14 > Trace; c01cf962 > Trace; c01e6e22 > Trace; c01e6340 > Trace; c026cf44 > Trace; c01f696e > Trace; c01e6340 > Trace; c014f45c > Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> > Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> > Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> > Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> > Trace; f8d2b348 <[nfsd]nfsd+1b8/370> > Trace; c01057ea > Code; c012ff76 > 00000000 <_EIP>: > Code; c012ff76 <===== > 0: 0f 0b ud2a <===== > Code; c012ff78 > 2: 83 c4 08 add $0x8,%esp > Code; c012ff7a > 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx > Code; c012ff80 > b: 8b 2c 1a mov (%edx,%ebx,1),%ebp > Code; c012ff84 > e: 89 7c 24 14 mov %edi,0x14(%esp,1) > Code; c012ff88 > 12: b8 00 00 00 00 mov $0x0,%eax > > Is this still what you see? > > This one does bear the symptoms of a problem which was fixed a while ago > - memory was freed into the wrong pool. > > Steve > > From owner-linux-xfs@oss.sgi.com Mon Sep 16 10:57:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 10:57:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GHvXtG008742 for ; Mon, 16 Sep 2002 10:57:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA45603; Mon, 16 Sep 2002 13:02:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA75391; Mon, 16 Sep 2002 13:02:22 -0500 (CDT) Subject: Re: XFS mount failure From: Eric Sandeen To: vkuznet Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 16 Sep 2002 12:57:32 -0500 Message-Id: <1032199053.6354.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs hi Valentin - Well, you can mount with "-o nouuid" to get around this, but the question remains, which other filesystem has this same uuid? Try xfs_db -r -c "sb 0" -c "p uuid" /dev/ for each of your mounted filesystems' devices, and see if you can find it. -Eric On Mon, 2002-09-16 at 12:01, vkuznet wrote: > Hi, > we do have 3Ware RAID machine where XFS is using. > After unexpected reboot we cannot longer mount our XFS filesystem. > > Here the /var/log/messages > > Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold exceeded: Port #6. > Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - can't mount > > Any idea how to fix the problem. > > We do have > Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 i686 unknown > patched kernel with XFS. > > Thanks, > Valentin. > P.S. could you please reply me directly I'm not currently in a mailing list. > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Mon Sep 16 11:10:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 11:10:35 -0700 (PDT) Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GIAMtG009312 for ; Mon, 16 Sep 2002 11:10:22 -0700 Received: by musuko.uchicago.edu (Postfix, from userid 1002) id 940E82839E50; Mon, 16 Sep 2002 12:44:05 -0500 (CDT) Subject: Lost interrupt on repairing file system From: Stuart Luppescu To: Linux XFS List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-T/Mp9pMWzbpedOtYT2ot" X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 12:44:05 -0500 Message-Id: <1032198245.32318.11.camel@musuko.uchicago.edu> Mime-Version: 1.0 X-archive-position: 410 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: s-luppescu@uchicago.edu Precedence: bulk X-list: linux-xfs --=-T/Mp9pMWzbpedOtYT2ot Content-Type: text/plain Content-Transfer-Encoding: quoted-printable We had a power failure here, and when I restarted my machine and the xfs repair ran, I got this message repeated about 4 or 5 times: /dev/hda lost interrupt It seems to be running ok now, but I'm curious about what this means. Can someone explain this, please? (I'm running Gentoo Linux on an Athlon XP 2100 system, with the Gentoo 2.4.19-r7 kernel sources.) --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.19-gentoo-r7=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20 Can I have an IMPULSE ITEM instead?=20 =20 --=-T/Mp9pMWzbpedOtYT2ot Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9hhhlDBHcBS0tWxMRAqeXAJ4gtTcPFlifQl9jxj19pM+uBlNa7ACfQ2uS Ehmiu2v1nWepbTXBpbIDLN8= =D/Y1 -----END PGP SIGNATURE----- --=-T/Mp9pMWzbpedOtYT2ot-- From owner-linux-xfs@oss.sgi.com Mon Sep 16 13:38:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 13:38:20 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GKcFtG012416 for ; Mon, 16 Sep 2002 13:38:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA41283 for ; Mon, 16 Sep 2002 15:43:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA92940; Mon, 16 Sep 2002 15:43:05 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8GKcDb07390; Mon, 16 Sep 2002 15:38:13 -0500 Message-Id: <200209162038.g8GKcDb07390@stout.americas.sgi.com> Date: Mon, 16 Sep 2002 15:38:13 -0500 Subject: PARTIAL TAKE - mkfs trips ASSERT in ag resizing code X-archive-position: 411 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Reiterating for the benefit of the folks on linux-xfs: mkfs.xfs contains code which looks to see if all AGs will start on the same disk stripe, a non-optimal configuration, and changes the ag size by +/- 1 data stripe unit to avoid this. However, in the 1 AG case, this can lead to an ag size > data size, which ultimately fails in an ASSERT. This can be demonstrated with: mkfs.xfs -f -b size=4096 -d file,name=foo,size=10m,sunit=8,swidth=8 This can be avoided by not even going down the path for the 1-ag case, but a check for (agsize > dblocks) is added as well, to ensure that this never happens. Date: Mon Sep 16 13:38:02 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127521a cmd/xfsprogs/VERSION - 1.58 - Bump to 2.3.3 cmd/xfsprogs/doc/CHANGES - 1.83 - Document changes for 2.3.3 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.36 - Don't do ag resizing based on stripe alignment for single ag fs Don't ever let agsize > dblocks when doing this resizing. From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:03:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:03:12 -0700 (PDT) Received: from moutvdom.kundenserver.de (moutvdom.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GM35tG020059 for ; Mon, 16 Sep 2002 15:03:06 -0700 Received: from [195.20.224.214] (helo=mrvdomng2.kundenserver.de) by moutvdom.kundenserver.de with esmtp (Exim 3.35 #1) id 17r427-0002rk-00 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 00:07:55 +0200 Received: from [217.88.221.79] (helo=kernelpanix.aura.of.mankind) by mrvdomng2.kundenserver.de with esmtp (Exim 3.35 #1) id 17r427-0004RR-00 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 00:07:55 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.6/8.11.2) id g8GM5WY18388 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 00:05:32 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 17 Sep 2002 00:05:32 +0200 From: utz lehmann To: linux-xfs@oss.sgi.com Subject: Linus merges XFS Message-ID: <20020917000532.A18289@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-archive-position: 412 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: xfs@s2y4n2c.de Precedence: bulk X-list: linux-xfs saw this on lwn.net. linus had merged XFS in the 2.5 tree. congratulation! and many thanks to all who made this possible. utz From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:09:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:09:53 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GM9otG020547 for ; Mon, 16 Sep 2002 15:09:50 -0700 Received: (qmail 14242 invoked by uid 500); 16 Sep 2002 22:14:32 -0000 Subject: Re: Linus merges XFS From: Austin Gonyou To: utz lehmann Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020917000532.A18289@s2y4n2c.de> References: <20020917000532.A18289@s2y4n2c.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032214472.13127.50.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 16 Sep 2002 17:14:32 -0500 X-archive-position: 413 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: austin@coremetrics.com Precedence: bulk X-list: linux-xfs Wooohooooo!!!! Hip-hip Hooooray!!!! On Mon, 2002-09-16 at 17:05, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:12:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:12:14 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GMCCtG021015 for ; Mon, 16 Sep 2002 15:12:12 -0700 Received: from attbi.com ([12.253.73.46]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020916221703.RCNK16829.rwcrmhc51.attbi.com@attbi.com> for ; Mon, 16 Sep 2002 22:17:03 +0000 Message-ID: <3D8658FF.30301@attbi.com> Date: Mon, 16 Sep 2002 16:19:43 -0600 From: "D. Stimits" Reply-To: stimits@attbi.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020528 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 414 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stimits@attbi.com Precedence: bulk X-list: linux-xfs utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz > > > Yay! I may have an excuse to go with 2.5 now. I have never kept up with issues on 2.5 though, I especially avoid devfs which I *think* is more important to 2.5 series. Can anyone give me any warnings or other hints one what to look out for if I use the next 2.5 release based on Linus merge of XFS? D. Stimits, stimits AT attbi.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 15:15:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 15:15:06 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GMF4tG021460 for ; Mon, 16 Sep 2002 15:15:04 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA47824; Mon, 16 Sep 2002 17:19:55 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-4.corp.sgi.com [134.15.64.4]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA59408; Mon, 16 Sep 2002 17:19:54 -0500 (CDT) Subject: Re: Linus merges XFS From: Stephen Lord To: stimits@attbi.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D8658FF.30301@attbi.com> References: <20020917000532.A18289@s2y4n2c.de> <3D8658FF.30301@attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Sep 2002 17:18:13 -0500 Message-Id: <1032214695.9808.216.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 415 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-16 at 17:19, D. Stimits wrote: > > Yay! I may have an excuse to go with 2.5 now. I have never kept up with > issues on 2.5 though, I especially avoid devfs which I *think* is more > important to 2.5 series. Can anyone give me any warnings or other hints > one what to look out for if I use the next 2.5 release based on Linus > merge of XFS? > > D. Stimits, stimits AT attbi.com > devfs is pretty much a dead issue in 2.5, there is a new spiffy driverfs, but it is a different beast entirely and you do not need it. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 16 16:01:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 16:01:46 -0700 (PDT) Received: from echo.computel.nl (IDENT:postfix@echo.computel.nl [195.86.134.74]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GN1htG024620 for ; Mon, 16 Sep 2002 16:01:44 -0700 Received: from localhost (localhost [127.0.0.1]) by echo.computel.nl (Postfix) with SMTP id DF1409E54 for ; Tue, 17 Sep 2002 01:06:38 +0200 (CEST) X-AV-Checked: Tue Sep 17 01:06:38 2002 www.nederland.net Received: from balefire10ww (e122144.upc-e.chello.nl [213.93.122.144]) by echo.computel.nl (Postfix) with ESMTP id 9C7A19E53 for ; Tue, 17 Sep 2002 01:06:38 +0200 (CEST) Message-ID: <004401c25dd5$b64bbfb0$64c8a8c0@balefire10ww> From: "Sander Steffann" To: References: <20020917000532.A18289@s2y4n2c.de> Subject: Re: Linus merges XFS Date: Tue, 17 Sep 2002 01:06:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-archive-position: 416 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sander@steffann.nl Precedence: bulk X-list: linux-xfs > saw this on lwn.net. linus had merged XFS in the 2.5 tree. Congratulations everyone! Sander. From owner-linux-xfs@oss.sgi.com Mon Sep 16 16:41:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 16:41:44 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8GNfctG027229 for ; Mon, 16 Sep 2002 16:41:38 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA03465 for ; Mon, 16 Sep 2002 16:46:34 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA10877; Tue, 17 Sep 2002 09:45:17 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA52758; Tue, 17 Sep 2002 09:45:16 +1000 (AEDT) Date: Tue, 17 Sep 2002 09:45:15 +1000 From: Nathan Scott To: Frasenyak Dmitrij Cc: linux-xfs@oss.sgi.com Subject: Re: Need information about XFS tests Message-ID: <20020917094515.A154181@wobbly.melbourne.sgi.com> References: <3D85C8D5.6030901@rtsoft.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D85C8D5.6030901@rtsoft.msk.ru>; from sed@rtsoft.msk.ru on Mon, Sep 16, 2002 at 04:04:37PM +0400 X-archive-position: 417 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 04:04:37PM +0400, Frasenyak Dmitrij wrote: > Hello > I'm looking for any documentation about XFS tests included in CVS tree. > I've searched over sgi site and Internet but found only small remarks > in the headers of scripts. There's a bit more info here... cmd/xfstests# ls */*README* *README* README dmapi/README crash/README tools/README.auto-qa cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 16 18:00:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 18:00:15 -0700 (PDT) Received: from web40612.mail.yahoo.com (web40612.mail.yahoo.com [66.218.78.149]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H109tG030563 for ; Mon, 16 Sep 2002 18:00:09 -0700 Message-ID: <20020917010501.70562.qmail@web40612.mail.yahoo.com> Received: from [208.35.40.2] by web40612.mail.yahoo.com via HTTP; Mon, 16 Sep 2002 18:05:01 PDT Date: Mon, 16 Sep 2002 18:05:01 -0700 (PDT) From: Ravi Wijayaratne Subject: oops in 2.4.18 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 418 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Hi all, In our stress test we see the oops that is attached. Having examined the code we see that the oops is happening in page_buf.c function pagebuf_page_io. Apparently the call to kmalloc failed in the following function. ---------------------------------- psync=(pagesync_t *)kmalloc(sizeof(pagesync_t),GFP_NOFS); if(psync==NULL) BUG(); <======== oopsed here ---------------------------------- We are running 2.4.18-xfs code with LVM on RAID 5. Is there a fix available for this ? Thank you Ravi ---------------------0x--------------x0----------- invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: 00000008 ecx: 00000246 edx: 00000000 esi: 0c0002a0 edi: c1631780 ebp: 00000000 esp: efecde9c ds: 0018 es: 0018 ss: 0018 Process pagebuf_daemon (pid: 7, stackpage=efecd000) Stack: 00000000 0c0002a0 c1631780 d69cda60 e97dd7a0 0c8000cf 00000008 00000008 00000000 efecdec8 3a009fc8 d7ce49e0 d7ce46e0 d7ce4200 d7ce4bc0 d7ce43e0 d7ce42c0 d7ce4440 e97dd7a0 c01decf2 c1631780 d69cda60 0c0002a0 00000000 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 74 24 54 89 75 00 8b 7c 24 70 89 7d 04 c7 45 08 00 >>EIP; c01de997 <_pagebuf_page_io+bf/324> <===== Trace; c01decf2 <_page_buf_page_apply+f6/108> Trace; c01df16a Trace; c01dedf4 Trace; c01debfc <_page_buf_page_apply+0/108> Trace; c01e8742 Trace; c01df418 Trace; c0105000 <_stext+0/0> Trace; c01df250 Trace; c01056f3 Code; c01de997 <_pagebuf_page_io+bf/324> 00000000 <_EIP>: Code; c01de997 <_pagebuf_page_io+bf/324> <===== 0: 0f 0b ud2a <===== Code; c01de999 <_pagebuf_page_io+c1/324> 2: 8b 74 24 54 mov 0x54(%esp,1),%esi Code; c01de99d <_pagebuf_page_io+c5/324> 6: 89 75 00 mov %esi,0x0(%ebp) Code; c01de9a0 <_pagebuf_page_io+c8/324> 9: 8b 7c 24 70 mov 0x70(%esp,1),%edi Code; c01de9a4 <_pagebuf_page_io+cc/324> d: 89 7d 04 mov %edi,0x4(%ebp) Code; c01de9a7 <_pagebuf_page_io+cf/324> 10: c7 45 08 00 00 00 00 movl $0x0,0x8(%ebp) ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 19:48:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 19:48:48 -0700 (PDT) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H2mftG031740 for ; Mon, 16 Sep 2002 19:48:42 -0700 Received: from [209.96.179.45] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17r8Ub-000PNq-00 for linux-xfs@oss.sgi.com; Mon, 16 Sep 2002 22:53:38 -0400 Received: from daydream.shannon.net (daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g8H1t8229254 for ; Mon, 16 Sep 2002 21:55:08 -0400 (EDT) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id g8H1t51L016094 for ; Mon, 16 Sep 2002 21:55:05 -0400 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id g8H1sj3W016091 for linux-xfs@oss.sgi.com; Mon, 16 Sep 2002 21:54:45 -0400 Date: Mon, 16 Sep 2002 21:54:45 -0400 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917015442.GA15962@widomaker.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020917000532.A18289@s2y4n2c.de> <3D8658FF.30301@attbi.com> <1032214695.9808.216.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032214695.9808.216.camel@laptop.americas.sgi.com> User-Agent: Mutt/1.4i X-archive-position: 419 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: shannon@widomaker.com Precedence: bulk X-list: linux-xfs On Mon, Sep 16, 2002 at 05:18:13PM -0500, Stephen Lord wrote: > devfs is pretty much a dead issue in 2.5, there is a new spiffy > driverfs, but it is a different beast entirely and you do not > need it. You mean they are getting rid of devfs? -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Mon Sep 16 20:30:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 20:30:31 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H3U3tG000464 for ; Mon, 16 Sep 2002 20:30:04 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8H3Yxq04948 for ; Mon, 16 Sep 2002 23:34:59 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8H3Yxx04939; Mon, 16 Sep 2002 23:34:59 -0400 Date: Mon, 16 Sep 2002 23:34:58 -0400 (EDT) From: Benito Venegas To: utz lehmann cc: Subject: Re: Linus merges XFS In-Reply-To: <20020917000532.A18289@s2y4n2c.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 420 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Congratulation guys!!!! On Tue, 17 Sep 2002, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz > > Vene.- From owner-linux-xfs@oss.sgi.com Mon Sep 16 23:48:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 23:48:58 -0700 (PDT) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6mstG002645 for ; Mon, 16 Sep 2002 23:48:55 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H6rkg6046463; Tue, 17 Sep 2002 08:53:51 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917085058.0373f448@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 08:52:34 +0200 To: Benito Venegas , From: Seth Mos Subject: Re: kernel src to compile In-Reply-To: References: <200209131823.g8DINgZ25682@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 421 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:08 16-9-2002 -0400, Benito Venegas wrote: >Good morning team: >(bad morning for me, but I hope you have better than mine) > >I have a problem in one of my servers. >Kernel Panic, only I have latest line, due Kernel Panic >debug message was too big for my console (nfs_ related problem I think) >grrrrrr..I ate don;t have good logs.... > >Does any of you guys have a kernel-2.4.18 or higher version >in format src.rpm ready to compile? or at least > 2.4.9-31 that I am using >today. ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/2.4.18/SRPMS/ This one? -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Sep 16 23:52:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 23:52:39 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6qatG003108 for ; Mon, 16 Sep 2002 23:52:36 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H6vWuO060460; Tue, 17 Sep 2002 08:57:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917085353.038c0c88@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 08:56:19 +0200 To: Stuart Luppescu , Linux XFS List From: Seth Mos Subject: Re: Lost interrupt on repairing file system In-Reply-To: <1032198245.32318.11.camel@musuko.uchicago.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_2517079==_" X-archive-position: 422 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs --=====================_2517079==_ Content-Type: multipart/related; type="text/plain"; boundary="=====================_2517079==_.REL" --=====================_2517079==_.REL Content-Type: text/plain; charset="us-ascii"; format=flowed At 12:44 16-9-2002 -0500, Stuart Luppescu wrote: >23eed0.jpg Lost interrupt on repairing >fil.ems<0880.0002>> >*** PGP Signature Status: bad >*** Signer: Stuart Luppescu (Invalid) >*** Signed: 16-9-2002 19:44:05 >*** Verified: 17-9-2002 8:53:39 >*** BEGIN PGP VERIFIED MESSAGE *** > >We had a power failure here, and when I restarted my machine and the xfs >repair ran, I got this message repeated about 4 or 5 times: >/dev/hda lost interrupt >It seems to be running ok now, but I'm curious about what this means. >Can someone explain this, please? A flakky IDE controller at best. As long as it is not reporting media errors you might be OK. You might have either not compiled the driver for your IDE chipset into the kernel and the controller is working in compatability mode which might cause interesting problems. In general I'd said the disk/machine was very busy and a interrupt got dropped. Cheers --=====================_2517079==_.REL Content-Type: image/jpeg; name="23eed0.jpg"; x-mac-type="4A504547"; x-mac-creator="4A565752" Content-ID: <4.3.2.7.2.20020917085353.038c0c88@pop.xs4all.nl.0> Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="23eed0.jpg" /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/ 2wBDAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQH/wAARCAAgACADASIAAhEBAxEB/8QA HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1 dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU 1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD+gCvlf9tW b4sW37Nvjq4+DFp4ov8AxfBrHwym1mw8DtrCeNL34TRfFfwO/wAfLTwg/ha5 svHieKLn4Fr8RodAb4W3lp8Yl1Z7Q/By5g+KI8Iypp3dx8fviH8dfjX4F+Hf xZ+HXwl8A/BD4Rfsh+MdRl1L9ij4+/tnfEPxf4t/as+M/wC0t8KLWHTvDPwK /aJ+EOt6B4T8Ht8EPD9/q+oL4R8VQ6dYeIPEHifxHrWgeHPDtxOn09Y/sP8A 7cmoWtneQftvfsqpDfW9pcwpcf8ABNj41W10sd5HYSxrNYzf8FO0vYrgLqEY a0a3+1PJ9khghmm13wwmufB8TeJ/AHBuNhl/FHFWV5NjalP2sKGLqVVJxtGT TdOlUhGpGFSlUlRlJVYUq+HqygqWIozqdVHBYrERcqFCdSKdm4penVp2vdJ7 NppO6aX8w3iD4Qa/+xd+0J+wr8S/D/hzwf8ABf47/tW6h8M9Z+P3gj4YfC79 nn4Y+BPhPquu/tM/sPfCb4ufs+fDTTfgD8O/B2k+Ifgfd6R+018QdAGg/FLX /jhc2ms+BPhL8TPCnja2+JXgq1+IGp/04V+Pnxn8OeHvhRL/AMFA9W/aj8N/ 8E+/2oPjD8Ef2rPgn4E8PfGD9o39jf8AZT13w34a+HPj39lf9ifxzZeAvB3h f9s//goJ4Fm+Hnw8t9V+InjrWNK8Nr+0v4Y8F618R/FHxU+J/gi/8eax468T 6D8Lvmr9qSw+HfgfWf8Agl148+B3wS/Zb+CXiX4j/tH/ALEfizxN49/ZZ/Zh /Zq+CHiDWfD3xVv/AIR+F/GmmWXxB/Z68O/E7U7f4L+PLfxh418Pal4b0H48 +J/g54rl1zX/AAwv7VHxouBd/s++Cfk868deDsoz/grh+GHzjNK3H3EGQcP5 BmWXUMDPKZz4iyHE8S4HMcRXr5hQxUMveU4SrLno4KvXliZ0KKw6o1KmJo7U 8sxFSliat6cFhaVSrVhNyVS1KtGhKCSg4uftJLRyS5U3e6UX+6X/AATi/YV/ YP8AFX7IH/BMzSvFn/BHT9n/AOK//C1/2AP2WfiL8Sf2vdT/AGav2Cdc8Cad 471z9n/R9e1yD4pS+OfGenftNeKviB4q1rTra61DxF4Z+Cnj7R9R1jx9oWoa z4uTy/G174V+Zf8Agn/4x/ac/YJ1n/gn1+xFq37D/wAePgr4I+M/g74d/s2+ PdG+N/jz4BT/AAT0X9q74Y/s0+KPiH8afjZ+zl4i+C3xU+P3jfT/AAx8Xr74 U/E7VfHnwy1T4Yp8LviB418VWn7Qa+Kfgn4x8Y/tB+Fv2neL/Zu/aZ/4JheL v2Vv+Cc+m/F79sj/AIIoGw8Of8E4P2FP2ev2oPhb+1R+zn4E/aD/AGh/EPhX 4e+Hvh18SvGfwOm+NNx+1N4C0PwJ4f0Xxnomh6po3w08b/BL4m6d8LPjr4Xu fiDrui+IdetIfC2iN/bA/bD+CvxZ0v8A4JO/BP8AY7+PP/BLv9tL9oD4KftE fE21tPhB8O9Nk+EX7K2l/DrSf2L/ANqjwz4Tih+Avhvx1+0/4x+H3gf4ceA2 0PQ9As7PV/G3hc+PtE8NpJbeFPDniGx8O6P9p4h8MZfxfwZxFkeYZLTz9YjK 8bUwWWSlQpVa2aUMNVqZb9UxOIxODpYPGfW1Tjh8VPG4OnSlN+2xNKhKrI58 JWnh8RRqwqOk4zjzT1aUHJc/NFKTlHlvePLJvpFux9zj9gjQP239Vb9qO6+N n7Zf7F/xI+KcPgXxv8Vvhd8AfEHiDw74G1P4oReDvg3YW3j6Oy/bf/YW8M/F W08ayeFPhP8AArwrqtz4Z8B+C9MuJfhN8MNe13wafjVp99e/Eb8tfi/+wD4a +GX/AAU4/Zh/Z88YftE/tG/tGfCjwL+zprv7bHhPw78dNR+Bt9JoHxz+C3xX +CHwq+GWraJrHwr+C/w31fQ9D0Lw7c6BfJp+h6hp0utWvhDwj4Q1LW/Fnwfj v/D/AIw+0NJ/aF/4K0eH9Z1PxF4f/Zb/AOCSmheINas7TTtW13Sfin+0rZaz qen6dYrpel2Op6nF+zsL3VLPTdMg0/TrS11Oe7gFjpy2kyTW+q+IY9Z4Pw54 c/bc+MP7bnhr9q/9q/w1+yz4LsfBf7LPxM/Z70bRv2e/iZ8YfHN3qt345+MP wq+J2n6pqmn/ABO+FXgyPT4dPj8GeJLXUtRtfEmoXWqXWoaRPPpD6g+t63e/ xn4YeCniHgPGXhXiviTw6yfJ+F8lw9P/AGnHVOBc5zbA1cu4Nq5LlVKGbYLF ZhxFjfqOZQwkMuxFWtzUcNhsNVlHC+wp0aX0ONzHCTy6tQpYupUr1JP3YrE0 6clPERqTfs5KNKPNHmc0lq21eV23/9k= --=====================_2517079==_.REL-- --=====================_2517079==_ Content-Type: text/plain; charset="us-ascii"; format=flowed -- Seth It might just be your lucky day, if you only knew. --=====================_2517079==_-- From owner-linux-xfs@oss.sgi.com Mon Sep 16 23:55:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Sep 2002 23:55:28 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6tPtG003615 for ; Mon, 16 Sep 2002 23:55:26 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H70KO8007899; Tue, 17 Sep 2002 09:00:21 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917085626.038c0d90@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 08:59:07 +0200 To: vkuznet , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS mount failure In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 423 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 12:01 16-9-2002 -0500, vkuznet wrote: >Hi, >we do have 3Ware RAID machine where XFS is using. >After unexpected reboot we cannot longer mount our XFS filesystem. > >Here the /var/log/messages > >Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold >exceeded: Port #6. >Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - >can't mount I don't know about a 3ware controllers but I'd say the smart on the disk on port 6 is telling the controller that it's going bad. Better check. xfs_repair might be able to fix your filesystem. What 3ware controller are you using? >Any idea how to fix the problem. > >We do have >Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 >i686 unknown >patched kernel with XFS. Can you upgrade to something more recent please. You definitely want the XFS 1.1 release or later. Use CVS or the split patches if you want newer then 2.4.18. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 00:00:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 00:00:02 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H6xxtG004099 for ; Tue, 17 Sep 2002 00:00:00 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8H74uP9063935; Tue, 17 Sep 2002 09:04:56 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917090225.0438df38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 09:03:44 +0200 To: utz lehmann , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Linus merges XFS In-Reply-To: <20020917000532.A18289@s2y4n2c.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 424 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 00:05 17-9-2002 +0200, utz lehmann wrote: >saw this on lwn.net. linus had merged XFS in the 2.5 tree. > >congratulation! > >and many thanks to all who made this possible. ! :-) -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 00:07:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 00:07:34 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H77VtG004624 for ; Tue, 17 Sep 2002 00:07:31 -0700 Received: from erbenson.alaska.net (160-pm11.nwc.alaska.net [209.112.140.160]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8H7CRBs091575 for ; Mon, 16 Sep 2002 23:12:28 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 187633A09 for ; Mon, 16 Sep 2002 23:12:27 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 999DC4104E7; Mon, 16 Sep 2002 23:12:26 -0800 (AKDT) Date: Mon, 16 Sep 2002 23:12:26 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917071226.GA10776@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020917000532.A18289@s2y4n2c.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline In-Reply-To: <20020917000532.A18289@s2y4n2c.de> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 425 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2002 at 12:05:32AM +0200, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. you know what they say, if at first you don't succeed, try, try try try, try again. > congratulation! >=20 > and many thanks to all who made this possible. indeed. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2G1doACgkQJKx7GixEevw3LgCfdloyqtOyL+jbsXwpyRaB96t6 WjUAnRQXzLPh6HiNYgIAvZCDJKG+QqPt =zLNb -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-linux-xfs@oss.sgi.com Tue Sep 17 00:18:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 00:18:09 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8H7I6tG005178 for ; Tue, 17 Sep 2002 00:18:06 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8H7N2T7025487; Tue, 17 Sep 2002 09:23:03 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id C81FF69123; Tue, 17 Sep 2002 09:23:01 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: utz lehmann , linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Date: Tue, 17 Sep 2002 09:23:01 +0200 X-Mailer: KMail [version 1.3.2] References: <20020917000532.A18289@s2y4n2c.de> In-Reply-To: <20020917000532.A18289@s2y4n2c.de> MIME-Version: 1.0 Message-Id: <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8H7I7tG005179 X-archive-position: 426 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs Many thanks and congratulations to everyone involved!!! This is what I was waiting for so long, thanks. Simon On Tuesday 17 September 2002 00:05, utz lehmann wrote: > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > congratulation! > > and many thanks to all who made this possible. > > > utz From owner-linux-xfs@oss.sgi.com Tue Sep 17 03:40:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 03:40:35 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HAeWtG015284 for ; Tue, 17 Sep 2002 03:40:32 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8HAjTq10520 for ; Tue, 17 Sep 2002 06:45:29 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8HAjTH10510; Tue, 17 Sep 2002 06:45:29 -0400 Date: Tue, 17 Sep 2002 06:45:29 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: Subject: Re: kernel src to compile In-Reply-To: <4.3.2.7.2.20020917085058.0373f448@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 427 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs I was looking for a new one (many updates since last time you did that src.rpm @ oss.sgi.com I am using this one now. Thanks On Tue, 17 Sep 2002, Seth Mos wrote: > At 11:08 16-9-2002 -0400, Benito Venegas wrote: > >Good morning team: > >(bad morning for me, but I hope you have better than mine) > > > >I have a problem in one of my servers. > >Kernel Panic, only I have latest line, due Kernel Panic > >debug message was too big for my console (nfs_ related problem I think) > >grrrrrr..I ate don;t have good logs.... > > > >Does any of you guys have a kernel-2.4.18 or higher version > >in format src.rpm ready to compile? or at least > 2.4.9-31 that I am using > >today. > > ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/2.4.18/SRPMS/ > > This one? > -- > Seth > It might just be your lucky day, if you only knew. > -- Vene.- From owner-linux-xfs@oss.sgi.com Tue Sep 17 03:43:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 03:43:28 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HAhOtG016120 for ; Tue, 17 Sep 2002 03:43:24 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8HAmEh1068398; Tue, 17 Sep 2002 12:48:19 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917124548.03981060@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 12:47:05 +0200 To: Benito Venegas From: Seth Mos Subject: Re: kernel src to compile Cc: In-Reply-To: References: <4.3.2.7.2.20020917085058.0373f448@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 428 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 06:45 17-9-2002 -0400, Benito Venegas wrote: >I was looking for a new one (many updates since last time you did that >src.rpm @ oss.sgi.com There was discussion about releasing a newer one but there were/are some issues that need to be fixed for a new release to happen. Untill that time you can wait or us the CVS/split patches. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 05:38:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 05:38:55 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HCcntG019226 for ; Tue, 17 Sep 2002 05:38:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA52514 for ; Tue, 17 Sep 2002 07:43:42 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA46236 for ; Tue, 17 Sep 2002 07:43:41 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8HJwgL06252 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 15:58:42 -0400 Resent-Message-Id: <200209171958.g8HJwgL06252@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA95901 for ; Tue, 17 Sep 2002 07:43:19 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8HJwKV06207 for hch@sgi.com; Tue, 17 Sep 2002 15:58:20 -0400 Date: Tue, 17 Sep 2002 15:58:20 -0400 From: Christoph Hellwig Message-Id: <200209171958.g8HJwKV06207@dhcp212.munich.sgi.com> Subject: TAKE - Use do_gettimeofday() instead of racy direct access to xtime Resent-Date: Tue, 17 Sep 2002 15:58:42 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 429 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs This is the right fix for the small change in support/time.h in the 2.5.35 merge. Date: Tue Sep 17 05:42:00 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127568a linux/fs/xfs/support/time.h - 1.7 - Use do_gettimeofday() instead of racy direct access to xtime From owner-linux-xfs@oss.sgi.com Tue Sep 17 05:46:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 05:46:34 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HCkWtG019734 for ; Tue, 17 Sep 2002 05:46:32 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rHp8-0004Pb-00 for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 06:51:26 -0600 Message-ID: <3D8723BE.8050702@emergence.com> Date: Tue, 17 Sep 2002 06:44:46 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 430 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs My discussions with some of the Gentoo developers there seems to be a number of them that have/had experienced data loss in the past and I think some of them have a problem that it only journals metadata. Looks like XFS didn't make it in to the latest 2.4.19 kernel they have in testing right: gentoo-sources-2.4.19-r9 I think some of the developers feel they can't recommending XFS due to past experiences and I think they have the impression that XFS won't or is hard to patch into their mainline kernel now due to other features they want to offer. I think that other than the metadata, their fears are unfounded but I don't know how to open a discussion with them them about how some of the problems that they experienced with early XFS up to and including 1.1 (where the 2.4.19-r7 XFS patches come from) does not reflect on the sheer amount of testing and bug fixing have occured in CVS (even if you just consider the 2.4.19 XFS kernel sync) Perhaps I could patch a current XFS into their current (2.4.19-r9) and running the test suite? Is there anything else that might be suggested. I suppose a good starting point would be to see which of their patches overlap with the XFS 2.4.19 or CVS code. -Mike Simon Matter wrote: > Many thanks and congratulations to everyone involved!!! > This is what I was waiting for so long, thanks. > > Simon > > > On Tuesday 17 September 2002 00:05, utz lehmann wrote: > >>saw this on lwn.net. linus had merged XFS in the 2.5 tree. >> >>congratulation! >> >>and many thanks to all who made this possible. >> >> >>utz From owner-linux-xfs@oss.sgi.com Tue Sep 17 05:55:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 05:55:02 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HCsvtG020311 for ; Tue, 17 Sep 2002 05:54:59 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17rHxK-0006Y9-00; Tue, 17 Sep 2002 13:59:54 +0100 Date: Tue, 17 Sep 2002 13:59:54 +0100 From: Christoph Hellwig To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917135954.A25165@infradead.org> References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D8723BE.8050702@emergence.com>; from mbest@emergence.com on Tue, Sep 17, 2002 at 06:44:46AM -0600 X-archive-position: 431 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 06:44:46AM -0600, Michael Best wrote: > My discussions with some of the Gentoo developers there seems to be a > number of them that have/had experienced data loss in the past and I > think some of them have a problem that it only journals metadata. Some of their patches/patch combination almost guarntee data loss. I wouldn't trust gentoo for throw-away bk repo :) From owner-linux-xfs@oss.sgi.com Tue Sep 17 06:14:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 06:14:47 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HDEetG021618 for ; Tue, 17 Sep 2002 06:14:41 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rIGM-0004Tn-00; Tue, 17 Sep 2002 07:19:34 -0600 Message-ID: <3D872A57.5040301@emergence.com> Date: Tue, 17 Sep 2002 07:12:55 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <20020917135954.A25165@infradead.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 432 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > On Tue, Sep 17, 2002 at 06:44:46AM -0600, Michael Best wrote: > >>My discussions with some of the Gentoo developers there seems to be a >>number of them that have/had experienced data loss in the past and I >>think some of them have a problem that it only journals metadata. > > > Some of their patches/patch combination almost guarntee data loss. > I wouldn't trust gentoo for throw-away bk repo :) Just curious which of their patches/patch combinations were the worst? They have a separate xfs_sources available, and since keeping XFS out of their main tree anyways, I think I'll just stick to trying to get things like newer xfsprogs into their package system and perhaps a couple of things (like rml preempt) into their xfs kernel sources. I was also hoping to get their maintainer to build a weekly CVS snapshot kernel (as there appears to be a weekly XFS-patch snapshot) that would be masked/hidden, just in case developers wanted to test things. Other than the gcc-3.2 - O_DIRECT on i586 problem I know about I am using an XFS CVS kernel from a couple of weeks back. (using athlon so I'm not affected by the O_DIRECT problem) -Mike From owner-linux-xfs@oss.sgi.com Tue Sep 17 06:18:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 06:18:06 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HDI3tG022256 for ; Tue, 17 Sep 2002 06:18:04 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8HDMQDh034693; Tue, 17 Sep 2002 15:22:28 +0200 (CEST) Message-Id: <4.3.2.7.2.20020917150318.0391a4b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 17 Sep 2002 15:21:13 +0200 To: Michael Best , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Linus merges XFS In-Reply-To: <3D8723BE.8050702@emergence.com> References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 433 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 06:44 17-9-2002 -0600, Michael Best wrote: >My discussions with some of the Gentoo developers there seems to be a >number of them that have/had experienced data loss in the past and I >think some of them have a problem that it only journals metadata. The pre 1.1 releases had this problem. It should be a lot less common since the 1.1 release. So far I have had good success and the problems I did encounter could be worked around or fixed. >Looks like XFS didn't make it in to the latest 2.4.19 kernel they have >in testing right: XFS will only be integrated in 2.4 after it has succesfully made it in 2.5 according to Marcello. The merge would happen in 2.5.36 and we currently have 2.5.35 so a bit of patience please. Also of note is that the 2.4 tree is different from the 2.5 tree in many respects. You can find a link to Christoph' checklist in the FAQ that shows what functionality is available in 2.4 and 2.5 and what needs to be done to make it fit in. >I think some of the developers feel they can't recommending XFS due to >past experiences and I think they have the impression that XFS won't or >is hard to patch into their mainline kernel now due to other features >they want to offer. Not compared to the 2.4.0 days it's not :-) Since the VM has settled it did get easier. >I think that other than the metadata, their fears are unfounded but I >don't know how to open a discussion with them them about how some of the >problems that they experienced with early XFS up to and including 1.1 >(where the 2.4.19-r7 XFS patches come from) does not reflect on the >sheer amount of testing and bug fixing have occured in CVS (even if you >just consider the 2.4.19 XFS kernel sync) You can not compare XFS 1.1 from april to current CVS (5 months ago!). >Perhaps I could patch a current XFS into their current (2.4.19-r9) and >running the test suite? Is there anything else that might be suggested. There are some new features in current CVS that need somoe more testing. I believe a patch with more recent XFS code is going to Andrea and you might be able to use that as well. No warranty though since it is not a full fledged release (== tested). >I suppose a good starting point would be to see which of their patches >overlap with the XFS 2.4.19 or CVS code. That might be a lot :-) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Sep 17 06:18:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 06:18:13 -0700 (PDT) Received: from phoenix.infradead.org (phoenix.infradead.org [195.224.96.167]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HDIAtG022319 for ; Tue, 17 Sep 2002 06:18:11 -0700 Received: from hch by phoenix.infradead.org with local (Exim 4.10) id 17rIJp-0006iX-00; Tue, 17 Sep 2002 14:23:09 +0100 Date: Tue, 17 Sep 2002 14:23:09 +0100 From: Christoph Hellwig To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917142309.A25763@infradead.org> References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <20020917135954.A25165@infradead.org> <3D872A57.5040301@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D872A57.5040301@emergence.com>; from mbest@emergence.com on Tue, Sep 17, 2002 at 07:12:55AM -0600 X-archive-position: 434 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 07:12:55AM -0600, Michael Best wrote: > Just curious which of their patches/patch combinations were the worst? older xfs + preempt was very bad, merging of wli's unreleases per-zone kswapd + rmap + radix tree code was also very bad. Just look at some of the kernel patches, they're often random patch collections. From owner-linux-xfs@oss.sgi.com Tue Sep 17 07:14:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 07:14:42 -0700 (PDT) Received: from booster.telnet.hu (mail@booster.telnet.hu [212.75.128.38]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HEEVtG001359 for ; Tue, 17 Sep 2002 07:14:34 -0700 Received: from mx1.netposta.net ([212.75.128.65]) by booster.telnet.hu with esmtp (Exim 3.35 #1 (Debian)) id 17rJCE-00076f-00 for ; Tue, 17 Sep 2002 16:19:23 +0200 Received: from www-data by mx1.netposta.net with local (Exim 3.35 #1 (Debian)) id 17rIuR-0004TY-00 for ; Tue, 17 Sep 2002 16:00:59 +0200 From: "Regos Bendeguz" To: linux-xfs@oss.sgi.com Reply-To: "Regos Bendeguz" MIME-Version: 1.0 Content-Type: text/plain; ; charset="iso-8859-2" Content-Description: X-Mailer: NetPosta - http://www.netposta.net X-Originating-IP: 193.6.16.91 Subject: 2.4.18 kernel oops (RH7.3-SGI-XFS-1.1) Message-Id: Date: Tue, 17 Sep 2002 16:00:59 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8HEEbtG001360 X-archive-position: 435 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bendeguz@netposta.net Precedence: bulk X-list: linux-xfs Hi all, I am using 2.4.18 kernel (RH7.3-SGI-XFS-1.1) If I try to do some simple stress test (dbench) I get the following kernel bug: #1 Sep 11 17:32:03 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Sep 11 17:32:03 kernel: printing eip: Sep 11 17:32:03 kernel: c01cad5c Sep 11 17:32:03 kernel: *pde = 00000000 Sep 11 17:32:03 kernel: Oops: 0000 Sep 11 17:32:03 kernel: ipt_LOG ipt_limit ipt_state ip_conntrack iptable_filter ip_tables autofs 8139t Sep 11 17:32:03 kernel: CPU: 0 Sep 11 17:32:03 kernel: EIP: 0010:[] Not tainted Sep 11 17:32:03 kernel: EFLAGS: 00010286 Sep 11 17:32:03 kernel: Sep 11 17:32:03 kernel: EIP is at xfs_syncsub [kernel] 0x42c (2.4.18- 4SGI_XFS_1.1smp) Sep 11 17:32:03 kernel: eax: 00000018 ebx: 0000000a ecx: 0000000a edx: 00000000 Sep 11 17:32:03 kernel: esi: dd2fc1f4 edi: ccb16820 ebp: d046ee24 esp: db76dcf4 Sep 11 17:32:04 kernel: ds: 0018 es: 0018 ss: 0018 Sep 11 17:32:04 kernel: Process dbench (pid: 9853, stackpage=db76d000) Sep 11 17:32:04 kernel: Stack: ede49d18 00000000 0000000e 00000000 00000001 0000000a 0000000a 00000040 Sep 11 17:32:04 kernel: 00000000 00000000 00000000 dd30068c 00000000 00010000 00000202 00000004 Sep 11 17:32:04 kernel: dd30057c c01b3d03 dd300608 dd30068c 00000000 c01dd664 ede49c00 d046f478 Sep 11 17:32:04 kernel: Call Trace: [] xfs_iunlock [kernel] 0x33 Sep 11 17:32:04 kernel: [] xfs_iomap_write [kernel] 0xc4 Sep 11 17:32:04 kernel: [] xfs_sync [kernel] 0x15 Sep 11 17:32:04 kernel: [] xfs_bmap [kernel] 0x202 Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x82 Sep 11 17:32:04 kernel: [] _pagebuf_file_write [kernel] 0xf8 Sep 11 17:32:04 kernel: [] xfs_symlink [kernel] 0x65b Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 17:32:04 kernel: [] pagebuf_generic_file_write [kernel] 0x19b Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 17:32:04 kernel: [] xfs_access [kernel] 0x2f Sep 11 17:32:04 kernel: [] xfs_write [kernel] 0x280 Sep 11 17:32:04 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 17:32:04 kernel: [] linvfs_write [kernel] 0x2bf Sep 11 17:32:04 kernel: [] sys_write [kernel] 0x96 Sep 11 17:32:04 kernel: [] system_call [kernel] 0x33 Sep 11 17:32:04 kernel: Sep 11 17:32:04 kernel: Sep 11 17:32:04 kernel: Code: 39 42 18 0f 84 87 00 00 00 8b 44 24 10 85 c0 74 2c 8b 46 08 Oops report is here: >>EIP; c01cad5c <===== Trace; c01b3d03 Trace; c01dd664 Trace; c01ca925 Trace; c01dca72 Trace; c01db532 Trace; c01d7258 <_pagebuf_file_write+f8/210> Trace; c01d080b Trace; c01db4b0 Trace; c01d750b Trace; c01db4b0 Trace; c01cc77f Trace; c01dc660 Trace; c01db4b0 Trace; c01d867f Trace; c0142086 Trace; c0108c6b Code; c01cad5c 00000000 <_EIP>: Code; c01cad5c <===== 0: 39 42 18 cmp %eax,0x18(%edx) <===== Code; c01cad5f 3: 0f 84 87 00 00 00 je 90 <_EIP+0x90> c01cadec Code; c01cad65 9: 8b 44 24 10 mov 0x10(%esp,1),%eax Code; c01cad69 d: 85 c0 test %eax,%eax Code; c01cad6b f: 74 2c je 3d <_EIP+0x3d> c01cad99 Code; c01cad6d 11: 8b 46 08 mov 0x8(%esi),%eax #2 Sep 11 18:02:40 kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000018 Sep 11 18:02:40 kernel: printing eip: Sep 11 18:02:40 kernel: c01cad5c Sep 11 18:02:40 kernel: *pde = 00000000 Sep 11 18:02:40 kernel: Oops: 0000 Sep 11 18:02:40 kernel: autofs 8139too mii ne2k-pci 8390 ipt_LOG ipt_limit ipt_state ip_conntrack ipta Sep 11 18:02:40 kernel: CPU: 1 Sep 11 18:02:40 kernel: EIP: 0010:[] Not tainted Sep 11 18:02:40 kernel: EFLAGS: 00010286 Sep 11 18:02:40 kernel: Sep 11 18:02:40 kernel: EIP is at xfs_syncsub [kernel] 0x42c (2.4.18- 4SGI_XFS_1.1smp) Sep 11 18:02:40 kernel: eax: 00000018 ebx: 0000000a ecx: 0000000a edx: 00000000 Sep 11 18:02:40 kernel: esi: eb4e9750 edi: ef60f6c0 ebp: d1744184 esp: ead69cf4 Sep 11 18:02:40 kernel: ds: 0018 es: 0018 ss: 0018 Sep 11 18:02:40 kernel: Process dbench (pid: 1254, stackpage=ead69000) Sep 11 18:02:40 kernel: Stack: ef470118 00000000 00000006 00000000 00000001 0000000a 0000000a 00000040 Sep 11 18:02:40 kernel: 00000000 00000000 00000000 d1ace68c 00000000 00010000 00000202 00000004 Sep 11 18:02:40 kernel: d1ace57c c01b3d03 d1ace608 d1ace68c 00000000 c01dd664 ef470000 eb2a4740 Sep 11 18:02:40 kernel: Call Trace: [] xfs_iunlock [kernel] 0x33 Sep 11 18:02:40 kernel: [] xfs_iomap_write [kernel] 0xc4 Sep 11 18:02:40 kernel: [] xfs_sync [kernel] 0x15 Sep 11 18:02:40 kernel: [] xfs_bmap [kernel] 0x202 Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x82 Sep 11 18:02:40 kernel: [] _pagebuf_file_write [kernel] 0xf8 Sep 11 18:02:40 kernel: [] xfs_symlink [kernel] 0x65b Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 18:02:40 kernel: [] pagebuf_generic_file_write [kernel] 0x19b Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 18:02:40 kernel: [] xfs_access [kernel] 0x2f Sep 11 18:02:40 kernel: [] xfs_write [kernel] 0x280 Sep 11 18:02:40 kernel: [] linvfs_pb_bmap [kernel] 0x0 Sep 11 18:02:40 kernel: [] linvfs_write [kernel] 0x2bf Sep 11 18:02:40 kernel: [] sys_write [kernel] 0x96 Sep 11 18:02:40 kernel: [] system_call [kernel] 0x33 Sep 11 18:02:40 kernel: Sep 11 18:02:40 kernel: Sep 11 18:02:40 kernel: Code: 39 42 18 0f 84 87 00 00 00 8b 44 24 10 85 c0 74 2c 8b 46 08 Oops report: >>EIP; c01cad5c <===== Trace; c01b3d03 Trace; c01dd664 Trace; c01ca925 Trace; c01dca72 Trace; c01db532 Trace; c01d7258 <_pagebuf_file_write+f8/210> Trace; c01d080b Trace; c01db4b0 Trace; c01d750b Trace; c01db4b0 Trace; c01cc77f Trace; c01dc660 Trace; c01db4b0 Trace; c01d867f Trace; c0142086 Trace; c0108c6b Code; c01cad5c 00000000 <_EIP>: Code; c01cad5c <===== 0: 39 42 18 cmp %eax,0x18(%edx) <===== Code; c01cad5f 3: 0f 84 87 00 00 00 je 90 <_EIP+0x90> c01cadec Code; c01cad65 9: 8b 44 24 10 mov 0x10(%esp,1),%eax Code; c01cad69 d: 85 c0 test %eax,%eax Code; c01cad6b f: 74 2c je 3d <_EIP+0x3d> c01cad99 Code; c01cad6d 11: 8b 46 08 mov 0x8(%esi),%eax This happens reproducably under high load (with dbench) Best regards, Bendeguz --------------------------------------------------------------------- http://www.netposta.net NetPosta, E-m@il ingyen! From owner-linux-xfs@oss.sgi.com Tue Sep 17 07:27:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 07:27:16 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HERCtG001919 for ; Tue, 17 Sep 2002 07:27:12 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rJOX-0004es-00; Tue, 17 Sep 2002 08:32:05 -0600 Message-ID: <3D873B56.8040005@emergence.com> Date: Tue, 17 Sep 2002 08:25:26 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Regos Bendeguz CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 kernel oops (RH7.3-SGI-XFS-1.1) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 436 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs First mentioned: "XFS-1.1+DEBUG+debench = panic" - 2002/05/16 http://marc.theaimsgroup.com/?l=linux-xfs&s=dbench Dbench was also mentioned in most of the entire thread "2.4.20pre5aa2" - 2002/09/12 -> 2002/09/15 And a couple of times in: "snapshot regression test try 2" - 2002/08/30 -Mike Regos Bendeguz wrote: > Hi all, > > I am using 2.4.18 kernel (RH7.3-SGI-XFS-1.1) > If I try to do some simple stress test (dbench) I get > the following kernel bug From owner-linux-xfs@oss.sgi.com Tue Sep 17 07:40:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 07:40:43 -0700 (PDT) Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HEedtG003334 for ; Tue, 17 Sep 2002 07:40:39 -0700 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id H2L7ND00.610; Tue, 17 Sep 2002 16:45:13 +0200 Message-ID: <3D87944B.8040206@hamburg.fcb.com> Date: Tue, 17 Sep 2002 16:44:59 -0400 From: Harald Wagener Organization: FCB Wilkens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020909 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Best CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 437 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Michael Best wrote: >My discussions with some of the Gentoo developers there seems to be a >number of them that have/had experienced data loss in the past and I >think some of them have a problem that it only journals metadata. > >Looks like XFS didn't make it in to the latest 2.4.19 kernel they have >in testing right: > >gentoo-sources-2.4.19-r9 > >I think some of the developers feel they can't recommending XFS due to >past experiences and I think they have the impression that XFS won't or >is hard to patch into their mainline kernel now due to other features >they want to offer. > >I think that other than the metadata, their fears are unfounded but I >don't know how to open a discussion with them them about how some of the >problems that they experienced with early XFS up to and including 1.1 >(where the 2.4.19-r7 XFS patches come from) does not reflect on the >sheer amount of testing and bug fixing have occured in CVS (even if you >just consider the 2.4.19 XFS kernel sync) > >Perhaps I could patch a current XFS into their current (2.4.19-r9) and >running the test suite? Is there anything else that might be suggested. > >I suppose a good starting point would be to see which of their patches >overlap with the XFS 2.4.19 or CVS code. > >-Mike > >Simon Matter wrote: > > >>Many thanks and congratulations to everyone involved!!! >>This is what I was waiting for so long, thanks. >> >>Simon >> >> >>On Tuesday 17 September 2002 00:05, utz lehmann wrote: >> >> >> >>>saw this on lwn.net. linus had merged XFS in the 2.5 tree. >>> >>>congratulation! >>> >>>and many thanks to all who made this possible. >>> >>> >>>utz >>> >>> > > > > did You do an emerge -s xfs? I know that a few day ago, xfs-sources still popped up. Regards, Harald -- Harald Wagener*An der Alster 42*20099 Hamburg*http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 08:30:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 08:30:34 -0700 (PDT) Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HFU2tG004214 for ; Tue, 17 Sep 2002 08:30:03 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #3) id 17rKNM-0004rB-00; Tue, 17 Sep 2002 09:34:57 -0600 Message-ID: <3D874BA3.5040809@emergence.com> Date: Tue, 17 Sep 2002 09:34:59 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mbest@emergence.com CC: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <3D87944B.8040206@hamburg.fcb.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 438 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mbest@emergence.com Precedence: bulk X-list: linux-xfs Yes, the xfs-sources are using the 2.4.19 kernel tree. The gentoo-sources-2.4.19-r7 contains the older xfs 1.1 code, the new proposed gentoo-sources-2.4.19-r9 does not contain xfs at all. But based on comments I've read, it probably better for XFS to not be included and force people to use the xfs-sources tree. -Mike Harald Wagener wrote: > did You do an emerge -s xfs? I know that a few day ago, xfs-sources > still popped up. > > Regards, > Harald From owner-linux-xfs@oss.sgi.com Tue Sep 17 09:56:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 09:56:31 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HGuRtG009238 for ; Tue, 17 Sep 2002 09:56:27 -0700 Received: from vk-clued0.fnal.gov ([131.225.224.23]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0H2L006AFDYDFT@smtp.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 12:01:26 -0500 (CDT) Date: Tue, 17 Sep 2002 12:01:23 -0500 (CDT) From: vkuznet Subject: Re: XFS mount failure In-reply-to: <4.3.2.7.2.20020917085626.038c0d90@pop.xs4all.nl> To: Seth Mos Cc: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 439 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vkuznet@fnal.gov Precedence: bulk X-list: linux-xfs The controller we use is 3Ware Escalade 7850. Thanks for help, I used suggestion to mount xfs with -nouuid and at least we are able now to make a backup and them will think about upgrade of XFS. Valentin. On Tue, 17 Sep 2002, Seth Mos wrote: > At 12:01 16-9-2002 -0500, vkuznet wrote: > >Hi, > >we do have 3Ware RAID machine where XFS is using. > >After unexpected reboot we cannot longer mount our XFS filesystem. > > > >Here the /var/log/messages > > > >Sep 16 11:28:26 hermes-clued0 kernel: 3w-xxxx: scsi0: AEN: SMART threshold > >exceeded: Port #6. > >Sep 16 11:31:28 hermes-clued0 kernel: XFS: Filesystem has duplicate UUID - > >can't mount > > I don't know about a 3ware controllers but I'd say the smart on the disk on > port 6 is telling the controller that it's going bad. > Better check. xfs_repair might be able to fix your filesystem. > > What 3ware controller are you using? > > >Any idea how to fix the problem. > > > >We do have > >Linux hermes-clued0 2.4.17-0.4XFSsmp #1 SMP Tue Mar 12 14:18:33 CST 2002 > >i686 unknown > >patched kernel with XFS. > > Can you upgrade to something more recent please. You definitely want the > XFS 1.1 release or later. Use CVS or the split patches if you want newer > then 2.4.18. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > From owner-linux-xfs@oss.sgi.com Tue Sep 17 10:55:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 10:55:28 -0700 (PDT) Received: from mail.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HHtHtG014282 for ; Tue, 17 Sep 2002 10:55:21 -0700 Received: from sgo.es (tinto.sgo.es [193.127.97.48]) by mail.sgo.es (8.9.3/8.9.3) with ESMTP id UAA04842 for ; Tue, 17 Sep 2002 20:02:41 +0200 Message-ID: <3D876B70.84EA1A25@sgo.es> Date: Tue, 17 Sep 2002 17:50:40 +0000 From: jose Hernandez Organization: SGO X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.17 + XFS? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 440 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhernandez@sgo.es Precedence: bulk X-list: linux-xfs Hello. I would like to install the XFS support for my kernel (2.4.17).but I have seen that the supported kernel is 2.4.9. Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to 2.4.9? Thanks a lot for your help. From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:04:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:04:07 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HI45tG015276 for ; Tue, 17 Sep 2002 11:04:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA57198; Tue, 17 Sep 2002 13:08:57 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA99337; Tue, 17 Sep 2002 13:08:56 -0500 (CDT) Subject: Re: 2.4.17 + XFS? From: Eric Sandeen To: jose Hernandez Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D876B70.84EA1A25@sgo.es> References: <3D876B70.84EA1A25@sgo.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 17 Sep 2002 13:03:57 -0500 Message-Id: <1032285837.6354.87.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 441 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs You have several choices. You could grab old cvs snapshot patches from ftp://oss.sgi.com/projects/xfs/download/patches/2.4.17/ and apply them to your kernel. Or, you could try backporting the 2.4.18-XFS 1.1 patch to 2.4.17, which would probably not be too hard. ftp://oss.sgi.com/projects/xfs/download/latest/kernel_patches/xfs-1.1-2.4.18-all.patch.bz2 Or, you could upgrade your ancient kernel. :) -Eric On Tue, 2002-09-17 at 12:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:05:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:05:38 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HI5ZtG015744 for ; Tue, 17 Sep 2002 11:05:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA58251; Tue, 17 Sep 2002 13:10:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA50970; Tue, 17 Sep 2002 13:10:29 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8HI70M27747; Tue, 17 Sep 2002 13:07:00 -0500 Subject: Re: 2.4.17 + XFS? From: Steve Lord To: jose Hernandez Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D876B70.84EA1A25@sgo.es> References: <3D876B70.84EA1A25@sgo.es> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 13:07:00 -0500 Message-Id: <1032286020.22719.145.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 442 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-17 at 12:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > 2.4.9? That's a little old, so is 2.4.17, there are patches and cvs code for 2.4.19 on oss.sgi.com. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:19:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:19:18 -0700 (PDT) Received: from chimta03.algx.net (chimta03.algx.net [216.99.233.78]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HIJGtG016415 for ; Tue, 17 Sep 2002 11:19:16 -0700 Received: from [192.168.10.106] (ip66-2-81-26.z81-2-66.customer.algx.net [66.2.81.26]) by chimmx03.algx.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with ESMTP id <0H2L007YBHRE5H@chimmx03.algx.net> for linux-xfs@oss.sgi.com; Tue, 17 Sep 2002 13:23:38 -0500 (CDT) Date: Tue, 17 Sep 2002 14:22:56 -0400 From: John M Trostel Subject: Re: 2.4.17 + XFS? In-reply-to: <3D876B70.84EA1A25@sgo.es> To: jose Hernandez Cc: linux-xfs@oss.sgi.com Message-id: <1032286976.2348.8.camel@jtsdell> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.8 Content-type: text/plain Content-transfer-encoding: 7BIT References: <3D876B70.84EA1A25@sgo.es> X-archive-position: 443 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: john.trostel@quantum.com Precedence: bulk X-list: linux-xfs Hi Jose The currently supported kernel in the CVS tree is 2.4.19 (not 2.4.9). The currently supported kernel for RPM installs with version 1.1 of XFS is kernel 2.4.18. Only if one wants a RH 7.1 or 7.2 rpm install, is the kernel version 2.4.9-x used. I would upgrade my kernel from 2.4.17 to 2.4.19 and take advantage of that advance also, if possible. You could also be somewhat more conservative and upgrade to the version 1.1 of XFS on the 2.4.18 kernel level. (Actually, I have kept my laptop up with the CVS tree... but I enjoy living dangerously.) On Tue, 2002-09-17 at 13:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > > -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 11:58:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:58:36 -0700 (PDT) Received: from notes.guilford.edu ([192.154.63.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HIwUtG017375 for ; Tue, 17 Sep 2002 11:58:31 -0700 Subject: Can Windows read XFS? To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: vricks@guilford.edu Date: Tue, 17 Sep 2002 15:03:13 -0400 X-MIMETrack: Serialize by Router on notes.guilford.edu/Guilford(Release 5.0.10 |March 22, 2002) at 09/17/2002 03:03:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 444 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vricks@guilford.edu Precedence: bulk X-list: linux-xfs I've unsuccessfully checked the archives for the answer to the above question. Are there any programs that allow Windows NT/2k/XP systems to read XFS filesystem data? I have a dual-boot XP/Linux system with the /home partition formatted XFS. Thanks Vance Ricks Assistant Professor of Philosophy Guilford College Greensboro, NC 27410 John M Trostel ntum.com> cc: linux-xfs@oss.sgi.com Sent by: Subject: Re: 2.4.17 + XFS? linux-xfs-bounce@ oss.sgi.com 09/17/02 02:22 PM Hi Jose The currently supported kernel in the CVS tree is 2.4.19 (not 2.4.9). The currently supported kernel for RPM installs with version 1.1 of XFS is kernel 2.4.18. Only if one wants a RH 7.1 or 7.2 rpm install, is the kernel version 2.4.9-x used. I would upgrade my kernel from 2.4.17 to 2.4.19 and take advantage of that advance also, if possible. You could also be somewhat more conservative and upgrade to the version 1.1 of XFS on the 2.4.18 kernel level. (Actually, I have kept my laptop up with the CVS tree... but I enjoy living dangerously.) On Tue, 2002-09-17 at 13:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > > -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:41:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:41:47 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJfjtG018614 for ; Tue, 17 Sep 2002 12:41:45 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA00853 for ; Tue, 17 Sep 2002 12:46:44 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA31979; Tue, 17 Sep 2002 14:37:28 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA06882; Tue, 17 Sep 2002 14:37:28 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8HJXw827934; Tue, 17 Sep 2002 14:33:58 -0500 Subject: Re: Can Windows read XFS? From: Steve Lord To: vricks@guilford.edu Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 14:33:58 -0500 Message-Id: <1032291238.22767.261.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 445 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > I've unsuccessfully checked the archives for the answer to the above > question. Are there any programs that allow Windows NT/2k/XP systems to > read XFS filesystem data? I have a dual-boot XP/Linux system with the > /home partition formatted XFS. I am not aware of anything which runs on windows which can read XFS. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:49:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:49:03 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJn0tG019486 for ; Tue, 17 Sep 2002 12:49:01 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 04D0314AEE; Tue, 17 Sep 2002 21:53:55 +0200 (MEST) Date: Tue, 17 Sep 2002 21:53:51 +0200 From: Andi Kleen To: Steve Lord Cc: vricks@guilford.edu, linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? Message-ID: <20020917215351.A32709@wotan.suse.de> References: <1032291238.22767.261.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032291238.22767.261.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 446 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 02:33:58PM -0500, Steve Lord wrote: > On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > > > I've unsuccessfully checked the archives for the answer to the above > > question. Are there any programs that allow Windows NT/2k/XP systems to > > read XFS filesystem data? I have a dual-boot XP/Linux system with the > > /home partition formatted XFS. > > I am not aware of anything which runs on windows which can read XFS. I guess vmware on Windows with a linux in it would do the trick... -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:49:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:50:02 -0700 (PDT) Received: from iris.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJnwtG020098 for ; Tue, 17 Sep 2002 12:49:58 -0700 Received: from erbenson.alaska.net (100-pm30.nwc.alaska.net [209.112.158.100]) by iris.acsalaska.net (8.12.5/8.12.5) with ESMTP id g8HJsrBs076509 for ; Tue, 17 Sep 2002 11:54:55 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 463363A0F for ; Tue, 17 Sep 2002 11:54:50 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 575364104E7; Tue, 17 Sep 2002 11:54:50 -0800 (AKDT) Date: Tue, 17 Sep 2002 11:54:50 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Message-ID: <20020917195450.GE10776@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> <3D8723BE.8050702@emergence.com> <3D87944B.8040206@hamburg.fcb.com> <3D874BA3.5040809@emergence.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gMR3gsNFwZpnI/Ts" Content-Disposition: inline In-Reply-To: <3D874BA3.5040809@emergence.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-archive-position: 447 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --gMR3gsNFwZpnI/Ts Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 17, 2002 at 09:34:59AM -0600, Michael Best wrote: > Yes, the xfs-sources are using the 2.4.19 kernel tree. >=20 > The gentoo-sources-2.4.19-r7 contains the older xfs 1.1 code, the new > proposed gentoo-sources-2.4.19-r9 does not contain xfs at all. and they expect that to work? 1.1 was made for 2.4.18, its not all that surprising it doesn't get along with 2.4.19, especially with the half dozen other random patches they added alongside. i always suspected the gentoo people were just spewing FUD when one told me `XFS is vile crap' now im sure. > But based on comments I've read, it probably better for XFS to not be > included and force people to use the xfs-sources tree. yes, since they obviously don't know how to do it right. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --gMR3gsNFwZpnI/Ts Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2HiIoACgkQJKx7GixEevz80QCfS6nS26wT/be5c9W2D38NshDg QloAnAolwmY7HERbXd3eKdrm2daMRmwQ =guMz -----END PGP SIGNATURE----- --gMR3gsNFwZpnI/Ts-- From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:50:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:50:45 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJogtG020609 for ; Tue, 17 Sep 2002 12:50:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA56798; Tue, 17 Sep 2002 14:55:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA56862; Tue, 17 Sep 2002 14:55:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8HJq6b28064; Tue, 17 Sep 2002 14:52:06 -0500 Subject: Re: Can Windows read XFS? From: Steve Lord To: Andi Kleen Cc: vricks@guilford.edu, linux-xfs@oss.sgi.com In-Reply-To: <20020917215351.A32709@wotan.suse.de> References: <1032291238.22767.261.camel@jen.americas.sgi.com> <20020917215351.A32709@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 17 Sep 2002 14:52:06 -0500 Message-Id: <1032292326.22719.264.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 448 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 2002-09-17 at 14:53, Andi Kleen wrote: > On Tue, Sep 17, 2002 at 02:33:58PM -0500, Steve Lord wrote: > > On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > > > > > I've unsuccessfully checked the archives for the answer to the above > > > question. Are there any programs that allow Windows NT/2k/XP systems to > > > read XFS filesystem data? I have a dual-boot XP/Linux system with the > > > /home partition formatted XFS. > > > > I am not aware of anything which runs on windows which can read XFS. > > I guess vmware on Windows with a linux in it would do the trick... True, but then you are reading it into a linux application not a windows one.... Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Sep 17 12:59:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 12:59:49 -0700 (PDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HJxktG022167 for ; Tue, 17 Sep 2002 12:59:46 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E2A6A14AED; Tue, 17 Sep 2002 22:04:40 +0200 (MEST) Date: Tue, 17 Sep 2002 22:04:34 +0200 From: Andi Kleen To: Steve Lord Cc: Andi Kleen , vricks@guilford.edu, linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? Message-ID: <20020917220434.A2985@wotan.suse.de> References: <1032291238.22767.261.camel@jen.americas.sgi.com> <20020917215351.A32709@wotan.suse.de> <1032292326.22719.264.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032292326.22719.264.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 449 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Tue, Sep 17, 2002 at 02:52:06PM -0500, Steve Lord wrote: > On Tue, 2002-09-17 at 14:53, Andi Kleen wrote: > > On Tue, Sep 17, 2002 at 02:33:58PM -0500, Steve Lord wrote: > > > On Tue, 2002-09-17 at 14:03, vricks@guilford.edu wrote: > > > > > > > > I've unsuccessfully checked the archives for the answer to the above > > > > question. Are there any programs that allow Windows NT/2k/XP systems to > > > > read XFS filesystem data? I have a dual-boot XP/Linux system with the > > > > /home partition formatted XFS. > > > > > > I am not aware of anything which runs on windows which can read XFS. > > > > I guess vmware on Windows with a linux in it would do the trick... > > True, but then you are reading it into a linux application not a > windows one.... ... but you can run samba on the linux and then Windows apps can read it via a network drive. Apparently someone is working on making User Mode Linux work on Windows too, so you may be able to go via this route too. -Andi From owner-linux-xfs@oss.sgi.com Tue Sep 17 13:23:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 13:23:23 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HKNGtG024987 for ; Tue, 17 Sep 2002 13:23:16 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8HKSFq02374 for ; Tue, 17 Sep 2002 16:28:15 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8HKSFC02368 for ; Tue, 17 Sep 2002 16:28:15 -0400 Date: Tue, 17 Sep 2002 16:28:15 -0400 (EDT) From: Benito Venegas To: Subject: Kernel HANG Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463806619-1244800539-1032294495=:22051" X-archive-position: 450 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463806619-1244800539-1032294495=:22051 Content-Type: TEXT/PLAIN; charset=US-ASCII HW: Dell PE 2450 1 CPU 512 MB ram 2x 16 GB HD , RAID 1 using perc3 card. (aacraid module) Kernel 2.4.9-31SGI_XFS_1.1 compiled with gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) (mm...I supposed to have egc or gcc3 ....mm :/ ) nfs client. mounting 1 partition from man SAN server (1/4 TB) This server was in production until 2 days ago, when creashed by 2 second time and we couldn;t see kernel panic in console (was too big) We connected a serial console and vuala', after to reboot server and active one of our process that sycronize data using rsync, machine crashed again. any idea? can be the compiler I used to build kernel? btw, I have several servers installed with this kernel version since Build Date: Tue 23 Apr 2002 05:13:59 PM GMT and this is the first big problem. The only new module (since aug 15) in this server is snare to do audit to some process and users. we disabled after this 3rd crash. Any suggestion? attached you will find more info. Thanks for you help Vene.- Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf <1>Unable to handle kernel paging request at virtual address 04a20000 printing eip: dfdf4282 *pde = 00000000 Oops: 0002 Kernel 2.4.9-31SGI_XFS_1.1 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010286 EIP is at ___strtok_R29805c13 [] 0x1f9edc6e eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 ds: 0018 es: 0018 ss: 0018 Process rsync (pid: 4785, stackpage=d823f000) Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b 00000000 c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 0000000b d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 df68fb24 ---1463806619-1244800539-1032294495=:22051 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="crash.cap" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="crash.cap" Q29kZTogYTIgMDAgMDAgYTIgMDQgZGQgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMGMgYmYgMWMgYzAgNTggYmYgDQoNCiA8MT5VbmFibGUgdG8gaGFuZGxl IGtlcm5lbCBwYWdpbmcgcmVxdWVzdCBhdCB2aXJ0dWFsIGFkZHJlc3MgMDRh MjAwMDANCiBwcmludGluZyBlaXA6DQpkZmRmNDI4Mg0KKnBkZSA9IDAwMDAw MDAwDQpPb3BzOiAwMDAyDQpLZXJuZWwgMi40LjktMzFTR0lfWEZTXzEuMQ0K Q1BVOiAgICAwDQpFSVA6ICAgIDAwMTA6WzxkZmRmNDI4Mj5dICAgIFRhaW50 ZWQ6IFAgDQpFRkxBR1M6IDAwMDEwMjg2DQpFSVAgaXMgYXQgX19fc3RydG9r X1IyOTgwNWMxMyBbXSAweDFmOWVkYzZlIA0KZWF4OiBkZmRmNDI4MiAgIGVi eDogMDAwMDAwMDIgICBlY3g6IGRmNjhmYjI0ICAgZWR4OiBkZjY4ZmFjMA0K ZXNpOiBkODIzZTAwMCAgIGVkaTogZDgyM2UwMDAgICBlYnA6IDAwMDAwMDBi ICAgZXNwOiBkODIzZjA3NA0KZHM6IDAwMTggICBlczogMDAxOCAgIHNzOiAw MDE4DQpQcm9jZXNzIHJzeW5jIChwaWQ6IDQ3ODUsIHN0YWNrcGFnZT1kODIz ZjAwMCkNClN0YWNrOiBjMDExOWNlYyAwMDAwMDAwMiAwMDAwMDAxMiBkODIz ZjE1OCAwMDAwMDAwYiBjMDEwNzMzYiAwMDAwMDAwYiAwMDAwMDAwMCANCiAg ICAgICBjMDExNDExNiBjMDI4NzAzZSBkODIzZjE1OCAwMDAwMDAwMiBkODIz ZTAwMCAwMDAwMDAwMiBjMDExM2Q2MCAwMDAwMDAwYiANCiAgICAgICBkODIz ZTAwMCBkZmRmNDI4MiBkZmRmNDI4MiBkODIzZTAwMCBkZDI0OTk3YyAwNGEy MDAwMCA4MDAwODM4MCBkZjY4ZmIyNCANCkNhbGwgVHJhY2U6IFs8YzAxMTlj ZWM+XSBkb19leGl0IFtrZXJuZWxdIDB4ZDAgDQpbPGMwMTA3MzNiPl0gZGll IFtrZXJuZWxdIDB4NGYgDQpbPGMwMTE0MTE2Pl0gZG9fcGFnZV9mYXVsdCBb a2VybmVsXSAweDNiNiANCls8YzAyODcwM2U+XSBjb3B5cml0ZSBba2VybmVs XSAweDY3ZSANCls8YzAxMTNkNjA+XSBkb19wYWdlX2ZhdWx0IFtrZXJuZWxd IDB4MCANCls8YzAxMWQzNDk+XSBkb19hY2N0X3Byb2Nlc3MgW2tlcm5lbF0g MHgyNzUgDQpbPGMwMWNjNjgwPl0gbGludmZzX3dyaXRlIFtrZXJuZWxdIDB4 MCANCls8YzAxMDZlZDg+XSBlcnJvcl9jb2RlIFtrZXJuZWxdIDB4MzggDQpb PGMwMTE5Y2VjPl0gZG9fZXhpdCBba2VybmVsXSAweGQwIA0KWzxjMDEwNzMz Yj5dIGRpZSBba2VybmVsXSAweDRmIA0KWzxjMDExNDExNj5dIGRvX3BhZ2Vf ZmF1bHQgW2tlcm5lbF0gMHgzYjYgDQpbPGMwMjg3MDNlPl0gY29weXJpdGUg W2tlcm5lbF0gMHg2N2UgDQpbPGMwMTEzZDYwPl0gZG9fcGFnZV9mYXVsdCBb a2VybmVsXSAweDAgDQpbPGMwMTFkMzQ5Pl0gZG9fYWNjdF9wcm9jZXNzIFtr ZXJuZWxdIDB4Mjc1IA0KWzxjMDFjYzY4MD5dIGxpbnZmc193cml0ZSBba2Vy bmVsXSAweDAgDQpbPGMwMTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2VybmVsXSAw eDM4IA0KWzxjMDExOWNlYz5dIGRvX2V4aXQgW2tlcm5lbF0gMHhkMCANCls8 YzAxMDczM2I+XSBkaWUgW2tlcm5lbF0gMHg0ZiANCls8YzAxMTQxMTY+XSBk b19wYWdlX2ZhdWx0IFtrZXJuZWxdIDB4M2I2IA0KWzxjMDI4NzAzZT5dIGNv cHlyaXRlIFtrZXJuZWxdIDB4NjdlIA0KWzxjMDExM2Q2MD5dIGRvX3BhZ2Vf ZmF1bHQgW2tlcm5lbF0gMHgwIA0KWzxjMDI3OWY0MT5dIF9fY29uc3RfdWRl bGF5IFtrZXJuZWxdIDB4MTUgDQpbPGMwMTFkMzQ5Pl0gZG9fYWNjdF9wcm9j ZXNzIFtrZXJuZWxdIDB4Mjc1IA0KWzxjMDFjYzY4MD5dIGxpbnZmc193cml0 ZSBba2VybmVsXSAweDAgDQpbPGMwMTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2Vy bmVsXSAweDM4IA0KWzxjMDExOWNlYz5dIGRvX2V4aXQgW2tlcm5lbF0gMHhk MCANCls8YzAxMDczM2I+XSBkaWUgW2tlcm5lbF0gMHg0ZiANCls8YzAxMTQx MTY+XSBkb19wYWdlX2ZhdWx0IFtrZXJuZWxdIDB4M2I2IA0KWzxjMDI4NzAz ZT5dIGNvcHlyaXRlIFtrZXJuZWxdIDB4NjdlIA0KWzxjMDExM2Q2MD5dIGRv X3BhZ2VfZmF1bHQgW2tlcm5lbF0gMHgwIA0KWzxjMDExZDM0OT5dIGRvX2Fj Y3RfcHJvY2VzcyBba2VybmVsXSAweDI3NSANCls8YzAxY2M2ODA+XSBsaW52 ZnNfd3JpdGUgW2tlcm5lbF0gMHgwIA0KWzxjMDEwNmVkOD5dIGVycm9yX2Nv ZGUgW2tleGl0IFtrZXJuZWxdIDB4ZDAgDQpbPGMwMTEwMDE4Pl0gbXRycl9p b2N0bCBba2VybmVsXSAweDQ4NCANCls8YzAxMDc1NGM+XSBkb19pbnZhbGlk X29wIFtrZXJuZWxdIDB4MCANCls8YzAxMDczM2I+XSBkaWUgW2tlcm5lbF0g MHg0ZiANCls8YzAxMDc1Y2U+XSBkb19pbnZhbGlkX29wIFtrZXJuZWxdIDB4 ODIgDQpbPGMwMjgxMGZhPl0gLnJvZGF0YSBba2VybmVsXSAweDEzM2EgDQpb PGMwMTFkMzQ5Pl0gZG9fYWNjdF9wcm9jZXNzIFtrZXJuZWxdIDB4Mjc1IA0K WzxjMDFjYzY4MD5dIGxpbnZmc193cml0ZSBba2VybmVsXSAweDAgDQpbPGMw MTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2VybmVsXSAweDM4IA0KWzxjMDExOWNl Yz5dIGRvX2V4aXQgW2tlcm5lbF0gMHhkMCANCls8YzAxMTAwMTg+XSBtdHJy X2lvY3RsIFtrZXJuZWxdIDB4NDg0IA0KWzxjMDEwNzU0Yz5dIGRvX2ludmFs aWRfb3AgW2tlcm5lbF0gMHgwIA0KWzxjMDEwNzMzYj5dIGRpZSBba2VybmVs XSAweDRmIA0KWzxjMDEwNzVjZT5dIGRvX2ludmFsaWRfb3AgW2tlcm5lbF0g MHg4MiANCls8YzAyODEwZmE+XSAucm9kYXRhIFtrZXJuZWxdIDB4MTMzYSAN Cls8YzAxMWQzNDk+XSBkb19hY2N0X3Byb2Nlc3MgW2tlcm5lbF0gMHgyNzUg DQpbPGMwMWNjNjgwPl0gbGludmZzX3dyaXRlIFtrZXJuZWxdIDB4MCANCls8 YzAxMDZlZDg+XSBlcnJvcl9jb2RlIFtrZXJuZWxdIDB4MzggDQpbPGMwMTE5 Y2VjPl0gZG9fZXhpdCBba2VybmVsXSAweGQwIA0KWzxjMDExMDAxOD5dIG10 cnJfaW9jdGwgW2tlcm5lbF0gMHg0ODQgDQpbPGMwMTA3MzNiPl0gZGllIFtr ZXJuZWxdIDB4NGYgDQpbPGMwMTE0MTE2Pl0gZG9fcGFnZV9mYXVsdCBba2Vy bmVsXSAweDNiNiANCls8YzAyODcwM2U+XSBjb3B5cml0ZSBba2VybmVsXSAw eDY3ZSANCls8YzAxMTNkNjA+XSBkb19wYWdlX2ZhdWx0IFtrZXJuZWxdIDB4 MCANCls8YzAxMWYwYWU+XSBkZXF1ZXVlX3NpZ25hbCBba2VybmVsXSAweDMy IA0KWzxjMDExZjBhZT5dIGRlcXVldWVfc2lnbmFsIFtrZXJuZWxdIDB4MzIg DQpbPGMwMTA2ZWQ4Pl0gZXJyb3JfY29kZSBba2VybmVsXSAweDM4IA0KWzxj MDExZjBhZT5dIGRlcXVldWVfc2lnbmFsIFtrZXJuZWxdIDB4MzIgDQpbPGMw MTA2YzllPl0gZG9fc2lnbmFsIFtrZXJuZWxdIDB4MjMyIA0KWzxjMDEwNmUx Yz5dIHNpZ25hbF9yZXR1cm4gW2tlcm5lbF0gMHgxNCANCg0K ---1463806619-1244800539-1032294495=:22051-- From owner-linux-xfs@oss.sgi.com Tue Sep 17 18:28:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 18:28:49 -0700 (PDT) Received: from area51.underboost.net (mail@dsl-65-188-232-225.telocity.com [65.188.232.225]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I1SgtG032630 for ; Tue, 17 Sep 2002 18:28:43 -0700 Received: from area51.underboost.net ([65.188.232.225] ident=dijital1) by area51.underboost.net with esmtp (Exim 3.36 #1 (Debian)) id 17r7BZ-0004Vo-00 for ; Mon, 16 Sep 2002 21:29:53 -0400 Date: Mon, 16 Sep 2002 21:29:50 -0400 (AST) From: Ron Henry To: linux-xfs@oss.sgi.com Subject: stat() and xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 451 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dijital1@underboost.net Precedence: bulk X-list: linux-xfs if I do stat("filename", &entry); and I then procede to printf() some of the fields of the returned structure, is there a problem with casting the elements to int vs something else? for ex should it be printf("inode: %d\n", (int)entry.st_ino); OR printf("inode: %lld\n", (long long)entry.st_ino); The platform is x86. OS is Linux Ron Henry "the illiterate of the future are not those who can neither read or write; but those who cannot learn, unlearn, and relearn..." From owner-linux-xfs@oss.sgi.com Tue Sep 17 20:16:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 20:16:31 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I3GOtG005147 for ; Tue, 17 Sep 2002 20:16:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id UAA07929 for ; Tue, 17 Sep 2002 20:21:09 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA08853; Wed, 18 Sep 2002 13:19:47 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA58529; Wed, 18 Sep 2002 13:19:46 +1000 (AEDT) Date: Wed, 18 Sep 2002 13:19:45 +1000 From: Nathan Scott To: Ron Henry Cc: linux-xfs@oss.sgi.com Subject: Re: stat() and xfs Message-ID: <20020918131945.A158353@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dijital1@underboost.net on Mon, Sep 16, 2002 at 09:29:50PM -0400 X-archive-position: 452 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs hi, On Mon, Sep 16, 2002 at 09:29:50PM -0400, Ron Henry wrote: > if I do stat("filename", &entry); and I then procede to printf() some of > the fields of the returned structure, is there a problem with casting the > elements to int vs something else? for ex should it be > > printf("inode: %d\n", (int)entry.st_ino); OR > > printf("inode: %lld\n", (long long)entry.st_ino); > > The platform is x86. OS is Linux > The latter is more correct - the first would chop off the top 32 bits (and get the wrong result, should the inode number be greater than 2^32 - 1). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Sep 17 20:25:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 20:26:02 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I3PwtG005680 for ; Tue, 17 Sep 2002 20:25:58 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA09369 for ; Tue, 17 Sep 2002 20:30:54 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA51128 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 13:29:35 +1000 (EST) Date: Wed, 18 Sep 2002 13:29:35 +1000 (EST) From: Nathan Scott Message-Id: <200209180329.NAA51128@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA X-archive-position: 453 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Sep 17 20:28:20 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127713a cmd/xfstests/bench - 1.1 - First cut at a framework for running benchmarks along with all of the functional tests we have. Aim is to get wind of performance regressions as changes are checked in, rather than at arbitrary points down the track. Still work to do wrt this framework though. cmd/xfstests/run.dbench - 1.1 - wrapper script for running dbench with a configurable number of clients and spitting out csv format values. cmd/xfstests/run.tar - 1.1 - wrapper script for running untar with a configurable tar file and then spitting out csv format values. cmd/xfstests/common.config - 1.22 - Move all configurations in here - previously some options lived in the auto-qa script and some here. cmd/xfstests/tools/auto-qa - 1.34 - Move configuration options out of here and into common.config. Add in a hook to call out to the bench script, if requested. From owner-linux-xfs@oss.sgi.com Tue Sep 17 20:46:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 20:46:31 -0700 (PDT) Received: from mail.miratek.com ([216.97.55.61]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I3kNtG006473 for ; Tue, 17 Sep 2002 20:46:24 -0700 Received: from maherxp [24.145.147.99] by mail.miratek.com with ESMTP (SMTPD32-7.13) id A6E217C01AE; Tue, 17 Sep 2002 22:45:38 -0500 Reply-To: From: "Mike" To: Subject: Install 24.18-4SMP Date: Tue, 17 Sep 2002 23:51:01 -0400 Message-ID: <001301c25ec6$9ca093a0$9c7ba8c0@maherxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-archive-position: 454 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: samba@miratek.com Precedence: bulk X-list: linux-xfs I am trying to install kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm on a redhat 7.2 and I am getting the following error: [root ~]# rpm -ivh kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm error: failed dependencies: dev < 3.2-7 conflicts with kernel-smp-2.4.18-4SGI_XFS_1.1 Any help is greatly appreciated. I do not have a dev 3.2-7 rpm: [root ~]# rpm -q dev dev-3.2-5 I am on 2.4.9-34SGI_XFS_1.1smp kernel now. And I am having nfsd kernel error when I run xfsdump. It hangs nfsd and the only way to restart nfs is to reboot. I am hoping that 2.4.18-4 will fix this problem. Thanks, Mike From owner-linux-xfs@oss.sgi.com Tue Sep 17 23:58:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 23:58:53 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I6wmtG011669 for ; Tue, 17 Sep 2002 23:58:50 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8I73jT7092805; Wed, 18 Sep 2002 09:03:49 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id AF16F65104; Wed, 18 Sep 2002 09:03:45 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: Benito Venegas , Subject: Re: Kernel HANG Date: Wed, 18 Sep 2002 09:03:44 +0200 X-Mailer: KMail [version 1.3.2] References: In-Reply-To: MIME-Version: 1.0 Message-Id: <20020918070345.AF16F65104@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8I6wptG011670 X-archive-position: 455 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs On Tuesday 17 September 2002 22:28, Benito Venegas wrote: > HW: Dell PE 2450 > 1 CPU > 512 MB ram > 2x 16 GB HD , RAID 1 using perc3 card. (aacraid module) > Kernel 2.4.9-31SGI_XFS_1.1 > compiled with > gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-98) > (mm...I supposed to have egc or gcc3 ....mm :/ ) > > nfs client. mounting 1 partition from man SAN server (1/4 TB) > > > This server was in production until 2 days ago, when creashed by 2 second > time and we couldn;t see kernel panic in console (was too big) > We connected a serial console and vuala', after to reboot server and > active one of our process that sycronize data using rsync, machine > crashed again. Do you use rsync in verbose mode? This was my problem some months ago when I had many crashes using XFS/rsync. Then I read this verbose thing on lkml (or was it rsync ML) and removing verbose option from rsync helped. And of course, you didn't use the recommended compiler, did you? Have a look at ftp://oss.sgi.com/projects/xfs/download/Release-1.1/kernel_rpms/contributed/2.4.9-34-RH/ HTH Simon > > any idea? can be the compiler I used to build kernel? > btw, I have several servers installed with this kernel version since > > Build Date: Tue 23 Apr 2002 05:13:59 PM GMT > > and this is the first big problem. > > The only new module (since aug 15) in this server is snare to do audit to > some process and users. we disabled after this 3rd crash. > > Any suggestion? > attached you will find more info. > > Thanks for you help > > Vene.- > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > <1>Unable to handle kernel paging request at virtual address 04a20000 > printing eip: > dfdf4282 > *pde = 00000000 > Oops: 0002 > Kernel 2.4.9-31SGI_XFS_1.1 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010286 > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > ds: 0018 es: 0018 ss: 0018 > Process rsync (pid: 4785, stackpage=d823f000) > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > 00000000 > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > 0000000b > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > df68fb24 From owner-linux-xfs@oss.sgi.com Wed Sep 18 00:11:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 00:11:12 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I7B9tG012858 for ; Wed, 18 Sep 2002 00:11:10 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8I7G8T7094214; Wed, 18 Sep 2002 09:16:09 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id EC61A65104; Wed, 18 Sep 2002 09:16:07 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: , Subject: Re: Install 24.18-4SMP Date: Wed, 18 Sep 2002 09:16:07 +0200 X-Mailer: KMail [version 1.3.2] References: <001301c25ec6$9ca093a0$9c7ba8c0@maherxp> In-Reply-To: <001301c25ec6$9ca093a0$9c7ba8c0@maherxp> MIME-Version: 1.0 Message-Id: <20020918071607.EC61A65104@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8I7BBtG012871 X-archive-position: 456 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs On Wednesday 18 September 2002 05:51, Mike wrote: > I am trying to install kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm on a > redhat 7.2 and I am getting the following error: > > [root ~]# rpm -ivh kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm > error: failed dependencies: > dev < 3.2-7 conflicts with kernel-smp-2.4.18-4SGI_XFS_1.1 > > Any help is greatly appreciated. I do not have a dev 3.2-7 rpm: > [root ~]# rpm -q dev > dev-3.2-5 kernel-smp-2.4.18-4SGI_XFS_1.1.i686.rpm belongs to RH 7.3, so you may try the dev rpm from 7.3. Simon > > I am on 2.4.9-34SGI_XFS_1.1smp kernel now. And I am having nfsd kernel > error when I run xfsdump. It hangs nfsd and the only way to restart nfs > is to reboot. I am hoping that 2.4.18-4 will fix this problem. > > Thanks, > > Mike From owner-linux-xfs@oss.sgi.com Wed Sep 18 01:47:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 01:47:34 -0700 (PDT) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I8lTtG014257 for ; Wed, 18 Sep 2002 01:47:30 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8I8qTTh013718; Wed, 18 Sep 2002 10:52:29 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8I8qTO52042; Wed, 18 Sep 2002 10:52:29 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 18 Sep 2002 10:52:29 +0200 (CEST) From: Seth Mos To: vkuznet cc: linux-xfs@oss.sgi.com Subject: Re: XFS mount failure In-Reply-To: Message-ID: <20020918105102.N49810-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 457 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Tue, 17 Sep 2002, vkuznet wrote: > The controller we use is 3Ware Escalade 7850. > Thanks for help, I used suggestion to mount xfs with -nouuid > and at least we are able now to make a backup and them will think > about upgrade of XFS. Okay, do check the disk on port 6. It's complaining about something. It might have been causing troubles. It shouldn't have, but computers are just people after all. Cheers From owner-linux-xfs@oss.sgi.com Wed Sep 18 01:52:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 01:52:09 -0700 (PDT) Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I8q6tG014878 for ; Wed, 18 Sep 2002 01:52:07 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla4.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8I8v5Th016348; Wed, 18 Sep 2002 10:57:05 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8I8v5152274; Wed, 18 Sep 2002 10:57:05 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 18 Sep 2002 10:57:04 +0200 (CEST) From: Seth Mos To: vricks@guilford.edu cc: linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? In-Reply-To: Message-ID: <20020918105654.I49810-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 458 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Tue, 17 Sep 2002 vricks@guilford.edu wrote: > > I've unsuccessfully checked the archives for the answer to the above > question. Are there any programs that allow Windows NT/2k/XP systems to > read XFS filesystem data? I have a dual-boot XP/Linux system with the > /home partition formatted XFS. No. Cheers From owner-linux-xfs@oss.sgi.com Wed Sep 18 01:55:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 01:55:22 -0700 (PDT) Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.6.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8I8tJtG015415 for ; Wed, 18 Sep 2002 01:55:20 -0700 Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11]) by mxzilla3.xs4all.nl (8.12.3/8.12.3) with ESMTP id g8I90KZo009771; Wed, 18 Sep 2002 11:00:21 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs1.xs4all.nl (8.11.6/8.11.6) with ESMTP id g8I90Kg52406; Wed, 18 Sep 2002 11:00:20 +0200 (CEST) (envelope-from knuffie@xs1.xs4all.nl) Date: Wed, 18 Sep 2002 11:00:20 +0200 (CEST) From: Seth Mos To: Benito Venegas cc: linux-xfs@oss.sgi.com Subject: Re: Kernel HANG In-Reply-To: Message-ID: <20020918105959.M49810-100000@xs1.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 459 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs On Tue, 17 Sep 2002, Benito Venegas wrote: Run it through ksymoops please. > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > <1>Unable to handle kernel paging request at virtual address 04a20000 > printing eip: > dfdf4282 > *pde = 00000000 > Oops: 0002 > Kernel 2.4.9-31SGI_XFS_1.1 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010286 > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > ds: 0018 es: 0018 ss: 0018 > Process rsync (pid: 4785, stackpage=d823f000) > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > 00000000 > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > 0000000b > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > df68fb24 > > > From owner-linux-xfs@oss.sgi.com Wed Sep 18 03:14:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 03:14:39 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IAEXtG016895 for ; Wed, 18 Sep 2002 03:14:33 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 902B31D5306; Wed, 18 Sep 2002 03:19:35 -0700 (PDT) Date: Wed, 18 Sep 2002 03:19:35 -0700 From: Chris Wedgwood To: Simon Matter Cc: Benito Venegas , linux-xfs@oss.sgi.com Subject: Re: Kernel HANG Message-ID: <20020918101935.GA16439@tapu.f00f.org> References: <20020918070345.AF16F65104@xxl.bi.corp.invoca.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918070345.AF16F65104@xxl.bi.corp.invoca.ch> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 460 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Sep 18, 2002 at 09:03:44AM +0200, Simon Matter wrote: > Do you use rsync in verbose mode? This was my problem some months > ago when I had many crashes using XFS/rsync. Then I read this > verbose thing on lkml (or was it rsync ML) and removing verbose > option from rsync helped. Verbose, terse or otherwise ... rsync should not cause an oops. Benito, can you please try a more recent kernel? 2.4.9 is rather old. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 18 03:37:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 03:37:08 -0700 (PDT) Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IAb4tG017924 for ; Wed, 18 Sep 2002 03:37:05 -0700 Message-Id: <200209181037.g8IAb4tG017924@oss.sgi.com> Received: from there ([144.135.25.75]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15 mta05ps Jul 16 2002 22:47:55) with SMTP id H2MR2000.99Q for ; Wed, 18 Sep 2002 20:42:00 +1000 Received: from CPE-203-51-226-46.qld.bigpond.net.au ([203.51.226.46]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0n 89/9604230); 18 Sep 2002 20:42:00 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Date: Wed, 18 Sep 2002 20:41:57 +1000 X-Mailer: KMail [version 1.3.1] References: <20020917000532.A18289@s2y4n2c.de> <3D87944B.8040206@hamburg.fcb.com> <3D874BA3.5040809@emergence.com> In-Reply-To: <3D874BA3.5040809@emergence.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 461 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ahead@bigpond.net.au Precedence: bulk X-list: linux-xfs For those people out there including me that didn't know about this until now - here are a few Gentoo mailing list pointers. Various posts regarding XFS vs yda yda yda... w.r.t. Gentoo & Data loss. http://marc.theaimsgroup.com/?l=gentoo-user&m=103180819906339&w=2 http://marc.theaimsgroup.com/?l=gentoo-user&m=103180893506745&w=2 http://marc.theaimsgroup.com/?l=gentoo-user&m=103185359619182&w=2 http://marc.theaimsgroup.com/?l=gentoo-user&m=103185563621841&w=2 This basically sums the argument up... http://marc.theaimsgroup.com/?l=gentoo-user&m=103184030901850&w=2 The start of the thread can be found here: http://marc.theaimsgroup.com/?l=gentoo-user&m=103175216417207&w=2 -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Wed Sep 18 03:41:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 03:41:15 -0700 (PDT) Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IAfCtG018391 for ; Wed, 18 Sep 2002 03:41:13 -0700 Message-Id: <200209181041.g8IAfCtG018391@oss.sgi.com> Received: from there ([144.135.25.78]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps Jul 16 2002 22:47:55) with SMTP id H2MR8X00.6MV for ; Wed, 18 Sep 2002 20:46:09 +1000 Received: from CPE-203-51-226-46.qld.bigpond.net.au ([203.51.226.46]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0n 98/10053110); 18 Sep 2002 20:46:09 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS Date: Wed, 18 Sep 2002 20:46:06 +1000 X-Mailer: KMail [version 1.3.1] References: <20020917000532.A18289@s2y4n2c.de> <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> In-Reply-To: <20020917072301.C81FF69123@xxl.bi.corp.invoca.ch> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 462 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ahead@bigpond.net.au Precedence: bulk X-list: linux-xfs Thanks to the hard working XFS team, the major goal of getting XFS into the 2.5/6+ kernel has been achieved. The only way to go now is up ;-) Congratulations to everyone involved. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Wed Sep 18 05:25:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 05:25:20 -0700 (PDT) Received: from mail.sgo.es ([217.172.67.134]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ICPDtG020577 for ; Wed, 18 Sep 2002 05:25:17 -0700 Received: from sgo.es (ecastyneira.sgo.es [193.127.97.115] (may be forged)) by mail.sgo.es (8.9.3/8.9.3) with ESMTP id OAA08897 for ; Wed, 18 Sep 2002 14:32:36 +0200 Message-ID: <3D886F99.EF7A6BC8@sgo.es> Date: Wed, 18 Sep 2002 12:20:41 +0000 From: jose Hernandez Organization: SGO X-Mailer: Mozilla 4.79C-SGI [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.17 + XFS Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 944 X-archive-position: 463 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jhernandez@sgo.es Precedence: bulk X-list: linux-xfs At first, thanks for your quickly response. I am not a expert in linux. Normally I work with Irix. I have download the patch of XFS for 2.4.17, but after I have patched it , I try to rebuild the kernel but (make bzImage) , but it give me several compilation errors. In any case I have one doubt: Can I use that 2.4.17XFS patch from a original ( without XFS previous version) 2.4.17 kernel? Or Have I to install 2.4.9(with XFS) , then upgrade to 2.4.17 and finally to patch with 2.4.17XFS? On the other hand , I have download from CVS the 2.4.19 version, but I have error compiling the kernel. Exactly the error is that the file kernel.h is including a file called stdarg.h , and this file is not found. I think that I have done fine all the steps(mrproper,config...), but it is the firs time that a CLEAN kernel give me errors. Thanks a lot for your help. Salud y suerte,Jose. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Sep 18 05:50:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 05:50:57 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ICoptG021422 for ; Wed, 18 Sep 2002 05:50:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA63814 for ; Wed, 18 Sep 2002 07:55:49 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA81024 for ; Wed, 18 Sep 2002 07:55:48 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IKAlm25990 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 16:10:47 -0400 Resent-Message-Id: <200209182010.g8IKAlm25990@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id HAA58749 for ; Wed, 18 Sep 2002 07:52:42 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IK7gZ25927 for hch@sgi.com; Wed, 18 Sep 2002 16:07:42 -0400 Date: Wed, 18 Sep 2002 16:07:42 -0400 From: Christoph Hellwig Message-Id: <200209182007.g8IK7gZ25927@dhcp212.munich.sgi.com> Subject: TAKE - Small comment corrections/updates Resent-Date: Wed, 18 Sep 2002 16:10:47 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 464 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Sep 18 05:33:01 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127729a linux/fs/xfs/linux/xfs_vnode.h - 1.64 - Small comment corrections/updates From owner-linux-xfs@oss.sgi.com Wed Sep 18 05:52:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 05:52:48 -0700 (PDT) Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ICqjtG021688 for ; Wed, 18 Sep 2002 05:52:45 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8ICvgGc014467; Wed, 18 Sep 2002 14:57:42 +0200 (CEST) Message-Id: <4.3.2.7.2.20020918145423.0386a350@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Sep 2002 14:56:22 +0200 To: Adrian Head , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Linus merges XFS In-Reply-To: <200209181037.g8IAb4tG017924@oss.sgi.com> References: <3D874BA3.5040809@emergence.com> <20020917000532.A18289@s2y4n2c.de> <3D87944B.8040206@hamburg.fcb.com> <3D874BA3.5040809@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 465 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 20:41 18-9-2002 +1000, Adrian Head wrote: >This basically sums the argument up... >http://marc.theaimsgroup.com/?l=gentoo-user&m=103184030901850&w=2 I'd say so yes. It gives new meaning to the "Test in your environment and see if it works for you" argument. I have seen lot's of things fail over the years to which some people say that it shouldn't be possible, but it happens anyways. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 18 07:23:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 07:23:32 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IENQtG031562 for ; Wed, 18 Sep 2002 07:23:27 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA65097 for ; Wed, 18 Sep 2002 09:28:25 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA73231 for ; Wed, 18 Sep 2002 09:28:23 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8ILhMF28323 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 17:43:22 -0400 Resent-Message-Id: <200209182143.g8ILhMF28323@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA90925 for ; Wed, 18 Sep 2002 09:27:40 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8ILgel28313 for hch@sgi.com; Wed, 18 Sep 2002 17:42:40 -0400 Date: Wed, 18 Sep 2002 17:42:40 -0400 From: Christoph Hellwig Message-Id: <200209182142.g8ILgel28313@dhcp212.munich.sgi.com> Subject: TAKE - Make pagebuf use the generic xfs ASSERT() instead of it's own assert() Resent-Date: Wed, 18 Sep 2002 17:43:22 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 466 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs This is a leftover from the times when pagebug wasn't part of the XFS module Date: Wed Sep 18 07:26:00 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127736a linux/fs/xfs/pagebuf/Makefile - 1.14 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.30 linux/fs/xfs/pagebuf/page_buf.c - 1.63 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.15 - Make pagebuf use the generic xfs ASSERT() instead of it's own assert() From owner-linux-xfs@oss.sgi.com Wed Sep 18 07:53:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 07:53:48 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IErjtG032340 for ; Wed, 18 Sep 2002 07:53:46 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA39200 for ; Wed, 18 Sep 2002 09:58:44 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA57891 for ; Wed, 18 Sep 2002 09:58:43 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IMDgn28945 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 18:13:42 -0400 Resent-Message-Id: <200209182213.g8IMDgn28945@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA33565 for ; Wed, 18 Sep 2002 09:58:29 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8IMDTR28939 for hch@sgi.com; Wed, 18 Sep 2002 18:13:29 -0400 Date: Wed, 18 Sep 2002 18:13:29 -0400 From: Christoph Hellwig Message-Id: <200209182213.g8IMDTR28939@dhcp212.munich.sgi.com> Subject: TAKE - Add back a invalidate_inode_pages2 that got lost in the XFS tree Resent-Date: Wed, 18 Sep 2002 18:13:42 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 467 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs XFS does this differently so this might only have caused problems if you used O_DIRECT on a non-XFS filesystem with the XFS tree. Date: Wed Sep 18 07:56:59 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127737a linux/mm/filemap.c - 1.115 - Add back a invalidate_inode_pages2 that got lost in the XFS tree From owner-linux-xfs@oss.sgi.com Wed Sep 18 10:03:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 10:03:44 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IH3atG005390 for ; Wed, 18 Sep 2002 10:03:37 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8GGud7O020548; Mon, 16 Sep 2002 17:56:39 +0100 Reply-To: From: "Ian D. Hardy" To: "'Stephen Lord'" Cc: Subject: RE: Re-occurance of NFS server panics Date: Mon, 16 Sep 2002 17:56:40 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <1032190545.1051.80.camel@laptop.americas.sgi.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MailScanner: Believed to be clean X-archive-position: 468 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve, Thanks for the quick response. I don't always get a Oops output (sometimes the server just hangs and requires a reboot). However as it happens the server has just crashed again with the following Oops (through 'ksymoops'): EFLAGS: 00010016 eax: 5a2cf071 ebx: 003a0dc0 ecx: f7ee3dd0 edx: c200b060 esi: ce837000 edi: ce8372b4 ebp: ce837ce0 esp: f7ee1f38 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7ee1000) Stack: f7ee0000 00000009 f7ee3dd0 f7ee3c00 00000000 00000007 00000000 00000000 00000000 c200b060 00000020 000001d0 00000006 00000000 c01325d9 c036aa70 00000006 000001d0 c036aa70 00000000 c013268c 00000020 c036aa70 00000002 Call Trace: [] [] [] [] [] [] [] [] [] Code: 0f 0b 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 2c 5a 01 ca 87 42 >>EIP; c013127e <===== Trace; c01325d8 Trace; c013268c Trace; c0132730 Trace; c01327a6 Trace; c01328e0 Trace; c0132840 Trace; c0105000 <_stext+0/0> Trace; c0105836 Trace; c0132840 Code; c013127e 00000000 <_EIP>: Code; c013127e <===== 0: 0f 0b ud2a <===== Code; c0131280 2: 8b 44 24 24 mov 0x24(%esp,1),%eax Code; c0131284 6: 89 ea mov %ebp,%edx Code; c0131286 8: 8b 48 18 mov 0x18(%eax),%ecx Code; c0131288 b: b8 71 f0 2c 5a mov $0x5a2cf071,%eax Code; c013128e 10: 01 ca add %ecx,%edx Code; c0131290 12: 87 42 00 xchg %eax,0x0(%edx) Entering kdb (current=0xf7ee0000, pid 5) on processor 1 Oops: invalid operand eax = 0x5a2cf071 ebx = 0x003a0dc0 ecx = 0xf7ee3dd0 edx = 0xc200b060 esi = 0xce837000 edi = 0xce8372b4 esp = 0xf7ee1f38 eip = 0xc013127e ebp = 0xce837ce0 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 ->====================================================================== This is a different trace to the last one I posted, this new one makes no direct reference to XFS which may mean that it is not XFS related (in which case apologies....) or that it was another non XFS process (kswapd) that ran into difficulty in obtaining kernel memory as a result of XFS/extent issues. I seem to remember that the was an issue with the XFS/KDB implementation around the time of the CVS kernel I'm currently using. (No, the server shouldn't be running out of memory, it has 1Gbyte RAM and does nothing but NFS serving, it normally has ~957684K cached). If I remember correctly we have tried the fix you refer to regarding memory getting freed to the wrong pool: > > Only happens under high memory pressure, Ian, I think this was > your original oops. > > Date: Wed Mar 20 11:06:42 PST 2002 > Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline > > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs > > Modid: 2.4.x-xfs:slinx:114531a > linux/fs/xfs_support/kmem.c - 1.22 > - Fix the case where we used vmalloc to allocate memory under pressure, > we need to free it that way Anyway, I think I need to get the current 2.4.19-XFS tree installed even if this doesn't fix the problem it will give us a better base to work from. Regards Ian Hardy -----Original Message----- From: Stephen Lord [mailto:lord@sgi.com] Sent: 16 September 2002 16:36 To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com Subject: RE: Re-occurance of NFS server panics On Mon, 2002-09-16 at 09:52, Ian D. Hardy wrote: > Steve +, > > Sorry to bother you again. You may remember that we've corresponded > several times over the past ~9months with regards to kernel memory > allocation problems and fragmented files (see bellow). > > We had a period of relative stability, however the last few weeks we > have gone back to a situation of having one or more crashes/hangs > every week and are now having to again review our continued use of > XFS. Therefore any update on progress towards a fix for these > problems would be very useful (I'd hate to go though the pain of > converting our ~1Tbyte filesystem to Reiser of ext3 if there are fixes > immanent). > > We have been running a 2.4.18 XFS CVS kernel from Mid May for some > time now, I'm just in the process of compiling and testing the current > 2.4.19 XFS CVS, is this likely to help? (looking through the list > archive I can't find anything of direct relevance but may have missed > something). > > We appear to be running at a lower overall system fragmentation level > now (currently 13% in the past it has been 28% or more), though I > guess it is possible for only a couple of large very fragmented files > to result in kernel memory allocation problems and still have > reasonably low overall FS fragmentation levels? > > Unfortunately the NFS load on our server is such that it is > difficult/impossible to predict times of light NFS load in which to > run fsr and as reported before we've had several incidents of > filesystem corruption and the kernel taking the FS offline running fsr > under a NFS load. > > Thanks for your time (BTW: We've persevered with XFS for so long as it > seems to give better performance for our workload than ext3 or > ReiserFS, however, stability is again becoming a problem). > Nothing immediately rings a bell, there have been some recent changes which fixed some hangs HP was having in doing large scale NFS benchmarking. These might be beneficial to you. The last oops output I have from you looked like this: >>EIP; c012ff76 <===== Trace; c01fd146 Trace; c01fd1a4 Trace; c01d04f0 Trace; c01a6996 Trace; c01a5f12 Trace; c01d6474 Trace; c01fd2e0 Trace; c01aac14 Trace; c01cf962 Trace; c01e6e22 Trace; c01e6340 Trace; c026cf44 Trace; c01f696e Trace; c01e6340 Trace; c014f45c Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> Trace; f8d2b348 <[nfsd]nfsd+1b8/370> Trace; c01057ea Code; c012ff76 00000000 <_EIP>: Code; c012ff76 <===== 0: 0f 0b ud2a <===== Code; c012ff78 2: 83 c4 08 add $0x8,%esp Code; c012ff7a 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx Code; c012ff80 b: 8b 2c 1a mov (%edx,%ebx,1),%ebp Code; c012ff84 e: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c012ff88 12: b8 00 00 00 00 mov $0x0,%eax Is this still what you see? This one does bear the symptoms of a problem which was fixed a while ago - memory was freed into the wrong pool. Steve From owner-linux-xfs@oss.sgi.com Wed Sep 18 10:16:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 10:16:31 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IHGNtG006270 for ; Wed, 18 Sep 2002 10:16:24 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8IFp5q31044 for ; Wed, 18 Sep 2002 11:51:05 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8IFp4Q31035; Wed, 18 Sep 2002 11:51:04 -0400 Date: Wed, 18 Sep 2002 11:51:04 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: Subject: Re: Kernel HANG In-Reply-To: <20020918105959.M49810-100000@xs1.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463806619-937713930-1032364264=:22051" X-archive-position: 469 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---1463806619-937713930-1032364264=:22051 Content-Type: TEXT/PLAIN; charset=US-ASCII Kernel Debug is attached to this email. Thanks for your help Seth and xfs list members. Vene.- On Wed, 18 Sep 2002, Seth Mos wrote: > On Tue, 17 Sep 2002, Benito Venegas wrote: > > Run it through ksymoops please. > > > > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > > <1>Unable to handle kernel paging request at virtual address 04a20000 > > printing eip: > > dfdf4282 > > *pde = 00000000 > > Oops: 0002 > > Kernel 2.4.9-31SGI_XFS_1.1 > > CPU: 0 > > EIP: 0010:[] Tainted: P > > EFLAGS: 00010286 > > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > > ds: 0018 es: 0018 ss: 0018 > > Process rsync (pid: 4785, stackpage=d823f000) > > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > > 00000000 > > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > > 0000000b > > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > > df68fb24 > > > > > > > > ---1463806619-937713930-1032364264=:22051 Content-Type: APPLICATION/x-gzip; name="debug-kernel.gz" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="debug-kernel.gz" H4sICHWgiD0AA2RlYnVnLWtlcm5lbADtWmtv47gV/a5fwQ9dNKkd62lb9ngC tIPZRYACO2h2+sBgIVAk5aiRRS9JJc7++r2kHpYcKxN73CbbRghsU7w8vOfw XulSyq18WHG+lsgbBSMX8Rylk3BiWrML373+4Sr65/fXkTtyRwj9uFYpzyUq JKMW0sfF39EZZQkuMnVenblF9lpwYt8CsnzUm1W9K06LjD3u58jO0rjutvf4 YT8as0J2zLmyrx+kYqvRCq8v9oxrDbP+gUWe5ss5+hcvEE0pyrlCimUZWjF0 f8MEQ4qjJM0pAhYxz1CaJ1yssOYPQlyh+zTLLCxlAQPUDYbRNwxlfInAhtwA Md2+ZSJnGcIAU/M1thjwRZFrFyyRLm8UzH9vzK7+CD6AvGZ45S/ilew45ncM gR+1U4JJnhXGJ+sqMWNIIQTLVWtqG+zr2Sk3TI2PtcdD9AAiEJyjJVPWioNv mAAMVgzxQq0LheIHIw64i1aszeyOCQmzG9c7slmwCMN62iEqY4EpAtrd1hF3 cYPYZp3hNC/VqmiOLOujEOD0GfQCcMTjfzOi5PlcO6ndlwqrMxMmOCXTzWYz 4udGlqp5wHhMBE5pM75sPn+8pBFwrIeXrQNGE5l2xlftOjzRGeGrNQRLBGpq hFUqy6UDyasQgG6Vat2iHMPaoErrKMYQRBI/SEQcz5th4gzRNj/qHnc8JVNH B/Qy50JP2RoNYSQeDvElz1byjkRLgQmL1kyknGqHMk5uaTkjc2ZTOvGD4dez vIwwO5G2GV9+jvgWh+BZ0Pb8aMRjeeoY3kvPORE950XpqXTFIP/3UwxPRDF8 IYqJjCiLi6VmJ4tcrEnjlo/H3gErmDNllwjVV4uhjz3nqEXcB3oMSfokywPS 8Gssj8rE07DMVk+SPCBSv0byqGA9CUkY9hRJl5yKpJuQFyW5xCLGSxZhsZR7 uQbJ6bjSl+UqC0KY7KHJTkeTvDBNU3VETIj9weuc7GLrspe72G6oiHjOehbz ZFdal7zclVZTVPe8h+LJrrMuebnrrKb4KxN9HE8XqeTlIpW5juNEehMe0dTk pDnTeBcwb3IAUSpSvQu0MaU8tw1U+dkiHFB6XB30FPjBxAsZw030Dkq/G9iY ZSZX4RzRO97K03AW+PgI8gBjV1Bb2uHMZ5Nvot2F3SEMRCO9W4sUj0rM7R6z pJ5xTFn96KHe3OodOkZFnv5SsLqr3KOCpz/prRuMfjCPCWKGBMtSHGdsdIjQ 0mz7yt1wI4Ybs0Ou9LUEek/cbLNbYPTblO3CHhxKJns0hiFabdu33k19esDt u+tT80xgCzcm7lFX/T7gg+masZA6KYFwkKqHdOAccA94BungBCv8raRvuFRP Uj7gzv4Myv5RpdrpKctevqeN6+AVxHXGl0uwjzJ2x7LefD5taLv/gdD+wCmb I+whuJfDn/4RIEqr5p4/guIEuQQRB41D/dv6LLU71WNniRLBV63HtQqxLPG9 i9QPJ+gCI/1tmWnfIQAsD/QXlugbapIKyJpSZ6vpXEQfrz5dzp81CEH/HD52 GLWOFb/TX9/hbOhsAv2sxXF2oMd90GMNXaqz70gyCrGAzr5jeHO+gzntw5xq zNLXfQcUMbW7e3Fnfbizb8ON+3Djb8Olfbi0xjUR1otLDC5Nh+Yj2IF3+6LC NVFRxu2+Q8ax/vqDsyHOEJzfgfX6YD0NC4nQc6z52ngNQuwg+n2IvkYEBdpZ 1zqq8AVHHSOBZaGFe/k51/WWrtKqKrV61bLG+ioFBRnUbTALVuguFarAmdZT 6OcITp0CNKFJ4IWe9ac1Zeh9k2bWj5DHc930rA+fPmvvkGNBRpa/QPL5l0U9 +PJnffInnOaKwYJ+QtbH7//65x+uzXjX8SD3QYo5qu3BmMWbeT2ZaRPTPwmT 2NOJy2jdxsSxmEyhFXo+c4wuoEC3Ha/n2xCGtlyX/YkzDSxqiLih6Wh+yuqn 9QkKNK2JkA85QWfrFCgE03A81K9fyC2Iyd6XWI5zbl3rc3P9PsSdEUa2HJqY MbYuREfjEBg7U9+Pt2eaq5lVLbDGC1x3ol/BhFPHZ49gvC3h5owe5UN5uwWu 8RrbRvPtj6aLesFsNiVNNKAQPkI/dLYrYX3AWVbW+nP0ZVHThhWnPGKbVKEv ZdD9jJwNBT7GxrDVNilr9wdJ1W+olhha3qh8d9my9ONJaVqKAaaErx9Eqjp4 kymrAbUKTwHWnrnUD2alISZEmb2tXvyWqTcdV8aETEKNmqW53gre787f0J0w GoId02/zIgIZ3+ES1nO/Kff/qJw3nSWBC4YREMyligrKMtg2tyzd8ZvIv5/w 7BPH1bcTsF4pIaKUE5V1NAqDRsRxUAkN8+MspREUDPum/4raAETYU0Bwta/E dp0Eg+VIcIoV7sSe7+PfSfS9CfxqBH61l4HEwWbFdO1bsEimyxx3WPje4abP lfgQRDKrIuuxldee2NWLVtpEgqlC5J3ggiVpnmLomh1sMD2fI73v0KHDzONZ yVg+RLRYrbXhvf7HMhOmqUT4DqeZ3kdY1uUlFPjvtpXiImI5HbjJjFEywbbn +MkMB+El1JeL9/qwTGH4blsNL6roGlDH9sbhZcugrIAXEDKDILHHTruvLH0X ndUdQIzYAWvbVZXxoo6VAQSIHSSh28EyBfEOlrODVGaisWon4gCyz/bCoG1p 0hAt2lkIcP6kS04HCFps42Pgh3bQnfFNoP8lgcqqDlKkU9QNXJAneNPxdQea eQKw2N7kBnBnsyfTHZGghjBube/8MFtInqukqR12AUKvi1DWDWghFduoSP+P 2sAnCbaDSUxeeRS9qfhfVPFVJayucsCqU+QMfM/G5Aiz54j4XCQoqYz3lQWU UbvrauopCJR2OTVwAxuqXsuyvDG6L2spaf5NPSgLPgllkiwYHSH0NybN6469 r71/AwxPCXsgMQAA ---1463806619-937713930-1032364264=:22051-- From owner-linux-xfs@oss.sgi.com Wed Sep 18 10:53:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 10:53:39 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IHrWtG010157 for ; Wed, 18 Sep 2002 10:53:32 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1988E1D94C3; Wed, 18 Sep 2002 10:58:36 -0700 (PDT) Date: Wed, 18 Sep 2002 10:58:36 -0700 From: Chris Wedgwood To: jose Hernandez Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.17 + XFS Message-ID: <20020918175836.GA19707@tapu.f00f.org> References: <3D886F99.EF7A6BC8@sgo.es> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D886F99.EF7A6BC8@sgo.es> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 470 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Wed, Sep 18, 2002 at 12:20:41PM +0000, jose Hernandez wrote: > On the other hand , I have download from CVS the 2.4.19 version, but > I have error compiling the kernel. From CVS *when* and what is your error? Please also show your .config. If it would help people, I am happy to put up a 2.4.19-xfs tree (from CVS) and possible also 2.4.20-pre* kernels to as time permits so people can't just garb the tarball's and build from that. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 18 11:19:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 11:19:43 -0700 (PDT) Received: from mail02.securities.com (mail02.securities.com [57.69.15.72]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IIJZtG010838 for ; Wed, 18 Sep 2002 11:19:36 -0700 Received: from mail02.securities.com (localhost [127.0.0.1]) by mail02.securities.com (8.11.6/8.11.6-DELIVERY) with ESMTP id g8IIOdq10809 for ; Wed, 18 Sep 2002 14:24:39 -0400 Received: from localhost (venevene@localhost) by mail02.securities.com (8.11.6/8.11.6-SMTP) with ESMTP id g8IIOde10800; Wed, 18 Sep 2002 14:24:39 -0400 Date: Wed, 18 Sep 2002 14:24:38 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: Subject: Re: Kernel HANG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 471 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: venevene@securities.com Precedence: bulk X-list: linux-xfs Team: We found some conflicts between snare (auditmodule.o) and current 2.4.9-31SGI_XFS. We enabled snare and 1.5 hour later, machine was down. I will send information to snare developers. Thanks for your help. Vene.- On Wed, 18 Sep 2002, Benito Venegas wrote: > Kernel Debug is attached to this email. > Thanks for your help Seth and xfs list members. > > Vene.- > > On Wed, 18 Sep 2002, Seth Mos wrote: > > > On Tue, 17 Sep 2002, Benito Venegas wrote: > > > > Run it through ksymoops please. > > > > > > > > Code: a2 00 00 a2 04 dd 00 00 00 00 00 00 00 00 0c bf 1c c0 58 bf > > > <1>Unable to handle kernel paging request at virtual address 04a20000 > > > printing eip: > > > dfdf4282 > > > *pde = 00000000 > > > Oops: 0002 > > > Kernel 2.4.9-31SGI_XFS_1.1 > > > CPU: 0 > > > EIP: 0010:[] Tainted: P > > > EFLAGS: 00010286 > > > EIP is at ___strtok_R29805c13 [] 0x1f9edc6e > > > eax: dfdf4282 ebx: 00000002 ecx: df68fb24 edx: df68fac0 > > > esi: d823e000 edi: d823e000 ebp: 0000000b esp: d823ee44 > > > ds: 0018 es: 0018 ss: 0018 > > > Process rsync (pid: 4785, stackpage=d823f000) > > > Stack: c0119cec 00000002 00000012 d823ef28 0000000b c010733b 0000000b > > > 00000000 > > > c0114116 c028703e d823ef28 00000002 d823e000 00000002 c0113d60 > > > 0000000b > > > d823e000 dfdf4282 dfdf4282 d823e000 dd24997c 04a20000 80000000 > > > df68fb24 > > > > > > > > > From owner-linux-xfs@oss.sgi.com Wed Sep 18 11:26:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 11:26:30 -0700 (PDT) Received: from mta3.sucs.soton.ac.uk (mta3.sucs.soton.ac.uk [152.78.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IIQRtG011339 for ; Wed, 18 Sep 2002 11:26:28 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta3.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IIVN6C002093; Wed, 18 Sep 2002 19:31:24 +0100 Reply-To: From: "Ian D. Hardy" To: "'Stephen Lord'" Cc: , , , Subject: RE: Re-occurance of NFS server panics Date: Wed, 18 Sep 2002 19:31:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <1032196576.9808.149.camel@laptop.americas.sgi.com> X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.1, required 5, IN_REP_TO, WEIRD_PORT) X-archive-position: 472 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve, >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: >> Steve, >> >> Thanks for the quick response. I don't always get a Oops output >> (sometimes the server just hangs and requires a reboot). However as it >> happens the server has just crashed again with the following Oops >> (through 'ksymoops'): > >This one suggests heap corruption more than anything else. > >Steve I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday 16th Sept.) today and got a very similar looking Ooops to the one I reported on Monday, see below. I guess it is very difficult to know what would have caused any heap corruption. As I understand it there's nothing in these latest panics to directly link them with XFS? I need to do some more thinking on this. Any pointers would be very welcome. Regards Ian Hardy kernel BUG at slab.c:1439! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010016 eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7edd000) Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 00000000 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 c036fa08 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 00000002 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid operand due to oops @ 0xc0133a64 eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 xds = 0xe51e0018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf7eddf14 [0]kdb> kernel BUG at slab.c:1439! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010016 eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 5, stackpage=f7edd000) Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 00000000 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 c036fa08 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 00000002 Call Trace: [] [] [] [] [] [] [] [] Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 >>EIP; c0133a64 <===== Trace; c0134e58 Trace; c0134f0c Trace; c0134fb0 Trace; c0135026 Trace; c013515c Trace; c0105000 <_stext+0/0> Trace; c0107296 Trace; c01350c0 Code; c0133a64 00000000 <_EIP>: Code; c0133a64 <===== 0: 0f 0b ud2a <===== Code; c0133a66 2: 9f lahf Code; c0133a66 3: 05 a0 54 2b c0 add $0xc02b54a0,%eax Code; c0133a6c 8: 8b 44 24 24 mov 0x24(%esp,1),%eax Code; c0133a70 c: 89 ea mov %ebp,%edx Code; c0133a72 e: 8b 48 18 mov 0x18(%eax),%ecx Code; c0133a74 11: b8 71 f0 00 00 mov $0xf071,%eax Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid operand eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 From owner-linux-xfs@oss.sgi.com Wed Sep 18 11:38:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 11:38:57 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IIcptG011875 for ; Wed, 18 Sep 2002 11:38:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA68208; Wed, 18 Sep 2002 13:43:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA85618; Wed, 18 Sep 2002 13:43:49 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8IIe9l30357; Wed, 18 Sep 2002 13:40:09 -0500 Subject: RE: Re-occurance of NFS server panics From: Steve Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk, Russell Cattelan In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Sep 2002 13:40:09 -0500 Message-Id: <1032374409.30048.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 473 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > Steve, > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > >> Steve, > >> > >> Thanks for the quick response. I don't always get a Oops output > >> (sometimes the server just hangs and requires a reboot). However as > it > >> happens the server has just crashed again with the following Oops > >> (through 'ksymoops'): > > > >This one suggests heap corruption more than anything else. > > > >Steve > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday > 16th Sept.) today and got a very similar looking Ooops to the one I > reported on Monday, see below. I guess it is very difficult to know what > would have caused any heap corruption. As I understand it there's > nothing in these latest panics to directly link them with XFS? I need to > do some more thinking on this. Any pointers would be very welcome. > > Regards Ian Hardy > > > kernel BUG at slab.c:1439! OK, so you have slab debugging turned on, which I was going to ask you to do. Looks like someone walked off the end of an allocation here, that is progress. So, the question is what did it, thats the really hard part! Is this machine just running XFS via NFS, or is it doing anything else? Also, which options do you have turned on in XFS, in fact, sending the whole kernel config might be an idea. Steve > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010016 > eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 > esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=f7edd000) > Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 > 00000000 > 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 > c036fa08 > 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 > 00000002 > Call Trace: [] [] [] [] > [] > [] [] [] > > Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 > > Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid > operand > due to oops @ 0xc0133a64 > eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 > esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 > ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 > xds = 0xe51e0018 xes = 0x00000018 origeax = 0xffffffff ®s = > 0xf7eddf14 > [0]kdb> > kernel BUG at slab.c:1439! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010016 > eax: 5a2cf071 ebx: 006f5b20 ecx: f7edf00c edx: c1c0f060 > esi: e51e6000 edi: e51e6c3c ebp: e51e6c18 esp: f7eddf48 > ds: 0018 es: 0018 ss: 0018 > Process kswapd (pid: 5, stackpage=f7edd000) > Stack: 0000293b 00000002 f7edf00c f7edf000 00000000 00000007 00000000 > 00000000 > 00000000 c1c0f060 00000020 000001d0 00000006 00000000 c0134e59 > c036fa08 > 00000006 000001d0 c036fa08 00000000 c0134f0c 00000020 c036fa08 > 00000002 > Call Trace: [] [] [] [] > [] > [] [] [] > Code: 0f 0b 9f 05 a0 54 2b c0 8b 44 24 24 89 ea 8b 48 18 b8 71 f0 > > >>EIP; c0133a64 <===== > Trace; c0134e58 > Trace; c0134f0c > Trace; c0134fb0 > Trace; c0135026 > Trace; c013515c > Trace; c0105000 <_stext+0/0> > Trace; c0107296 > Trace; c01350c0 > Code; c0133a64 > 00000000 <_EIP>: > Code; c0133a64 <===== > 0: 0f 0b ud2a <===== > Code; c0133a66 > 2: 9f lahf > Code; c0133a66 > 3: 05 a0 54 2b c0 add $0xc02b54a0,%eax > Code; c0133a6c > 8: 8b 44 24 24 mov 0x24(%esp,1),%eax > Code; c0133a70 > c: 89 ea mov %ebp,%edx > Code; c0133a72 > e: 8b 48 18 mov 0x18(%eax),%ecx > Code; c0133a74 > 11: b8 71 f0 00 00 mov $0xf071,%eax > > Entering kdb (current=0xf7edc000, pid 5) on processor 0 Oops: invalid > operand > eax = 0x5a2cf071 ebx = 0x006f5b20 ecx = 0xf7edf00c edx = 0xc1c0f060 > esi = 0xe51e6000 edi = 0xe51e6c3c esp = 0xf7eddf48 eip = 0xc0133a64 > ebp = 0xe51e6c18 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010016 -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 18 13:44:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 13:44:28 -0700 (PDT) Received: from mta1.sucs.soton.ac.uk (mta1.sucs.soton.ac.uk [152.78.128.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IKiJtG014004 for ; Wed, 18 Sep 2002 13:44:20 -0700 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by mta1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IKnFD9005346; Wed, 18 Sep 2002 21:49:15 +0100 Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id VAA11727544; Wed, 18 Sep 2002 21:49:11 +0100 (BST) From: Message-Id: <200209182049.VAA11727544@plum.sucs.soton.ac.uk> Subject: Re: Re-occurance of NFS server panics To: lord@sgi.com (Steve Lord) Date: Wed, 18 Sep 2002 21:49:11 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk, cattelan@thebarn.com (Russell Cattelan) In-Reply-To: <1032374409.30048.8.camel@jen.americas.sgi.com> from "Steve Lord" at Sep 18, 2002 01:40:09 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=3.8, required 5, IN_REP_TO, NO_REAL_NAME, DOUBLE_CAPSWORD, PORN_10, PORN_11, SIGNATURE_DELIM, UPPERCASE_50_75, WEIRD_PORT) X-archive-position: 474 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve +, > > On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > > Steve, > > > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > > >> Steve, > > >> > > >> Thanks for the quick response. I don't always get a Oops output > > >> (sometimes the server just hangs and requires a reboot). However as > > it > > >> happens the server has just crashed again with the following Oops > > >> (through 'ksymoops'): > > > > > >This one suggests heap corruption more than anything else. > > > > > >Steve > > > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday > > 16th Sept.) today and got a very similar looking Ooops to the one I > > reported on Monday, see below. I guess it is very difficult to know what > > would have caused any heap corruption. As I understand it there's > > nothing in these latest panics to directly link them with XFS? I need to > > do some more thinking on this. Any pointers would be very welcome. > > > > Regards Ian Hardy > > > > > > kernel BUG at slab.c:1439! > > > OK, so you have slab debugging turned on, which I was going to ask > you to do. Looks like someone walked off the end of an allocation > here, that is progress. > > So, the question is what did it, thats the really hard part! Is > this machine just running XFS via NFS, or is it doing anything > else? Also, which options do you have turned on in XFS, in fact, > sending the whole kernel config might be an idea. > > Steve > Thanks for your continued help/interest, it is much appreciated. The server (dual 1Ghz PIII, with 1Gbyte memory) is a dedicated NFS fileserver (no users have direct access to it). It is serving ~260 NFS clients (part of a computational/Beowulf system). The server has a 40Gbyte IDE system disk and 2 FC-IDE connected RAID units (each with ~500Gbytes usable storage - RAID 5 configuration). The RAID units are connected via a Qlogic QLA2200 HBA and a FC switch. The 2 RAID units are stripped together(RAID 0) using the kernel 'md' RAID driver. Below is the kernel configuration file: # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set CONFIG_MPENTIUMIII=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_X86_MCE is not set # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_SMP=y # CONFIG_MULTIQUAD is not set CONFIG_HAVE_DEC_LOCK=y # # General setup # CONFIG_NET=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # CONFIG_HOTPLUG_PCI is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set CONFIG_PARPORT_OTHER=y # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # # CONFIG_PNP is not set # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_CISS_SCSI_TAPE is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID5=m # CONFIG_MD_MULTIPATH is not set CONFIG_BLK_DEV_LVM=m # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_CONNTRACK is not set # CONFIG_IP_NF_QUEUE is not set # CONFIG_IP_NF_IPTABLES is not set # CONFIG_IP_NF_ARPTABLES is not set # CONFIG_IP_NF_COMPAT_IPCHAINS is not set # CONFIG_IP_NF_COMPAT_IPFWADM is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DEV_APPLETALK is not set # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # CONFIG_PHONE_IXJ is not set # CONFIG_PHONE_IXJ_PCMCIA is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_BLK_DEV_IDEDMA_TIMEOUT is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_AMD74XX_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CMD680 is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_PIIX_TUNING is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_PDC202XX_FORCE is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set CONFIG_BLK_DEV_VIA82CXXX=y # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y CONFIG_IDEDMA_IVB=y # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # CONFIG_BLK_DEV_ATARAID_PDC is not set # CONFIG_BLK_DEV_ATARAID_HPT is not set # # SCSI support # CONFIG_SCSI=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=y # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_DEBUG_QUEUES is not set CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_7000FASST is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AHA152X is not set # CONFIG_SCSI_AHA1542 is not set # CONFIG_SCSI_AHA1740 is not set # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=8 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_IN2000 is not set # CONFIG_SCSI_AM53C974 is not set CONFIG_SCSI_MEGARAID=m # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_DTC3280 is not set # CONFIG_SCSI_EATA is not set # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set # CONFIG_SCSI_GENERIC_NCR5380 is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set # CONFIG_SCSI_NCR53C406A is not set # CONFIG_SCSI_NCR53C7xx is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set # CONFIG_SCSI_SYM53C8XX is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set CONFIG_SCSI_QLOGIC_FC=m # CONFIG_SCSI_QLOGIC_FC_FIRMWARE is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set # CONFIG_SCSI_SYM53C416 is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set # CONFIG_SCSI_ULTRASTOR is not set # CONFIG_SCSI_DEBUG is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # CONFIG_I2O=m CONFIG_I2O_PCI=m CONFIG_I2O_BLOCK=m CONFIG_I2O_LAN=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_SUNLANCE is not set # CONFIG_HAPPYMEAL is not set # CONFIG_SUNBMAC is not set # CONFIG_SUNQE is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y # CONFIG_EL1 is not set # CONFIG_EL2 is not set # CONFIG_ELPLUS is not set # CONFIG_EL16 is not set # CONFIG_EL3 is not set # CONFIG_3C515 is not set # CONFIG_ELMC is not set # CONFIG_ELMC_II is not set CONFIG_VORTEX=m # CONFIG_LANCE is not set # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set CONFIG_TULIP=m # CONFIG_TC35815 is not set # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set CONFIG_DE4X5=m # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=m # CONFIG_LNE390 is not set # CONFIG_FEALNX is not set # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_NE3210 is not set # CONFIG_ES3210 is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set # CONFIG_8139TOO_8129 is not set # CONFIG_8139_NEW_RX_RESET is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_VIA_RHINE_MMIO is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set # CONFIG_DL2K is not set # CONFIG_MYRI_SBUS is not set # CONFIG_NS83820 is not set CONFIG_HAMACHI=m # CONFIG_YELLOWFIN is not set CONFIG_SK98LIN=m # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set # CONFIG_INPUT_KEYBDEV is not set # CONFIG_INPUT_MOUSEDEV is not set # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 # CONFIG_PRINTER is not set # CONFIG_PPDEV is not set # # I2C support # CONFIG_I2C=m CONFIG_I2C_ALGOBIT=m CONFIG_I2C_PHILIPSPAR=m CONFIG_I2C_ELV=m CONFIG_I2C_VELLEMAN=m CONFIG_I2C_ALGOPCF=m CONFIG_I2C_ELEKTOR=m CONFIG_I2C_CHARDEV=m CONFIG_I2C_PROC=m # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=m CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # CONFIG_ACQUIRE_WDT is not set # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM7101_WDT is not set # CONFIG_SC520_WDT is not set # CONFIG_PCWATCHDOG is not set # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set # CONFIG_WAFER_WDT is not set # CONFIG_I810_TCO is not set # CONFIG_MIXCOMWD is not set # CONFIG_60XX_WDT is not set # CONFIG_SC1200_WDT is not set CONFIG_SOFT_WATCHDOG=m # CONFIG_W83877F_WDT is not set # CONFIG_WDT is not set # CONFIG_WDTPCI is not set # CONFIG_MACHZ_WDT is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set CONFIG_RTC=y # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set # CONFIG_AGP is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_FS_POSIX_ACL is not set CONFIG_QUOTA=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QIFACE_COMPAT=y CONFIG_QIFACE_V1=y # CONFIG_QIFACE_V2 is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_REISERFS_FS=y # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y # CONFIG_ADFS_FS is not set # CONFIG_ADFS_FS_RW is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set CONFIG_EXT3_FS=m CONFIG_JBD=m # CONFIG_JBD_DEBUG is not set CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_UMSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_EFS_FS is not set # CONFIG_JFFS_FS is not set # CONFIG_JFFS2_FS is not set CONFIG_CRAMFS=m CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_NTFS_RW is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set # CONFIG_DEVFS_MOUNT is not set # CONFIG_DEVFS_DEBUG is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_QNX4FS_RW is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UDF_RW is not set # CONFIG_UFS_FS is not set # CONFIG_UFS_FS_WRITE is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set # # Network File Systems # CONFIG_CODA_FS=m # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_ROOT_NFS is not set CONFIG_NFSD=m CONFIG_NFSD_V3=y CONFIG_SUNRPC=m CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_NCP_FS is not set # CONFIG_NCPFS_PACKET_SIGNING is not set # CONFIG_NCPFS_IOCTL_LOCKING is not set # CONFIG_NCPFS_STRONG is not set # CONFIG_NCPFS_NFS_NS is not set # CONFIG_NCPFS_OS2_NS is not set # CONFIG_NCPFS_SMALLDOS is not set # CONFIG_NCPFS_NLS is not set # CONFIG_NCPFS_EXTRAS is not set # CONFIG_ZISOFS_FS is not set CONFIG_ZLIB_FS_INFLATE=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set # CONFIG_OSF_PARTITION is not set # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set # CONFIG_MAC_PARTITION is not set CONFIG_MSDOS_PARTITION=y # CONFIG_BSD_DISKLABEL is not set # CONFIG_MINIX_SUBPARTITION is not set # CONFIG_SOLARIS_X86_PARTITION is not set # CONFIG_UNIXWARE_DISKLABEL is not set # CONFIG_LDM_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set # CONFIG_SUN_PARTITION is not set CONFIG_SMB_NLS=y CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # # CONFIG_SOUND is not set # # USB support # # CONFIG_USB is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_HIGHMEM is not set CONFIG_DEBUG_SLAB=y # CONFIG_DEBUG_IOVIRT is not set # CONFIG_MAGIC_SYSRQ is not set # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_FRAME_POINTER is not set CONFIG_KDB=y # CONFIG_KDB_MODULES is not set # CONFIG_KDB_OFF is not set # # Load all symbols for debugging is required for KDB # CONFIG_KALLSYMS=y -- Regards and thanks Ian -- Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Information Systems Services email: i.d.hardy@soton.ac.uk Southampton University Southampton S017 1BJ, UK. From owner-linux-xfs@oss.sgi.com Wed Sep 18 14:08:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 14:08:08 -0700 (PDT) Received: from mta1.sucs.soton.ac.uk (mta1.sucs.soton.ac.uk [152.78.128.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8IL85tG015399 for ; Wed, 18 Sep 2002 14:08:06 -0700 Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by mta1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8ILD6D9007711 for ; Wed, 18 Sep 2002 22:13:06 +0100 Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA12649842 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 22:13:06 +0100 (BST) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by mailspool1.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IL6M1b023152; Wed, 18 Sep 2002 22:06:22 +0100 From: I.D.Hardy@soton.ac.uk Received: from plum.sucs.soton.ac.uk (plum.sucs.soton.ac.uk [152.78.128.10]) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8IL6Hlj013672; Wed, 18 Sep 2002 22:06:17 +0100 Received: (from idh@localhost) by plum.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA12513678; Wed, 18 Sep 2002 22:06:17 +0100 (BST) Message-Id: <200209182106.WAA12513678@plum.sucs.soton.ac.uk> Subject: Re: Re-occurance of NFS server panics To: knuffie@xs4all.nl (Seth Mos) Date: Wed, 18 Sep 2002 22:06:07 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, O.G.Parchment@soton.ac.uk, linx-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020918223708.03a58ef0@pop.xs4all.nl> from "Seth Mos" at Sep 18, 2002 10:37:45 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean, Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-2.4, required 5, IN_REP_TO, NO_REAL_NAME, SIGNATURE_DELIM) X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-2.4, required 5, IN_REP_TO, NO_REAL_NAME, SIGNATURE_DELIM) X-archive-position: 475 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Seth, I fairly certain its the Qlogic driver for the QLA2200 HBA (driver version 4.27b (I've tried but so far failed to get the more recent 5.38.9 driver to work). The only other possibility (well the only other driver not in the base/XFS kernel) is an intel driver for a e1000 PRO Gigabit Ethernet card (version 3.6.8). Regards Ian > > At 19:31 18-9-2002 +0100, you wrote: > >Steve, > > > >I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of Monday > >16th Sept.) today and got a very similar looking Ooops to the one I > >reported on Monday, see below. I guess it is very difficult to know what > >would have caused any heap corruption. As I understand it there's > >nothing in these latest panics to directly link them with XFS? I need to > >do some more thinking on this. Any pointers would be very welcome. > > What driver have you loaded that taints your kernel. > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > -- -- Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Computing Services email: idh@soton.ac.uk Southampton University i.d.hardy@soton.ac.uk Southampton S017 1BJ, UK. From owner-linux-xfs@oss.sgi.com Wed Sep 18 14:13:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 14:13:20 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e1f0.dsl.mediaWays.net [213.20.225.240]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ILDHtG015920 for ; Wed, 18 Sep 2002 14:13:18 -0700 Received: from indigo-3.berdmann.de ([192.168.1.15] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17rmDA-0003a4-00 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 23:18:16 +0200 Message-ID: <3D88ED97.5010507@berdmann.de> Date: Wed, 18 Sep 2002 23:18:15 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Linus merges XFS References: <20020917000532.A18289@s2y4n2c.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 476 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: be@berdmann.de Precedence: bulk X-list: linux-xfs > saw this on lwn.net. linus had merged XFS in the 2.5 tree. Wooooooooooooooooooooohhhhhhhhhhhhh!!!!!!!!!! From owner-linux-xfs@oss.sgi.com Wed Sep 18 14:23:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 14:23:58 -0700 (PDT) Received: from darwin.libc.org (ucntcme224.dsl.micron.net [206.207.111.224] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8ILNrtG016528 for ; Wed, 18 Sep 2002 14:23:54 -0700 Received: (qmail 9164 invoked from network); 18 Sep 2002 14:11:44 -0000 Received: from ucntcme231.dsl.micron.net (HELO locutus.libc.org) (?TjMbz6QHSHR7A3SDyW9slfZBmYvdILZl?@206.207.111.231) by ucntcme224.dsl.micron.net with SMTP; 18 Sep 2002 14:11:44 -0000 Subject: Re: Linus merges XFS From: Bill Anderson To: "Linux XFS (SGI)" In-Reply-To: <3D88ED97.5010507@berdmann.de> References: <20020917000532.A18289@s2y4n2c.de> <3D88ED97.5010507@berdmann.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 18 Sep 2002 15:28:58 -0600 Message-Id: <1032384538.8292.64.camel@locutus> Mime-Version: 1.0 X-archive-position: 477 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bill@immosys.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-18 at 15:18, Bernhard Erdmann wrote: > > saw this on lwn.net. linus had merged XFS in the 2.5 tree. > > Wooooooooooooooooooooohhhhhhhhhhhhh!!!!!!!!!! > Yup, this means I should now be able to have UMLinux and XFS. Oh yeah! -- Bill Anderson Immosys Rebuilding the network of Tomorrow From owner-linux-xfs@oss.sgi.com Wed Sep 18 16:58:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 16:59:02 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8INwutG019171 for ; Wed, 18 Sep 2002 16:58:57 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id OAA30370 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 14:04:00 -1000 Date: Wed, 18 Sep 2002 14:03:59 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020918140359.A30339@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 478 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Hello - First, we've been running many raid5+XFS, some over 1TB in size: It's great! Thanks for adding this filesystem to Linux. We'd like to update a couple of our systems which are running vanilla 2.4.16+XFS to 2.4.19 (with XFS August 18th snapshot). We're recovering from a disk failure, so I'm currently mounting the fs read-only to be safe. 2.4.16 does this, and replays the log just fine. 2.4.19, however, oopses with a NULL pointer deref in xlog_do_log_recovery(0xf7d8679c, 0x36c58, 0x0). Also of interest, xfs_logprint (version 2.1.2) lists a bunch of entries in cycle 190, and then eventually prints a garbage entry ... bogus version, bogus cycle, etc. ... The 2.4.16 kernel apparently does not find problem here. xfs_logprint's memory usage blows up and eventually it gets oom-killed. Should I send you just the log? (How do I do that?) Thanks again! Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Wed Sep 18 19:18:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 19:19:01 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J2IttG028222 for ; Wed, 18 Sep 2002 19:18:55 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id QAA30829 for linux-xfs@oss.sgi.com; Wed, 18 Sep 2002 16:23:59 -1000 Date: Wed, 18 Sep 2002 16:23:59 -1000 From: Sidik Isani To: linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020918162359.A30809@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020918140359.A30339@cfht.hawaii.edu>; from lksi@cfht.hawaii.edu on Wed, Sep 18, 2002 at 02:03:59PM -1000 X-archive-position: 479 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs Hello - As a follow-up to my previous posting: I just tried the current linux-2.4-xfs from CVS, and the same thing happens (mount crashes and I drop into kdb.) Something is strange about the formatting of the backtrace in kdb ... some lines are definitely scrolling off the top of my console before the "more>" prompt appears. This time the function at the top of my screen is "scrup", but I think there are stack levels above which rolled off the screen (is there a screen height setting in kdb?) Anyway, the crash still happens right after "Starting XFS recovery". Please let me know what I should do next... Thanks! - Sidik From owner-linux-xfs@oss.sgi.com Wed Sep 18 19:38:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 19:38:31 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J2cStG004219 for ; Wed, 18 Sep 2002 19:38:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA02545 for ; Wed, 18 Sep 2002 19:43:32 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA04228; Thu, 19 Sep 2002 12:42:13 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B73A23000B8; Thu, 19 Sep 2002 12:42:12 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 91BB885; Thu, 19 Sep 2002 12:42:12 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Sidik Isani Cc: linux-xfs@sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) In-reply-to: Your message of "Wed, 18 Sep 2002 16:23:59 -1000." <20020918162359.A30809@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Sep 2002 12:42:07 +1000 Message-ID: <3697.1032403327@kao2.melbourne.sgi.com> X-archive-position: 480 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 18 Sep 2002 16:23:59 -1000, Sidik Isani wrote: > As a follow-up to my previous posting: I just tried the current > linux-2.4-xfs from CVS, and the same thing happens (mount crashes > and I drop into kdb.) Something is strange about the formatting > of the backtrace in kdb ... some lines are definitely scrolling > off the top of my console before the "more>" prompt appears. This > time the function at the top of my screen is "scrup", but I think > there are stack levels above which rolled off the screen (is there > a screen height setting in kdb?) set LINES 15 The default LINES is 24 which matches the screen, but only if all lines are <= 80 characters. kdb does not track long lines so it does not detect wraparound. You are much better off using kdb over a serial console and capturing the output on a second machine - no problems with lost lines then. From owner-linux-xfs@oss.sgi.com Wed Sep 18 21:18:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 21:18:38 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J4IWtG008871 for ; Wed, 18 Sep 2002 21:18:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id VAA04289 for ; Wed, 18 Sep 2002 21:23:37 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA05031; Thu, 19 Sep 2002 14:22:17 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) with ESMTP id g8J4M3Su001371; Thu, 19 Sep 2002 14:22:03 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.6/8.12.6/Debian-5) id g8J4M2LC001369; Thu, 19 Sep 2002 14:22:02 +1000 Date: Thu, 19 Sep 2002 14:22:02 +1000 From: Nathan Scott To: Sidik Isani Cc: linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020919042202.GC586@frodo> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020918162359.A30809@cfht.hawaii.edu> User-Agent: Mutt/1.4i X-archive-position: 481 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Hi, On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > Hello - > > As a follow-up to my previous posting: I just tried the current > linux-2.4-xfs from CVS, and the same thing happens (mount crashes > and I drop into kdb.) Something is strange about the formatting > of the backtrace in kdb ... some lines are definitely scrolling > off the top of my console before the "more>" prompt appears. This > time the function at the top of my screen is "scrup", but I think > there are stack levels above which rolled off the screen (is there > a screen height setting in kdb?) > > Anyway, the crash still happens right after "Starting XFS recovery". > Please let me know what I should do next... > I seem to remember Steve fixing an endian problem in the log code at one point several months ago - this may be what's biting you - perhaps you have a little endian number somewhere in the on disk log and the new kernel is expecting it is as big endian. If so, the right thing to do would be to run recovery using the old kernel - so first mount, then unmount the filesystem. This should complete fine with the old kernel. Then run xfs_repair on the filesystem. This will zero out the log in phase 2, so you can start afresh. Once you've done those things you should be able to mount and use this filesystem with the latest kernel. Hope this helps. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Sep 18 23:07:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Sep 2002 23:07:45 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J67etG012744 for ; Wed, 18 Sep 2002 23:07:40 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id UAA31850; Wed, 18 Sep 2002 20:12:42 -1000 Date: Wed, 18 Sep 2002 20:12:41 -1000 From: Sidik Isani To: Nathan Scott Cc: Sidik Isani , linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020918201241.A31826@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> <20020919042202.GC586@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020919042202.GC586@frodo>; from nathans@sgi.com on Thu, Sep 19, 2002 at 02:22:02PM +1000 X-archive-position: 482 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs On Thu, Sep 19, 2002 at 02:22:02PM +1000, Nathan Scott wrote: > Hi, > > On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > > > > Anyway, the crash still happens right after "Starting XFS recovery". > > Please let me know what I should do next... > > > > I seem to remember Steve fixing an endian problem in the log code > at one point several months ago - this may be what's biting you - > perhaps you have a little endian number somewhere in the on disk > log and the new kernel is expecting it is as big endian. > > If so, the right thing to do would be to run recovery using the > old kernel - so first mount, then unmount the filesystem. This > should complete fine with the old kernel. Then run xfs_repair > on the filesystem. This will zero out the log in phase 2, so > you can start afresh. Once you've done those things you should > be able to mount and use this filesystem with the latest kernel. Great. That makes perfect sense. I guess it is not reasonable to expect the kernel itself to repair damage from previous bugs. Could it help you to have a copy of my log anyway, to at least make the new kernel detect this corruption in a more elegant way than crashing? I do see checks in there masking bits for valid version numbers and all. I wonder why these are not finding it. Another RAID with totally different data on it does the same thing. Thanks for solving my problem (well ... I'll let you know soon ;-) Be seeing you, - Sidik From owner-linux-xfs@oss.sgi.com Thu Sep 19 00:23:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 00:23:12 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8J7N8tG014713 for ; Thu, 19 Sep 2002 00:23:08 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA01254 for ; Thu, 19 Sep 2002 00:28:12 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA87326 for linux-xfs@oss.sgi.com; Thu, 19 Sep 2002 17:26:54 +1000 (EST) Date: Thu, 19 Sep 2002 17:26:54 +1000 (EST) From: Nathan Scott Message-Id: <200209190726.RAA87326@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA X-archive-position: 483 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Further work on a generic benchmarking framework. Date: Thu Sep 19 00:26:17 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/sector-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127847a cmd/xfstests/tools/auto-qa - 1.36 - send off the benchmark results in the same way we do the other tests. cmd/xfstests/bench - 1.3 - make important arguments mandatory, do a better job of collecting results. cmd/xfstests/run.dbench - 1.3 - fix up cleanup, simplify the results reporting. cmd/xfstests/run.tar - 1.5 - fix up cleanup after running tar. From owner-linux-xfs@oss.sgi.com Thu Sep 19 04:55:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 04:55:05 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JBt0tG018514 for ; Thu, 19 Sep 2002 04:55:00 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA73787; Thu, 19 Sep 2002 07:00:01 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-17.corp.sgi.com [134.15.64.17]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id HAA56101; Thu, 19 Sep 2002 07:00:01 -0500 (CDT) Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) From: Stephen Lord To: Sidik Isani Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <20020918201241.A31826@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> <20020919042202.GC586@frodo> <20020918201241.A31826@cfht.hawaii.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 06:58:14 -0500 Message-Id: <1032436696.1114.8.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 484 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 01:12, Sidik Isani wrote: > On Thu, Sep 19, 2002 at 02:22:02PM +1000, Nathan Scott wrote: > > Hi, > > > > On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > > > > > > Anyway, the crash still happens right after "Starting XFS recovery". > > > Please let me know what I should do next... > > > > > > > I seem to remember Steve fixing an endian problem in the log code > > at one point several months ago - this may be what's biting you - > > perhaps you have a little endian number somewhere in the on disk > > log and the new kernel is expecting it is as big endian. > > > > If so, the right thing to do would be to run recovery using the > > old kernel - so first mount, then unmount the filesystem. This > > should complete fine with the old kernel. Then run xfs_repair > > on the filesystem. This will zero out the log in phase 2, so > > you can start afresh. Once you've done those things you should > > be able to mount and use this filesystem with the latest kernel. > > Great. That makes perfect sense. I guess it is not reasonable > to expect the kernel itself to repair damage from previous bugs. > Could it help you to have a copy of my log anyway, to at least > make the new kernel detect this corruption in a more elegant way > than crashing? I do see checks in there masking bits for valid > version numbers and all. I wonder why these are not finding it. > Another RAID with totally different data on it does the same thing. > Thanks for solving my problem (well ... I'll let you know soon ;-) > > Be seeing you, > > - Sidik > This is what I fixed: revision 1.240 date: 2002/08/29 21:26:29; author: lord; state: Exp; lines: +2 -1 modid: 2.4.x-xfs:slinx:126410a when processing unlinked inodes and dealing with the di_next_unlinked field, endian flip it. However, this code is purely in recovery dealing with what is in the log, not with how the log is layed down. An old kernel would have crashed in the same way on this problem. Basically it would arise on a crash where the log had a lot of unlinked files to remove. There were some earlier fixes, too, but nothing which would make things worse so far as I can see. I presume in your original message you are saying you have the fs and the 2.4.16 kernel will mount it and the 2.4.19 one will not? Is this something you have done more than one? If you are mounting readonly, you must also be specifying norecovery, otherwise the first mount will actually have done a recovery on the fs. Probably too late for this, but if not, can you send a complete backtrace, and the xlog printout you have, you might want to get new commands first, there have been changes in logprint I think, we are at 2.3.3 now. Steve From owner-linux-xfs@oss.sgi.com Thu Sep 19 10:10:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 10:10:44 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [212.34.181.86]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JHAftG028967 for ; Thu, 19 Sep 2002 10:10:42 -0700 Received: (from hch@localhost) by verein.lst.de (8.11.6/8.11.6) id g8JHFms22694 for linux-xfs@oss.sgi.com; Thu, 19 Sep 2002 19:15:48 +0200 Resent-Message-Id: <200209191715.g8JHFms22694@verein.lst.de> Received: from tolkor.sgi.com ([198.149.18.6]) by verein.lst.de (8.11.6/8.11.6) with ESMTP id g8JHECu22548 for ; Thu, 19 Sep 2002 19:14:13 +0200 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g8JHEVS9015846 for ; Thu, 19 Sep 2002 12:14:31 -0500 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA76579 for ; Thu, 19 Sep 2002 12:14:06 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id MAA48823 for ; Thu, 19 Sep 2002 12:14:05 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K0SnQ10513 for hch@lst.de; Thu, 19 Sep 2002 20:28:49 -0400 Date: Thu, 19 Sep 2002 20:28:49 -0400 From: Christoph Hellwig Message-Id: <200209200028.g8K0SnQ10513@dhcp212.munich.sgi.com> Subject: TAKE - Sanitize some function names Resent-From: hch@lst.de Resent-Date: Thu, 19 Sep 2002 19:15:48 +0200 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 485 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: linux-xfs Sanitize some names in xfs_aops.c, especially a less offending name for linvfs_pb_bmap Date: Thu Sep 19 10:11:58 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127872a linux/fs/xfs/linux/xfs_aops.c - 1.5 - Sanitize some names, especially a less offending name for linvfs_pb_bmap From owner-linux-xfs@oss.sgi.com Thu Sep 19 10:11:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 10:11:59 -0700 (PDT) Received: from mta3.sucs.soton.ac.uk (mta3.sucs.soton.ac.uk [152.78.128.142]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JHButG029127 for ; Thu, 19 Sep 2002 10:11:56 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta3.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8JHH1NG013232; Thu, 19 Sep 2002 18:17:01 +0100 Reply-To: From: "Ian D. Hardy" To: , "'Steve Lord'" Cc: , , "'Russell Cattelan'" Subject: RE: Re-occurance of NFS server panics Date: Thu, 19 Sep 2002 18:17:01 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <200209182049.VAA11727544@plum.sucs.soton.ac.uk> X-MailScanner: Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-6.5, required 5, IN_REP_TO, OUTLOOK_FWD, DOUBLE_CAPSWORD, SIGNATURE_DELIM, WEIRD_PORT) X-archive-position: 486 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve, + I'm not sure if this provides any more info but I've just had another crash on this server, again caught by 'slab.c', this time from an 'nfsd' process: Reading Oops report from the terminal kernel BUG at slab.c:1218! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P EFLAGS: 00010002 eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 856, stackpage=f381f000) Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc ebdfe000 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a c1c0e060 f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 000003a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid operand due to oops @ 0xc0132aeb eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 xds = 0xc0250018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf381fe58 [0]kdb> kernel BUG at slab.c:1218! invalid operand: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 856, stackpage=f381f000) Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc ebdfe000 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a c1c0e060 f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 000003a0 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 >>EIP; c0132aea <===== Trace; c0132e32 Trace; c013360a Trace; c010cef8 Trace; c02558a2 Trace; c02558bc Trace; c0255a36 <__kfree_skb+116/120> Trace; c02557ea Trace; c0255898 Trace; c0255e10 Trace; f89d0488 <[sunrpc]svc_udp_recvfrom+128/380> Trace; f89d1820 <[sunrpc]svc_send+70/1a0> Trace; f89d14d8 <[sunrpc]svc_recv+2c8/470> Trace; f8a252b4 <[nfsd]nfsd+114/350> Trace; c0107296 Trace; f8a251a0 <[nfsd]nfsd+0/350> Code; c0132aea 00000000 <_EIP>: Code; c0132aea <===== 0: 0f 0b ud2a <===== Code; c0132aec 2: c2 04 a0 ret $0xa004 Code; c0132aee 5: 54 push %esp Code; c0132af0 6: 2b c0 sub %eax,%eax Code; c0132af2 8: 89 d8 mov %ebx,%eax Code; c0132af4 a: 0f af c1 imul %ecx,%eax Code; c0132af6 d: 8d 04 30 lea (%eax,%esi,1),%eax Code; c0132afa 10: 39 c5 cmp %eax,%ebp Code; c0132afc 12: 74 08 je 1c <_EIP+0x1c> c0132b06 Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid operand eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 -----Original Message----- From: I.D.Hardy@soton.ac.uk [mailto:I.D.Hardy@soton.ac.uk] Sent: 18 September 2002 21:49 Steve +, > > On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > > Steve, > > > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > > >> Steve, > > >> > > >> Thanks for the quick response. I don't always get a Oops output > > >> (sometimes the server just hangs and requires a reboot). However as > > it > > >> happens the server has just crashed again with the following Oops > > >> (through 'ksymoops'): > > > > > >This one suggests heap corruption more than anything else. > > > > > >Steve > > > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of > > Monday 16th Sept.) today and got a very similar looking Ooops to the > > one I reported on Monday, see below. I guess it is very difficult to > > know what would have caused any heap corruption. As I understand it > > there's nothing in these latest panics to directly link them with > > XFS? I need to do some more thinking on this. Any pointers would be > > very welcome. > > > > Regards Ian Hardy > > > > > > kernel BUG at slab.c:1439! > > > OK, so you have slab debugging turned on, which I was going to ask you > to do. Looks like someone walked off the end of an allocation here, > that is progress. > > So, the question is what did it, thats the really hard part! Is this > machine just running XFS via NFS, or is it doing anything else? Also, > which options do you have turned on in XFS, in fact, sending the whole > kernel config might be an idea. > > Steve > Thanks for your continued help/interest, it is much appreciated. The server (dual 1Ghz PIII, with 1Gbyte memory) is a dedicated NFS fileserver (no users have direct access to it). It is serving ~260 NFS clients (part of a computational/Beowulf system). The server has a 40Gbyte IDE system disk and 2 FC-IDE connected RAID units (each with ~500Gbytes usable storage - RAID 5 configuration). The RAID units are connected via a Qlogic QLA2200 HBA and a FC switch. The 2 RAID units are stripped together(RAID 0) using the kernel 'md' RAID driver. Below is the kernel configuration file: -- Regards and thanks Ian -- Ian Hardy Tel: 023 80593577 Research Services Fax: 023 80593131 Information Systems Services email: i.d.hardy@soton.ac.uk Southampton University Southampton S017 1BJ, UK. From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:18:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:18:51 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIImtG031267 for ; Thu, 19 Sep 2002 11:18:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA77528 for ; Thu, 19 Sep 2002 13:23:47 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA57545 for ; Thu, 19 Sep 2002 13:23:45 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K1chX12214 for linux-xfs@oss.sgi.com; Thu, 19 Sep 2002 21:38:43 -0400 Resent-Message-Id: <200209200138.g8K1chX12214@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA98236 for ; Thu, 19 Sep 2002 13:20:52 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K1ZoB12204 for hch@sgi.com; Thu, 19 Sep 2002 21:35:50 -0400 Date: Thu, 19 Sep 2002 21:35:50 -0400 From: Christoph Hellwig Message-Id: <200209200135.g8K1ZoB12204@dhcp212.munich.sgi.com> Subject: TAKE - Simplify xfs_dir_lookup_int Resent-Date: Thu, 19 Sep 2002 21:38:43 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 487 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 19 11:19:37 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127879a linux/fs/xfs/xfs_vnodeops.c - 1.564 - Adopt for new xfs_dir_lookup_int prototype linux/fs/xfs/xfs_utils.c - 1.52 - Remove flags argument from xfs_dir_lookup_int. DLF_IGET is always set and now implied. DLF_LOCK_SHARED is replaced by passing in the lock flags directly. linux/fs/xfs/xfs_utils.h - 1.26 linux/fs/xfs/xfs_rename.c - 1.41 - Adopt for new xfs_dir_lookup_int prototype From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:43:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:43:41 -0700 (PDT) Received: from mbi.ufl.edu (mbi-00.mbi.ufl.edu [159.178.51.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIhctG031950 for ; Thu, 19 Sep 2002 11:43:39 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: Status of 2.5.x CVS now Date: Thu, 19 Sep 2002 14:48:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Status of 2.5.x CVS now Thread-Index: AcJgAJJznz3wm4ZNRFeGtqeXAU50hQAC+ugA From: "Jon K. Akers" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8JIhdtG031951 X-archive-position: 488 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jka@ufbi.ufl.edu Precedence: bulk X-list: linux-xfs I was just wondering what is going to happen to the status of the 2.5.x CVS tree now that XFS has been put into the actually 2.5.x tree by Linus. From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:44:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:44:10 -0700 (PDT) Received: from clubphoto.com (mail-gw.clubphoto.com [64.124.34.66]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIi8tG032004 for ; Thu, 19 Sep 2002 11:44:08 -0700 Received: from [192.168.168.25] (gabe-g4.clubphoto.local [192.168.168.25]) by clubphoto.com (8.9.3/8.9.3) with ESMTP id LAA25681 for ; Thu, 19 Sep 2002 11:49:16 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 19 Sep 2002 11:49:43 -0700 Subject: {evil tone} is it safe? From: "Gabe E. Nydick" To: linux-xfs Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-archive-position: 489 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gnydick@clubphoto.com Precedence: bulk X-list: linux-xfs So, I was a pilot user of XFS 1.0 and it caused all sorts of problems and corruptions, but I stuck with it until about 2.4.17, which was around when ext3 was ready, give or take some time. I would like to get the performance and scalability back of XFS, so here is the question. Is it finally ready? What are the outstanding bugs that need to be fixed. - Gabe From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:50:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:50:21 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIoFtG000510 for ; Thu, 19 Sep 2002 11:50:15 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA77363; Thu, 19 Sep 2002 13:55:18 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id NAA98754; Thu, 19 Sep 2002 13:55:17 -0500 (CDT) Subject: Re: Status of 2.5.x CVS now From: Eric Sandeen To: "Jon K. Akers" Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Sep 2002 13:49:59 -0500 Message-Id: <1032461399.2159.79.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 490 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Hi Jon - A few things to note... DMAPI and ACLS are not in 2.5, so if you need those, you'll still need CVS. I think I'll keep pushing weekly snapshot patches against 2.5, to make it easy to get those things. CVS is really just our internal source control system exported to the outside, and of course development will continue, so we'll probably keep pushing CVS. In short, you can get most of XFS in 2.5 from Linus now, but we'll keep the CVS archive available as well. -Eric On Thu, 2002-09-19 at 13:48, Jon K. Akers wrote: > I was just wondering what is going to happen to the status of the 2.5.x > CVS tree now that XFS has been put into the actually 2.5.x tree by > Linus. > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Sep 19 11:51:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 11:51:43 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JIpetG000689 for ; Thu, 19 Sep 2002 11:51:41 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 46A661DA51C; Thu, 19 Sep 2002 11:56:49 -0700 (PDT) Date: Thu, 19 Sep 2002 11:56:49 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: [PATCH] 2.4.19-xfs EFSCORRUPTED redefine to EIO Message-ID: <20020919185649.GA32227@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 491 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs For corrupted filesystem right now, XFS can return EFSCORRUPTED (presently set to 990) to userspace. This is pointless as (almost) no user-space code knows that this mean, it's inherently not portable, and rather ugly not to mention completely unmanageable if every filesystem and/or driver decides to invent their own error codes. I suggest this trivial patch (2.4.x tree) to redefine it as EIO. Obviously, a similar fix should also go into 2.5.x. --cw diff -u -u -r1.84 xfs_linux.h --- fs/xfs/linux/xfs_linux.h 2002/09/05 05:37:11 1.84 +++ fs/xfs/linux/xfs_linux.h 2002/09/19 18:42:21 @@ -133,17 +133,11 @@ #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ /* - * XXX EFSCORRUPTED needs a real value in errno.h. asm-i386/errno.h won't - * return codes out of its known range in errno. - * XXX Also note: needs to be < 1000 and fairly unique on Linux (mustn't - * conflict with any code we use already or any code a driver may use) - * XXX Some options (currently we do #2): - * 1/ New error code ["Filesystem is corrupted", _after_ glibc updated] - * 2/ 990 ["Unknown error 990"] - * 3/ EUCLEAN ["Structure needs cleaning"] - * 4/ Convert EFSCORRUPTED to EIO [just prior to return into userspace] + * EFSCORRUPTED previously returned 990 which is a rather meaningless + * error code. Rather than invent new error codes every picosecond or + * so, lets just pick something appropriate and stick with it. */ -#define EFSCORRUPTED 990 /* Filesystem is corrupted */ +#define EFSCORRUPTED EIO /* Filesystem is corrupted */ #define SYNCHRONIZE() barrier() #define lbolt jiffies From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:00:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:01:00 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJ0wtG001509 for ; Thu, 19 Sep 2002 12:00:58 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA76386; Thu, 19 Sep 2002 14:06:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA00703; Thu, 19 Sep 2002 14:06:00 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8JJ2Ad32738; Thu, 19 Sep 2002 14:02:10 -0500 Subject: Re: [PATCH] 2.4.19-xfs EFSCORRUPTED redefine to EIO From: Steve Lord To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020919185649.GA32227@tapu.f00f.org> References: <20020919185649.GA32227@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 14:02:10 -0500 Message-Id: <1032462130.29705.339.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 492 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 13:56, Chris Wedgwood wrote: > For corrupted filesystem right now, XFS can return EFSCORRUPTED > (presently set to 990) to userspace. > > This is pointless as (almost) no user-space code knows that this mean, > it's inherently not portable, and rather ugly not to mention > completely unmanageable if every filesystem and/or driver decides to > invent their own error codes. > > I suggest this trivial patch (2.4.x tree) to redefine it as EIO. > Obviously, a similar fix should also go into 2.5.x. Except that the filesystem internally needs to be able to tell the difference between the two. There are actions taken upon EFSCORRUPTED which we may not want to take on EIO. Having said that in most cases where we get EIO from underneath we would probably map it to EFSCORRUPTED anyway. So, I think this would need some major auditing before putting it in, we reference EFSCORRUPTED in about 100 places. Steve > > > --cw > > > > > > diff -u -u -r1.84 xfs_linux.h > --- fs/xfs/linux/xfs_linux.h 2002/09/05 05:37:11 1.84 > +++ fs/xfs/linux/xfs_linux.h 2002/09/19 18:42:21 > @@ -133,17 +133,11 @@ > #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ > > /* > - * XXX EFSCORRUPTED needs a real value in errno.h. asm-i386/errno.h won't > - * return codes out of its known range in errno. > - * XXX Also note: needs to be < 1000 and fairly unique on Linux (mustn't > - * conflict with any code we use already or any code a driver may use) > - * XXX Some options (currently we do #2): > - * 1/ New error code ["Filesystem is corrupted", _after_ glibc updated] > - * 2/ 990 ["Unknown error 990"] > - * 3/ EUCLEAN ["Structure needs cleaning"] > - * 4/ Convert EFSCORRUPTED to EIO [just prior to return into userspace] > + * EFSCORRUPTED previously returned 990 which is a rather meaningless > + * error code. Rather than invent new error codes every picosecond or > + * so, lets just pick something appropriate and stick with it. > */ > -#define EFSCORRUPTED 990 /* Filesystem is corrupted */ > +#define EFSCORRUPTED EIO /* Filesystem is corrupted */ > > #define SYNCHRONIZE() barrier() > #define lbolt jiffies > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:13:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:13:06 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJD2tG002153 for ; Thu, 19 Sep 2002 12:13:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA76309; Thu, 19 Sep 2002 14:18:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id OAA80097; Thu, 19 Sep 2002 14:18:05 -0500 (CDT) Subject: Re: Status of 2.5.x CVS now From: Eric Sandeen To: Jens Axboe Cc: "Jon K. Akers" , linux-xfs@oss.sgi.com In-Reply-To: <20020919191454.GF936@suse.de> References: <1032461399.2159.79.camel@stout.americas.sgi.com> <20020919191454.GF936@suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 19 Sep 2002 14:12:46 -0500 Message-Id: <1032462766.1541.81.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 493 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Yep :) On Thu, 2002-09-19 at 14:14, Jens Axboe wrote: > And pulling I hope, at least you'll need to pull the bio_add_page() > changes from bk-current into cvs to have a working xfs. -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:20:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:21:03 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJKstG002963 for ; Thu, 19 Sep 2002 12:20:56 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA75715; Thu, 19 Sep 2002 14:25:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA57775; Thu, 19 Sep 2002 14:25:54 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8JJM5c00464; Thu, 19 Sep 2002 14:22:05 -0500 Subject: RE: Re-occurance of NFS server panics From: Steve Lord To: I.D.Hardy@soton.ac.uk Cc: linux-xfs@oss.sgi.com, O.G.Parchment@soton.ac.uk, "'Russell Cattelan'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 14:22:05 -0500 Message-Id: <1032463325.29705.398.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 494 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 12:17, Ian D. Hardy wrote: > Steve, + > > I'm not sure if this provides any more info but I've just had another > crash on this server, again caught by 'slab.c', this time from an 'nfsd' > process: Well, either someone trampled on some memory allocation headers they should not have and confused the code in a precise direction, or, the pointer passed into the free was a little out of the range it should have been. I do not suppose there is anyway you can remove the binary only modules from your kernel. From the sound of it they are pretty fundamental to your setup - the disk driver and the network driver. If the free really is a bogus address of some form, then it is a network packet, and we definitely do not do those. Also, the fact that this corruption seems specific to your setup says investigating those drivers some more might be beneficial. Steve > > Reading Oops report from the terminal > kernel BUG at slab.c:1218! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > EFLAGS: 00010002 > eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 > esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 856, stackpage=f381f000) > Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc > ebdfe000 > 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a > c1c0e060 > f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 > 000003a0 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] > > Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 > > Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid > operand > due to oops @ 0xc0132aeb > eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 > esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb > ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 > xds = 0xc0250018 xes = 0x00000018 origeax = 0xffffffff ®s = > 0xf381fe58 > [0]kdb> > kernel BUG at slab.c:1218! > invalid operand: 0000 > CPU: 0 > EIP: 0010:[] Tainted: P > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010002 > eax: c1c0e060 ebx: 00091858 ecx: 00001000 edx: 000005a6 > esi: 5a5a5a5a edi: c96c8bcc ebp: ebdfe000 esp: f381fe8c > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 856, stackpage=f381f000) > Stack: ebdfe000 c96c8bcc ebdff000 ebdfe000 c0132e33 c1c0e060 c96c8bcc > ebdfe000 > 0000001b f7ee5720 f7ee5694 c1c0e060 008c0f70 eeafd000 c013360a > c1c0e060 > f7ee5714 0000001e 00000286 eeafd000 ed79ffff c1c0e4d0 c010cef8 > 000003a0 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] > Code: 0f 0b c2 04 a0 54 2b c0 89 d8 0f af c1 8d 04 30 39 c5 74 08 > > >>EIP; c0132aea <===== > Trace; c0132e32 > Trace; c013360a > Trace; c010cef8 > Trace; c02558a2 > Trace; c02558bc > Trace; c0255a36 <__kfree_skb+116/120> > Trace; c02557ea > Trace; c0255898 > Trace; c0255e10 > Trace; f89d0488 <[sunrpc]svc_udp_recvfrom+128/380> > Trace; f89d1820 <[sunrpc]svc_send+70/1a0> > Trace; f89d14d8 <[sunrpc]svc_recv+2c8/470> > Trace; f8a252b4 <[nfsd]nfsd+114/350> > Trace; c0107296 > Trace; f8a251a0 <[nfsd]nfsd+0/350> > Code; c0132aea > 00000000 <_EIP>: > Code; c0132aea <===== > 0: 0f 0b ud2a <===== > Code; c0132aec > 2: c2 04 a0 ret $0xa004 > Code; c0132aee > 5: 54 push %esp > Code; c0132af0 > 6: 2b c0 sub %eax,%eax > Code; c0132af2 > 8: 89 d8 mov %ebx,%eax > Code; c0132af4 > a: 0f af c1 imul %ecx,%eax > Code; c0132af6 > d: 8d 04 30 lea (%eax,%esi,1),%eax > Code; c0132afa > 10: 39 c5 cmp %eax,%ebp > Code; c0132afc > 12: 74 08 je 1c <_EIP+0x1c> c0132b06 > > > Entering kdb (current=0xf381e000, pid 856) on processor 0 Oops: invalid > operand > eax = 0xc1c0e060 ebx = 0x00091858 ecx = 0x00001000 edx = 0x000005a6 > esi = 0x5a5a5a5a edi = 0xc96c8bcc esp = 0xf381fe8c eip = 0xc0132aeb > ebp = 0xebdfe000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010002 > > > -----Original Message----- > From: I.D.Hardy@soton.ac.uk [mailto:I.D.Hardy@soton.ac.uk] > Sent: 18 September 2002 21:49 > > Steve +, > > > > > On Wed, 2002-09-18 at 13:31, Ian D. Hardy wrote: > > > Steve, > > > > > > >On Mon, 2002-09-16 at 11:56, Ian D. Hardy wrote: > > > >> Steve, > > > >> > > > >> Thanks for the quick response. I don't always get a Oops output > > > >> (sometimes the server just hangs and requires a reboot). However > as > > > it > > > >> happens the server has just crashed again with the following Oops > > > >> (through 'ksymoops'): > > > > > > > >This one suggests heap corruption more than anything else. > > > > > > > >Steve > > > > > > I upgraded the kernel to the current CVS (2.4.19-xfs) tree (as of > > > Monday 16th Sept.) today and got a very similar looking Ooops to the > > > > one I reported on Monday, see below. I guess it is very difficult to > > > > know what would have caused any heap corruption. As I understand it > > > there's nothing in these latest panics to directly link them with > > > XFS? I need to do some more thinking on this. Any pointers would be > > > very welcome. > > > > > > Regards Ian Hardy > > > > > > > > > kernel BUG at slab.c:1439! > > > > > > OK, so you have slab debugging turned on, which I was going to ask you > > > to do. Looks like someone walked off the end of an allocation here, > > that is progress. > > > > So, the question is what did it, thats the really hard part! Is this > > machine just running XFS via NFS, or is it doing anything else? Also, > > which options do you have turned on in XFS, in fact, sending the whole > > > kernel config might be an idea. > > > > Steve > > > > Thanks for your continued help/interest, it is much appreciated. > > The server (dual 1Ghz PIII, with 1Gbyte memory) is a dedicated NFS > fileserver (no users have direct access to it). It is serving ~260 NFS > clients (part of a computational/Beowulf system). The server has a > 40Gbyte IDE system disk and 2 FC-IDE connected RAID units (each with > ~500Gbytes usable storage - RAID 5 configuration). The RAID units are > connected via a Qlogic QLA2200 HBA and a FC switch. The 2 RAID units are > stripped together(RAID 0) using the kernel 'md' RAID driver. > > Below is the kernel configuration file: > > > -- > > Regards and thanks > > Ian > > -- > Ian Hardy Tel: 023 80593577 > Research Services Fax: 023 80593131 > Information Systems Services email: i.d.hardy@soton.ac.uk > > Southampton University > Southampton S017 1BJ, UK. > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 19 12:22:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 12:22:30 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JJMStG003155 for ; Thu, 19 Sep 2002 12:22:28 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id MAA03857 for ; Thu, 19 Sep 2002 12:24:32 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA77941; Thu, 19 Sep 2002 14:23:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA47511; Thu, 19 Sep 2002 14:23:16 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8JJJRR00455; Thu, 19 Sep 2002 14:19:27 -0500 Subject: Re: Status of 2.5.x CVS now From: Steve Lord To: Eric Sandeen Cc: Jens Axboe , "Jon K. Akers" , linux-xfs@oss.sgi.com In-Reply-To: <1032462766.1541.81.camel@stout.americas.sgi.com> References: <1032461399.2159.79.camel@stout.americas.sgi.com> <20020919191454.GF936@suse.de> <1032462766.1541.81.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 19 Sep 2002 14:19:26 -0500 Message-Id: <1032463166.8022.387.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 495 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 2002-09-19 at 14:12, Eric Sandeen wrote: > Yep :) > > On Thu, 2002-09-19 at 14:14, Jens Axboe wrote: > > And pulling I hope, at least you'll need to pull the bio_add_page() > > changes from bk-current into cvs to have a working xfs. I have a built 2.5.36 tree here, but other work is keeping me from testing it. I have conference calls until 7:30 this evening, unless I can find a victim, it may take a while. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:10:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:10:33 -0700 (PDT) Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKATtG005483 for ; Thu, 19 Sep 2002 13:10:30 -0700 Received: from brick.kernel.dk ([195.249.94.204] helo=burns.home.kernel.dk) by virtualhost.dk with esmtp (Exim 3.35 #1) id 17s6lk-0002qB-00; Thu, 19 Sep 2002 21:15:20 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 4.10) id 17s6lK-0008U7-00; Thu, 19 Sep 2002 21:14:54 +0200 Date: Thu, 19 Sep 2002 21:14:54 +0200 From: Jens Axboe To: Eric Sandeen Cc: "Jon K. Akers" , linux-xfs@oss.sgi.com Subject: Re: Status of 2.5.x CVS now Message-ID: <20020919191454.GF936@suse.de> References: <1032461399.2159.79.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032461399.2159.79.camel@stout.americas.sgi.com> X-archive-position: 496 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: axboe@suse.de Precedence: bulk X-list: linux-xfs On Thu, Sep 19 2002, Eric Sandeen wrote: > Hi Jon - > > A few things to note... > > DMAPI and ACLS are not in 2.5, so if you need those, you'll still need > CVS. I think I'll keep pushing weekly snapshot patches against 2.5, to > make it easy to get those things. > > CVS is really just our internal source control system exported to the > outside, and of course development will continue, so we'll probably keep > pushing CVS. > > In short, you can get most of XFS in 2.5 from Linus now, but we'll keep > the CVS archive available as well. And pulling I hope, at least you'll need to pull the bio_add_page() changes from bk-current into cvs to have a working xfs. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:25:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:25:40 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKPbtG006564 for ; Thu, 19 Sep 2002 13:25:38 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id AFC0D1DA55F; Thu, 19 Sep 2002 13:30:46 -0700 (PDT) Date: Thu, 19 Sep 2002 13:30:46 -0700 From: Chris Wedgwood To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: [PATCH] (take #2) 2.4.19-xfs -EFSCORRUPTED expose as -EIO Message-ID: <20020919203046.GA357@tapu.f00f.org> References: <20020919185649.GA32227@tapu.f00f.org> <1032462130.29705.339.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032462130.29705.339.camel@jen.americas.sgi.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 497 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Sep 19, 2002 at 02:02:10PM -0500, Steve Lord wrote: So, I think this would need some major auditing before putting it in, we reference EFSCORRUPTED in about 100 places. Yes, I was just talking to hch and sandeen about this. Attached is another *suggestion* (ie. it needs to be verified carefully and a couple of minor changes). --cw -- -- snip snip -- ouch ouch -- -- xfs_aops.c | 18 ++++++++--------- xfs_iops.c | 63 ++++++++++++++++++++++++++++++------------------------------ xfs_linux.h | 22 ++++++++++++-------- xfs_super.c | 4 +-- 4 files changed, 56 insertions(+), 51 deletions(-) Index: linux/xfs_aops.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_aops.c,v retrieving revision 1.5 diff -u -w -b -B -r1.5 xfs_aops.c --- linux/xfs_aops.c 2002/09/19 17:11:58 1.5 +++ linux/xfs_aops.c 2002/09/19 20:21:07 @@ -150,16 +150,14 @@ /* Are we off the end of the file ? */ if (page->index >= end_index) { unsigned offset = inode->i_size & (PAGE_CACHE_SIZE-1); - if ((page->index >= end_index+1) || !offset) { - ret = -EIO; - goto out; + if ((page->index >= end_index+1) || !offset) + goto out_flush; } - } ret = delalloc_convert(inode, page, 0, 0); -out: if (ret < 0) { +out_flush: block_flushpage(page, 0); ClearPageUptodate(page); @@ -558,6 +556,8 @@ return err; } +/* maybe be called (indirectly) from Linux so we may have to fix error + codes */ STATIC int linvfs_get_block_core( struct inode *inode, @@ -586,7 +586,7 @@ create ? flags : PBF_READ, NULL, (struct page_buf_bmap_s *)&pbmap, &retpbbm, error); if (error) - return -error; + return linux_err_code(-error); if (retpbbm == 0) return 0; @@ -690,7 +689,7 @@ struct file *unused, struct page *page) { - return block_read_full_page(page, linvfs_get_block); + return linux_err_code(block_read_full_page(page, linvfs_get_block)); } STATIC int @@ -747,7 +746,7 @@ if (flagset) current->flags &= ~PF_NOIO; - return error; + return linux_err_code(error); out_fail: SetPageDirty(page); @@ -873,7 +872,7 @@ length -= size; } - return (error ? error : (int)(total - length)); + return (error ? linux_err_code(error) : (int)(total - length)); } /* Index: linux/xfs_iops.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_iops.c,v retrieving revision 1.174 diff -u -w -b -B -r1.174 xfs_iops.c --- linux/xfs_iops.c 2002/09/11 14:29:13 1.174 +++ linux/xfs_iops.c 2002/09/19 20:21:07 @@ -143,7 +142,7 @@ _ACL_FREE(pdacl); } } - return -error; + return linux_err_code(-error); } STATIC int @@ -152,7 +151,7 @@ struct dentry *dentry, int mode) { - return linvfs_mknod(dir, dentry, mode, 0); + return linux_err_code(linvfs_mknod(dir, dentry, mode, 0)); } STATIC int @@ -161,7 +160,7 @@ struct dentry *dentry, int mode) { - return linvfs_mknod(dir, dentry, mode|S_IFDIR, 0); + return linux_err_code(linvfs_mknod(dir, dentry, mode|S_IFDIR, 0)); } @@ -189,6 +188,7 @@ } error = -linvfs_revalidate_core(ip, ATTR_COMM); } + /* XXX linux_err_code required here? */ if (error && (error != ENOENT)) return ERR_PTR(-error); d_add(dentry, ip); /* Negative entry goes in if ip is NULL */ @@ -222,7 +222,7 @@ d_instantiate(dentry, ip); mark_inode_dirty_sync(ip); } - return -error; + return linux_err_code(-error); } STATIC int @@ -247,7 +247,7 @@ mark_inode_dirty_sync(dir); } - return -error; + return linux_err_code(-error); } STATIC int @@ -288,7 +288,7 @@ mark_inode_dirty_sync(dir); } } - return -error; + return linux_err_code(-error); } STATIC int @@ -307,7 +307,7 @@ mark_inode_dirty_sync(inode); mark_inode_dirty_sync(dir); } - return -error; + return linux_err_code(-error); } STATIC int @@ -329,7 +329,7 @@ VOP_RENAME(fvp, odentry, tvp, ndentry, NULL, error); if (error) - return -error; + return linux_err_code(-error); if (new_inode) { validate_fields(new_inode); @@ -365,7 +365,7 @@ VOP_READLINK(vp, &uio, NULL, error); if (error) - return -error; + return linux_err_code(-error); return (size - uio.uio_resid); } @@ -414,7 +414,7 @@ if (error) { kfree(uio); kfree(link); - return -error; + return linux_err_code(-error); } link[MAXNAMELEN - uio->uio_resid] = '\0'; @@ -423,7 +423,7 @@ /* vfs_follow_link returns (-) errors */ error = vfs_follow_link(nd, link); kfree(link); - return error; + return linux_err_code(error); } STATIC int @@ -436,7 +436,7 @@ mode <<= 6; /* convert from linux to vnode access bits */ VOP_ACCESS(vp, mode, NULL, error); - return -error; + return linux_err_code(-error); } /* Brute force approach for now - copy data into linux inode @@ -461,7 +461,7 @@ vnode_t *vp = LINVFS_GET_VP(dentry->d_inode); if (unlikely(vp->v_flag & VMODIFIED)) { - return linvfs_revalidate_core(dentry->d_inode, 0); + return linux_err_code(linvfs_revalidate_core(dentry->d_inode, 0)); } return 0; } @@ -518,7 +518,7 @@ VOP_SETATTR(vp, &vattr, flags, NULL, error); if (error) - return(-error); /* Positive error up from XFS */ + return linux_err_code(-error); /* Positive error up from XFS */ if (ia_valid & ATTR_SIZE) { error = vmtruncate(inode, attr->ia_size); } @@ -527,7 +527,7 @@ vn_revalidate(vp, 0); mark_inode_dirty_sync(inode); } - return error; + return linux_err_code(error); } STATIC void @@ -610,14 +610,14 @@ xfs_namespaces[SYSTEM_NAMES].namelen) == 0) { error = -EINVAL; if (flags & XATTR_CREATE) - return error; + return linux_err_code(error); error = -ENOATTR; p += xfs_namespaces[SYSTEM_NAMES].namelen; if (strcmp(p, POSIXACL_ACCESS) == 0) { if (vp->v_flag & VMODIFIED) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); } error = xfs_acl_vset(vp, data, size, _ACL_TYPE_ACCESS); if (!error) { @@ -628,7 +628,7 @@ else if (strcmp(p, POSIXACL_DEFAULT) == 0) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); error = xfs_acl_vset(vp, data, size, _ACL_TYPE_DEFAULT); if (!error) { VMODIFY(vp); @@ -638,7 +638,7 @@ else if (strcmp(p, POSIXCAP) == 0) { error = xfs_cap_vset(vp, data, size); } - return error; + return linux_err_code(error); } /* Convert Linux syscall to XFS internal ATTR flags */ @@ -650,11 +650,11 @@ if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, xfs_namespaces[ROOT_NAMES].namelen) == 0) { if (!capable(CAP_SYS_ADMIN)) - return -EPERM; + return linux_err_code(-EPERM); xflags |= ATTR_ROOT; p += xfs_namespaces[ROOT_NAMES].namelen; VOP_ATTR_SET(vp, p, data, size, xflags, NULL, error); - return -error; + return linux_err_code(-error); } if (strncmp(name, xfs_namespaces[USER_NAMES].name, xfs_namespaces[USER_NAMES].namelen) == 0) { @@ -662,7 +662,7 @@ return -EPERM; p += xfs_namespaces[USER_NAMES].namelen; VOP_ATTR_SET(vp, p, data, size, xflags, NULL, error); - return -error; + return linux_err_code(-error); } return -ENOATTR; } @@ -688,7 +688,7 @@ if (vp->v_flag & VMODIFIED) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); } error = xfs_acl_vget(vp, data, size, _ACL_TYPE_ACCESS); } @@ -696,14 +696,14 @@ if (vp->v_flag & VMODIFIED) { error = linvfs_revalidate_core(inode, 0); if (error) - return error; + return linux_err_code(error); } error = xfs_acl_vget(vp, data, size, _ACL_TYPE_DEFAULT); } else if (strcmp(p, POSIXCAP) == 0) { error = xfs_cap_vget(vp, data, size); } - return error; + return linux_err_code(error); } /* Convert Linux syscall to XFS internal ATTR flags */ @@ -719,7 +719,7 @@ VOP_ATTR_GET(vp, p, data, (int *)&size, xflags, NULL, error); if (!error) error = -size; - return -error; + return linux_err_code(-error); } if (strncmp(name, xfs_namespaces[USER_NAMES].name, xfs_namespaces[USER_NAMES].namelen) == 0) { @@ -729,7 +729,7 @@ VOP_ATTR_GET(vp, p, data, (int *)&size, xflags, NULL, error); if (!error) error = -size; - return -error; + return linux_err_code(-error); } return -ENOATTR; } @@ -759,7 +759,7 @@ memset(&cursor, 0, sizeof(cursor)); VOP_ATTR_LIST(vp, data, size, xflags, &cursor, NULL, error); if (error > 0) - return -error; + return linux_err_code(-error); result += -error; k += result; /* advance start of our buffer */ @@ -801,7 +801,7 @@ error = xfs_acl_vremove(vp, _ACL_TYPE_DEFAULT); else if (strcmp(p, POSIXCAP) == 0) error = xfs_cap_vremove(vp); - return error; + return linux_err_code(error); } if (strncmp(name, xfs_namespaces[ROOT_NAMES].name, @@ -811,7 +811,7 @@ xflags |= ATTR_ROOT; p += xfs_namespaces[ROOT_NAMES].namelen; VOP_ATTR_REMOVE(vp, p, xflags, NULL, error); - return -error; + return linux_err_code(-error); } if (strncmp(name, xfs_namespaces[USER_NAMES].name, xfs_namespaces[USER_NAMES].namelen) == 0) { @@ -819,7 +819,7 @@ if (!capable_user_xattr(inode)) return -EPERM; VOP_ATTR_REMOVE(vp, p, xflags, NULL, error); - return -error; + return linux_err_code(-error); } return -ENOATTR; } Index: linux/xfs_linux.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_linux.h,v retrieving revision 1.84 diff -u -w -b -B -r1.84 xfs_linux.h --- linux/xfs_linux.h 2002/09/05 05:37:11 1.84 +++ linux/xfs_linux.h 2002/09/19 20:21:07 @@ -133,17 +133,21 @@ #define EWRONGFS EINVAL /* Mount with wrong filesystem type */ /* - * XXX EFSCORRUPTED needs a real value in errno.h. asm-i386/errno.h won't - * return codes out of its known range in errno. - * XXX Also note: needs to be < 1000 and fairly unique on Linux (mustn't - * conflict with any code we use already or any code a driver may use) - * XXX Some options (currently we do #2): - * 1/ New error code ["Filesystem is corrupted", _after_ glibc updated] - * 2/ 990 ["Unknown error 990"] - * 3/ EUCLEAN ["Structure needs cleaning"] - * 4/ Convert EFSCORRUPTED to EIO [just prior to return into userspace] + * EFSCORRUPTED needs to be distinct from other errors internally to + * the filesystem. + * + * Linux error codes are return as negative values, so externally we + * need to expose -EFSCORRUPTED with EIO. + * + * This however means whatever value we choose must be unique from + * other error codes. The present value of 990 more than suffices at + * present. */ #define EFSCORRUPTED 990 /* Filesystem is corrupted */ +/* xlate to linux error code */ +#define linux_err_code(x) (((x) == (-EFSCORRUPTED))?(-EIO):(x)) + + #define SYNCHRONIZE() barrier() #define lbolt jiffies Index: linux/xfs_super.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/linux/xfs_super.c,v retrieving revision 1.213 diff -u -w -b -B -r1.213 xfs_super.c --- linux/xfs_super.c 2002/09/13 02:01:06 1.213 +++ linux/xfs_super.c 2002/09/19 20:21:07 @@ -621,7 +621,7 @@ VFS_STATVFS(vfsp, statp, NULL, error); - return error; + return linux_err_code(error); } int @@ -669,7 +669,7 @@ out: kfree(args); - return error; + return linux_err_code(error); } void From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:41:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:41:19 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKfFtG007228 for ; Thu, 19 Sep 2002 13:41:15 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 028C01DA566; Thu, 19 Sep 2002 13:46:23 -0700 (PDT) Date: Thu, 19 Sep 2002 13:46:23 -0700 From: Chris Wedgwood To: "Gabe E. Nydick" Cc: linux-xfs Subject: Re: {evil tone} is it safe? Message-ID: <20020919204623.GA470@tapu.f00f.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 498 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Thu, Sep 19, 2002 at 11:49:43AM -0700, Gabe E. Nydick wrote: > I would like to get the performance and scalability back of XFS, so > here is the question. Is it finally ready? What are the > outstanding bugs that need to be fixed. For many people it works very well. A small number of people seem to have has recent problems but most of those seem to be either hardware, proprietary-driver or clue related. I would suggest if you can to try it out once again on a test machine and see how it works for you. If it doesn't, then by all means provide a bug report! --cw From owner-linux-xfs@oss.sgi.com Thu Sep 19 13:57:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 13:57:54 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8JKvmtG008530 for ; Thu, 19 Sep 2002 13:57:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA77230 for ; Thu, 19 Sep 2002 16:02:52 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id QAA87868 for ; Thu, 19 Sep 2002 16:02:51 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K4HmQ18342 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 00:17:48 -0400 Resent-Message-Id: <200209200417.g8K4HmQ18342@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA72562 for ; Thu, 19 Sep 2002 15:54:44 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8K49f916736 for hch@sgi.com; Fri, 20 Sep 2002 00:09:41 -0400 Date: Fri, 20 Sep 2002 00:09:41 -0400 From: Christoph Hellwig Message-Id: <200209200409.g8K49f916736@dhcp212.munich.sgi.com> Subject: TAKE - Remove some dead prototypes in pagebuf Resent-Date: Fri, 20 Sep 2002 00:17:46 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 499 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Sep 19 13:54:05 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.4-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127896a linux/fs/xfs/pagebuf/page_buf.h - 1.40 - Remove some dead prototypes From owner-linux-xfs@oss.sgi.com Thu Sep 19 17:04:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 17:04:09 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K042tG013990 for ; Thu, 19 Sep 2002 17:04:02 -0700 Received: from yew.sucs.soton.ac.uk (yew.sucs.soton.ac.uk [152.78.128.19]) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8K095Vc009680 for ; Fri, 20 Sep 2002 01:09:05 +0100 Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id BAA19753 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 01:09:05 +0100 From: To: Seth Mos Subject: Re: Re-occurance of NFS server panics Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id BAA19747; Fri, 20 Sep 2002 01:06:32 +0100 X-Authentication-Warning: yew.sucs.soton.ac.uk: nobody set sender to idh@soton.ac.uk using -f Message-ID: <1032480392.3d8a668823dd1@webmail.soton.ac.uk> Date: Fri, 20 Sep 2002 01:06:32 +0100 (BST) Cc: I.D.Hardy@soton.ac.uk, O.G.Parchment@soton.ac.uk, linx-xfs@oss.sgi.com References: <4.3.2.7.2.20020918223708.03a58ef0@pop.xs4all.nl> <4.3.2.7.2.20020919082538.02c86680@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20020919082538.02c86680@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.182.156.27 X-MailScanner: Believed to be clean, Believed to be clean X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.6, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME) Resent-Date: Fri, 20 Sep 2002 01:09:05 +0100 (BST) Resent-From: I.D.Hardy@soton.ac.uk Resent-To: linux-xfs@oss.sgi.com Resent-Message-ID: <1032480545.3d8a6721c13c1@webmail.soton.ac.uk> X-Originating-IP: 172.182.156.27 X-MailScanner-Spam: not spam (whitelisted), SpamAssassin (score=-3.6, required 5, IN_REP_TO, X_AUTH_WARNING, NO_REAL_NAME, FORGED_RCVD_FOUND) X-archive-position: 500 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Seth, Steve + Thanks for the suggestions (Steve Lord has also suggested changing these drivers). I've not had sufficient time to look into RedHat Qlogic driver, however, I have now found that the 'qlogicfc' driver that is part of the standard kernel will work with my HBA (I'm sure last time I tried it with an earlier kernel it would not initialize/see my RAID units) - so I'll give this a try. I've also updated to the latest 4.3.15 version of the e1000.o driver from Intel's website. Will see if these help. Regards and Thanks Ian Quoting Seth Mos : > At 22:06 18-9-2002 +0100, I.D.Hardy@soton.ac.uk wrote: > >Seth, > > > >I fairly certain its the Qlogic driver for the QLA2200 HBA (driver > >version 4.27b (I've tried but so far failed to get the more recent > >5.38.9 driver to work). > > That might well be the case. Have you tried backporting or fetching the > > Qlogic driver found in the Red Hat kernels? The drivers in there are > heavily cleaned up and fixed. Fixes that are not yet in the opensource > driver. > > >The only other possibility (well the only other driver not in the > >base/XFS kernel) is an intel driver for a e1000 PRO Gigabit Ethernet > >card (version 3.6.8). > > The e1000 driver does not taint the kernel since it has a GPL license. > Well, at least the 4.3 drivers do. Maybe check in a newer driver. > You can find them on the intel site. I use 4.3.2 > The performance is about 400Mbps on a PIII450 and 32bit pci slot. > > [root@lsautom root]# lsmod > Module Size Used by Not tainted > nfsd 67840 16 (autoclean) > nfs 74684 2 (autoclean) > lockd 47808 1 (autoclean) [nfsd nfs] > sunrpc 62068 1 (autoclean) [nfsd nfs lockd] > tg3 40960 1 > e1000 66828 1 > st 27284 0 > usbcore 57632 1 > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > > From owner-linux-xfs@oss.sgi.com Thu Sep 19 18:32:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 18:32:43 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K1WdtG016299 for ; Thu, 19 Sep 2002 18:32:39 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA04093 for ; Thu, 19 Sep 2002 18:37:47 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA50065 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 11:36:30 +1000 (EST) Date: Fri, 20 Sep 2002 11:36:30 +1000 (EST) From: Nathan Scott Message-Id: <200209200136.LAA50065@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - QA X-archive-position: 501 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Additional refinements for the auto-bench stuff. Date: Thu Sep 19 18:35:55 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127936a cmd/xfstests/tools/auto-qa - 1.37 - Fix up the mailing of results to an owner. cmd/xfstests/bench - 1.4 - Fix up producing the results files. From owner-linux-xfs@oss.sgi.com Thu Sep 19 20:35:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 20:35:39 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K3ZYtG018174 for ; Thu, 19 Sep 2002 20:35:34 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA05044 for ; Thu, 19 Sep 2002 20:40:43 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA65302 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:39:26 +1000 (EST) Date: Fri, 20 Sep 2002 13:39:26 +1000 (EST) From: Nathan Scott Message-Id: <200209200339.NAA65302@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - tidy mount option handling X-archive-position: 502 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Cleanup mount argument manipulation, sanitize xfs_cmountfs and move the check for a mount with IRIX project quota enabled much earlier on in the piece. Date: Thu Sep 19 20:36:14 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127944a linux/fs/xfs/xfs_vfsops.c - 1.382 - Split xfs_cmountfs into manageable chunks - separating out those arguments we can validate before reading the superblock from those which happen only afterward. The IRIX project quota mount check moves in here too (earlier on in the piece now). linux/fs/xfs/xfs_mount.c - 1.301 - Move the check for a mount with IRIX project quota enabled in line with other superblock flags checks (much earlier). From owner-linux-xfs@oss.sgi.com Thu Sep 19 22:07:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 22:07:34 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K57VtG019332 for ; Thu, 19 Sep 2002 22:07:31 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA07754 for ; Thu, 19 Sep 2002 22:12:40 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA79540 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 15:11:23 +1000 (EST) Date: Fri, 20 Sep 2002 15:11:23 +1000 (EST) From: Nathan Scott Message-Id: <200209200511.PAA79540@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dabuf btree split bug X-archive-position: 503 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix xfs_da_node_split handling of dir/attr buffers for filesystems built with a directory block size larger than the filesystem (and hence attr) blocksize. This does not affect filesystems built with default mkfs.xfs parameters, and only hits when a large number of attributes are set on an inode. Date: Thu Sep 19 22:03:21 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127949a linux/fs/xfs/xfsidbg.c - 1.197 linux/fs/xfs/xfs_macros.c - 1.44 linux/fs/xfs/xfs_da_btree.c - 1.132 linux/fs/xfs/xfs_da_btree.h - 1.48 linux/fs/xfs/xfs_dir.c - 1.140 linux/fs/xfs/xfs_mount.h - 1.156 linux/fs/xfs/xfs_dir2_node.c - 1.25 linux/fs/xfs/xfs_attr.c - 1.95 linux/fs/xfs/xfs_dir2.c - 1.37 - Fix a problem in the dabuf (dir/attr buffer) layer which deals with calculating when a block should be split in two. Previously there was only one constant used in the test. When V2 directories have a block size larger than the fs block size, the constant is too large for extended attributes. So, replace this constant with two, and make the dabuf code use the correct one based upon being used for attributes or directories. From owner-linux-xfs@oss.sgi.com Thu Sep 19 23:09:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Sep 2002 23:09:14 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K69AtG020326 for ; Thu, 19 Sep 2002 23:09:10 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA00838 for ; Thu, 19 Sep 2002 23:14:19 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA78800 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 16:13:01 +1000 (EST) Date: Fri, 20 Sep 2002 16:13:01 +1000 (EST) From: Nathan Scott Message-Id: <200209200613.QAA78800@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - user/kernel sync up X-archive-position: 504 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Sync up userspace with some recent kernel changes, no functional change for the user tools. Date: Thu Sep 19 23:12:16 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:127952a cmd/xfsprogs/include/xfs_da_btree.h - 1.11 cmd/xfsprogs/include/libxfs.h - 1.17 cmd/xfsprogs/include/xfs_mount.h - 1.27 cmd/xfsprogs/repair/dir2.c - 1.9 cmd/xfsprogs/repair/dir.c - 1.8 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.16 cmd/xfsprogs/libxfs/xfs_dir.c - 1.8 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.9 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.8 From owner-linux-xfs@oss.sgi.com Fri Sep 20 00:01:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 00:01:59 -0700 (PDT) Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K71utG023433 for ; Fri, 20 Sep 2002 00:01:57 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8K76rqo036734; Fri, 20 Sep 2002 09:07:03 +0200 (CEST) Message-Id: <4.3.2.7.2.20020920085756.033e2070@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Sep 2002 09:05:42 +0200 To: "Gabe E. Nydick" , linux-xfs From: Seth Mos Subject: Re: {evil tone} is it safe? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 505 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:49 19-9-2002 -0700, Gabe E. Nydick wrote: >So, I was a pilot user of XFS 1.0 and it caused all sorts of problems and >corruptions, but I stuck with it until about 2.4.17, which was around when >ext3 was ready, give or take some time. I would like to get the performance >and scalability back of XFS, so here is the question. Is it finally ready? >What are the outstanding bugs that need to be fixed. I have used XFS longer then this without too much hassle. It is good enough for me. I can not speak for others to determine of XFS is ready. You need to test it before putting it into production at your site. I'd say that the official release tend to keep working reasonably well. But even the original XFS 1.0 (2.4.2!) was not good enough for the oss.sgi.com at that time and died rather quickly in just under a day. If you compare this to the 1.1 (2.4.9 or 2.4.18) release a lot has changed in between. And even now the gap between 2.4.19 and the 1.1 release is 5 months! Don't forget that the stability of XFS is also determined by the system it is running on and depends on the rest of the kernel to cooperate. I couldn't get a box stable with a faulty memory dimm and I don't expect that a filesystem would be able to work around that. Thus I experienced all sorts of corruptions and problems, but hardly XFS specific. I just wasn't trying hard enough using another filesystem. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 20 01:21:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 01:21:47 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K8LhtG003521 for ; Fri, 20 Sep 2002 01:21:43 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id BAA04577 for ; Fri, 20 Sep 2002 01:26:52 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA99791 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 18:25:35 +1000 (EST) Date: Fri, 20 Sep 2002 18:25:35 +1000 (EST) From: Nathan Scott Message-Id: <200209200825.SAA99791@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Undo block splitting change X-archive-position: 506 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Ugh - isn't that always the way? - 5pm on Friday and then you run one more test... For some reason I don't get yet, this block splitting change is causing a livelock in dbench with the new benchmarking harness, though all the QA tests are passing with it. So, I've backed it out for now, will have to investigate this some more next week. cheers. Date: Fri Sep 20 01:20:25 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs Undoes mod: 2.4.x-xfs:slinx:127949a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:127958a linux/fs/xfs/xfsidbg.c - 1.198 linux/fs/xfs/xfs_macros.c - 1.45 linux/fs/xfs/xfs_da_btree.c - 1.133 linux/fs/xfs/xfs_da_btree.h - 1.49 linux/fs/xfs/xfs_dir.c - 1.141 linux/fs/xfs/xfs_mount.h - 1.157 linux/fs/xfs/xfs_dir2_node.c - 1.26 linux/fs/xfs/xfs_attr.c - 1.96 linux/fs/xfs/xfs_dir2.c - 1.38 - Undo extended attribute/directory block splitting change. From owner-linux-xfs@oss.sgi.com Fri Sep 20 02:54:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 02:54:34 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8K9sTtG008651 for ; Fri, 20 Sep 2002 02:54:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id EAA81047 for ; Fri, 20 Sep 2002 04:59:35 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA41390 for ; Fri, 20 Sep 2002 04:59:34 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8KHEVq22517 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:14:31 -0400 Resent-Message-Id: <200209201714.g8KHEVq22517@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id EAA07916 for ; Fri, 20 Sep 2002 04:58:04 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8KHD0t22507 for hch@sgi.com; Fri, 20 Sep 2002 13:13:00 -0400 Date: Fri, 20 Sep 2002 13:13:00 -0400 From: Christoph Hellwig Message-Id: <200209201713.g8KHD0t22507@dhcp212.munich.sgi.com> Subject: TAKE - Use min_t in linvfs_get_block_core Resent-Date: Fri, 20 Sep 2002 13:14:31 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 507 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Patch from DaveM Date: Fri Sep 20 02:56:28 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127966a linux/fs/xfs/linux/xfs_aops.c - 1.7 - Use min_t in linvfs_get_block_core to avoid a compiler warning on sparc64 From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:09:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:09:14 -0700 (PDT) Received: from mailscanout256k.tataelxsi.co.in ([203.197.168.150]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KB95tG010344 for ; Fri, 20 Sep 2002 04:09:08 -0700 Message-ID: <3D8B03F4.497B7EE4@tataelxsi.co.in> Date: Fri, 20 Sep 2002 16:48:12 +0530 From: "N.C. Sunil" MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Clarification Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 508 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ncsunil@tataelxsi.co.in Precedence: bulk X-list: linux-xfs Hi ! This is Sunil frm India. We are looking for a solution for the problem of fragmentation caused during I/O transactions on the RAID file system i.e.TP9400. We need to know if : 1. SGI - XFS file system can do an on-fly defragmentation of the data ? 2. Is it unique to only SGI - XFS file system ? 3. If so how will this happen? regards Sunil From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:17:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:17:57 -0700 (PDT) Received: from bingo.yes.lt (mail@bingo.yes.lt [194.176.33.226]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBHptG010835 for ; Fri, 20 Sep 2002 04:17:52 -0700 Received: from tm (helo=localhost) by bingo.yes.lt with local-esmtp (Exim 3.35 #2 (Debian)) id 17sLRh-0008Vm-00; Fri, 20 Sep 2002 12:55:37 +0200 Date: Fri, 20 Sep 2002 12:55:37 +0200 (EET) From: =?windows-1257?Q?Tadas_=DEelionis?= To: Simon Matter , Seth Mos cc: Linux XFS List Subject: Re: md + xfs (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=windows-1257 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by oss.sgi.com id g8KBHrtG010836 X-archive-position: 509 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tm@arti.lt Precedence: bulk X-list: linux-xfs i have just experienced kernel crash/panic when tried to 'sync' disks when md reconstruction was running. (no logs :/) system was debian woody 2.4.20-pre7, md raid1 autodetect, 2 scsi disks on aic7xxx, SMP, filesystem btw was ext3 - not xfs there goes the strange part... when booting next time md started reconstructing arrays as it should, but filesystems seemed clean... then there was a lot of input/output errors etc, i fsck'ed manually, but system turned out unusable, ALL fs's were corrupted. had to reinstall. i don't know why all the fs's were corrupted - now testing that system with 2.4.19. wonder if those 'Warning - running *really* short on DMA buffers' have anything todo with this. > > I must add that the system is Slackware 8.0 based. The MD support is > > compiled in kernel (no modules support). The partitions are of type > RAID > > autodetect so linux can detect them at boot time. Also the / and /home > > partitions are NOT on the md0 divice. Only /var is. > > > > I do not really have any suggestions for you as to why the log appeared > clean, maybe you really were not mounted when the power was pulled. > As for the filesystem, all you can do is run xfs_check when you get a > chance. > > Steve -- Tadas Þelionis +370-687-14478 tm@arti.lt http://www.arti.lt From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:24:58 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBOstG011316 for ; Fri, 20 Sep 2002 04:24:54 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0F-0000PP-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:19 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKue-0000vU-0F for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 12:21:28 +0200 From: Juergen Sauer Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: MosiX Cluster with XFS - Tried anyone ? Date: Sat, 18 May 2002 10:53:25 +0200 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200205181053.25654.jojo@automatix.de> X-KMail-EncryptionState: X-KMail-SignatureState: X-archive-position: 511 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, did anyone successfully tried to build a mosix cluster with XFS ? Reffer to http://www.mosix.org http://www.openmosix.org mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmFoUACgkQW7UKI9EqarHgGQCgoOrvqCVetsUkLsxHlAFNRP1Y klsAn0IgIozy/ae2yuhwEGWkgXjYXszX =kRis -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:24:58 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBOrtG011315 for ; Fri, 20 Sep 2002 04:24:54 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0I-0000RA-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:22 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKug-0000vU-04; Fri, 20 Sep 2002 12:21:30 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: Henri Aanstoot , linux-xfs@oss.sgi.com Subject: Re: RH 7.3 and XFS Date: Mon, 27 May 2002 14:09:52 +0200 User-Agent: KMail/1.4.1 References: <20020527113432.C1230@ao-dai.interaccess.nl> In-Reply-To: <20020527113432.C1230@ao-dai.interaccess.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200205271409.52910.juergen.sauer@automatix.de> X-archive-position: 510 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juergen.sauer@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Montag, 27. Mai 2002 14:34 schrieb Henri Aanstoot: > I'm waiting for you guys to release RH7.3 install iso .. :) > Any release date known yet? > (how long do i have to wait with formatting my laptop drive? ;) This is a job of the RedHat distributor. > Love the work y'all do ... > keep it up .. mfG J. Sauer - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzyIhAACgkQW7UKI9EqarHZ4gCgoqTFRKx5iZ0gbHYvVTKkxcsp 6HYAniOS2RlEjRJPBmLyDPbgNEF5RjYS =SuFR -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:24:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:24:59 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBOstG011317 for ; Fri, 20 Sep 2002 04:24:55 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0F-0000PT-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:19 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKue-0000vU-0G; Fri, 20 Sep 2002 12:21:28 +0200 From: Juergen Sauer Organization: AutomatiX GmbH To: Chris Tooley Subject: Re: MosiX Cluster with XFS - Tried anyone ? Date: Sat, 18 May 2002 16:32:41 +0200 User-Agent: KMail/1.4.5 Cc: linux-xfs@oss.sgi.com References: <200205181053.25654.jojo@automatix.de> <1021724097.2378.1.camel@christooley.cjb.net> In-Reply-To: <1021724097.2378.1.camel@christooley.cjb.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200205181632.46109.jojo@automatix.de> X-KMail-EncryptionState: X-KMail-SignatureState: X-archive-position: 512 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 18. Mai 2002 14:14 schrieb Chris Tooley: > Moshe Bar, who develops openMosix explicitly supports XFS as he thinks > it is a higher performance filesystem than most of the other offerings > for linux. There is a lot of information about it on the openMosix > website. Or at least their used to be. Yes, I did know this before. But it is not usable. 1. Getting CVS Version of openmosix [does not contain XFS] 2. getting the XFS-Patch for 2.4.17 3. Installing the patch works with some linefuzzes, configuring, works, builing the xfs-mosix-kernel definitley not: pc2:/usr/src/linux-openmosix # make gcc -D__KERNEL__ -I/usr/src/linux-openmosix/include -Wall - -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer - -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 - -march=i686 -c -o init/main.o init/main.c In file included from /usr/src/linux-openmosix/include/linux/capability.h:17, from /usr/src/linux-openmosix/include/linux/binfmts.h:5, from /usr/src/linux-openmosix/include/linux/sched.h:9, from /usr/src/linux-openmosix/include/linux/mm.h:4, from /usr/src/linux-openmosix/include/linux/slab.h:14, from /usr/src/linux-openmosix/include/linux/proc_fs.h:5, from init/main.c:15: /usr/src/linux-openmosix/include/linux/fs.h:530: field `xfs_i' has incomplete type make: *** [init/main.o] Fehler 1 pc2:/usr/src/linux-openmosix # That's why I asked, if somewhere a XFS-Mosix ist already installed and working. Any ideas here ? mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzmZgwACgkQW7UKI9EqarFVxwCcCY6P613hm3G9lSPUWFg8/efk r3YAn3feDtyKK0HalKEji3eLrJ3P5CxP =ST5H -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:39:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:39:14 -0700 (PDT) Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBd8tG012676 for ; Fri, 20 Sep 2002 04:39:08 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8KBiGCA085784; Fri, 20 Sep 2002 13:44:18 +0200 (CEST) Message-Id: <4.3.2.7.2.20020920134142.02df57e8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Sep 2002 13:43:03 +0200 To: "N.C. Sunil" , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Clarification In-Reply-To: <3D8B03F4.497B7EE4@tataelxsi.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 513 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 16:48 20-9-2002 +0530, N.C. Sunil wrote: >Hi ! > >This is Sunil frm India. We are looking for a solution for the problem >of fragmentation caused during I/O transactions on the RAID file system >i.e.TP9400. > >We need to know if : >1. SGI - XFS file system can do an on-fly defragmentation of the data ? Yes >2. Is it unique to only SGI - XFS file system ? The defragmentation utility is. Other filesystems can do it as well. But I am not familiar with those. >3. If so how will this happen? Run the xfs_fsr utility to defragment your harddrive. Some people run this overnight in cron every day or week. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 20 04:55:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 04:55:19 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KBtGtG013355 for ; Fri, 20 Sep 2002 04:55:17 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sM0h-0000cs-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 13:31:47 +0200 Received: from [192.168.11.11] (helo=pc1) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sKvD-0000vU-03; Fri, 20 Sep 2002 12:22:03 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Who's using XFS? (again) Date: Wed, 24 Jul 2002 22:58:07 +0200 User-Agent: KMail/1.4.2 References: <1027117051.12810.74.camel@stout.americas.sgi.com> In-Reply-To: <1027117051.12810.74.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200207242258.12989.jojo@automatix.de> X-archive-position: 514 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 20. Juli 2002 00:17 schrieb Eric Sandeen: > Hi all - > I've been asked to take another pulse of the XFS user community; we did > this a while ago, and the results are at > http://oss.sgi.com/projects/xfs/xfs_users.html > If you're using XFS in an interesting/large/impressive/unique > installation, or your company is shipping a product using XFS (and you > can go on the record about it*) I'd like to know, so I can update the > information in the above web page. We use XFS exlusively on about 15 production servers. The biggest is called 'goliath', which is a fileserver >4 TeraByte. We run XFS 1.1 in Kernel 2.4.18-xfs, CVS from 1,5 month ago. XFS seems to us the most reliable an most usable filesystem in the Linux world. My production test on goliath was Power-off without any shutdown, more than 10 times. The system (XFS is root fs) came up in a glance. Later a SapDB Server was added on extra hdd space. XFS succeeded our hard-core crash/power down crash tests also very fine. SapDB (see: http://www.sapdb.org, http://sapdb.automatix.de, GPLed enterprise class RDBMS, compareable to Oracle, successor and anchestor of Adabas D) runns very fin on XFS in Linux. We were heavyly disapointed in reiserfs. Sure the theretical specs are impressive, but there was missing realiabilit. We say only: NFS+disapearing files until next boot. We can not recommend ext2/ext3 due extensive filesystem checks. Ext3 is a journaled fs for starter. We hate IBM jfs due big instability. JFS is not usable for a stable, reliable system. Needs manually repair filesystem after powerloss, jfs looses data during this 'repair filesystem'. My opinion: forget jfs. As JFS was designated by SuSE as IBM partner, it was included jfs in 7.3 distribution, so we took in in a IBM friendly customer's server. We earned Only troubles. The support exchanged it against XFS on month later, now this server runns 137 days up without any further troubles. To Linus: You may forward this eMail to Linus. PErhaps he recognizes the fine work of the XFS staff. To XFS staff: GREAT WORK. KEEP ON. mfG J. Sauer CEO AutomatiX Ltd. Germany - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0/FOMACgkQW7UKI9EqarE0qgCghVZSJS8zGpl8ulQUYhtqSTkl RUQAni7p7EjTB9b1EtejkoBaABOt2sYI =uOE4 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 07:13:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 07:13:05 -0700 (PDT) Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KED0tG022614 for ; Fri, 20 Sep 2002 07:13:01 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.36 #1) id 17sOcz-0002Jy-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 16:19:29 +0200 Received: from [192.168.11.12] (helo=pc2) by s.automatix.de with esmtp (Exim 3.36 #2) id 17sOVm-0003Cd-00 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 16:12:02 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: Double Posts Date: Fri, 20 Sep 2002 16:12:01 +0200 User-Agent: KMail/1.4.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200209201612.01137.jojo@automatix.de> X-archive-position: 515 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jojo@automatix.de Precedence: bulk X-list: linux-xfs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, Please ignore my eMailys from today. Those were created by an old backup-restore on one of our servers. Sorry for any inconvienience. mfG J. Sauer - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj2LLLEACgkQW7UKI9EqarF1cACfUt9BCDEQgChyigfzQM2DeuIz nBEAn0FN0eSnsPMa5ZG3vBcvetwnTWIF =1UA1 -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 20 07:46:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 07:47:04 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KEkvtG023568 for ; Fri, 20 Sep 2002 07:46:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA82507 for ; Fri, 20 Sep 2002 09:52:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id JAA03408 for ; Fri, 20 Sep 2002 09:52:03 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8KEm6e18287; Fri, 20 Sep 2002 09:48:06 -0500 Message-Id: <200209201448.g8KEm6e18287@jen.americas.sgi.com> Date: Fri, 20 Sep 2002 09:48:06 -0500 Subject: TAKE - Merge up to 2.5.36 To: linux-xfs@oss.sgi.com X-archive-position: 516 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs This brings the xfs 2.5 cvs tree in line with Linus's 2.5.36. The only differences between this tree and 2.5.36 should be the parts of xfs which were not submitted to Linus, changes made to xfs since then and kdb. Steve Date: Fri Sep 20 07:35:02 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127971a linux/arch/m68k/vmlinux-std.lds - 1.1 linux/drivers/char/vt_ioctl.c - 1.1 linux/arch/ppc64/vmlinux.lds.S - 1.1 linux/arch/x86_64/vmlinux.lds.S - 1.1 linux/lib/dump_stack.c - 1.1 linux/arch/m68k/vmlinux.lds.S - 1.1 linux/arch/arm/vmlinux.lds.S - 1.1 linux/arch/sparc64/vmlinux.lds.S - 1.1 linux/arch/sparc/vmlinux.lds.S - 1.1 linux/arch/s390x/vmlinux.lds.S - 1.1 linux/arch/cris/vmlinux.lds.S - 1.1 linux/arch/ppc/vmlinux.lds.S - 1.1 linux/arch/s390/vmlinux.lds.S - 1.1 linux/arch/mips/vmlinux.lds.S - 1.1 linux/arch/parisc/vmlinux.lds.S - 1.1 linux/arch/i386/mm/hugetlbpage.c - 1.1 linux/mm/vmscan.c - 1.112 linux/mm/vmalloc.c - 1.44 linux/mm/slab.c - 1.39 linux/mm/page_alloc.c - 1.91 linux/mm/mremap.c - 1.33 linux/mm/mprotect.c - 1.32 linux/mm/mmap.c - 1.59 linux/mm/memory.c - 1.91 linux/mm/filemap.c - 1.134 linux/lib/Makefile - 1.13 linux/kernel/sysctl.c - 1.57 linux/kernel/ksyms.c - 1.164 linux/kernel/exit.c - 1.54 linux/include/linux/sysctl.h - 1.61 linux/include/linux/sched.h - 1.83 linux/include/linux/mm.h - 1.100 linux/include/linux/kernel.h - 1.36 linux/include/linux/blkdev.h - 1.68 linux/include/asm-i386/page.h - 1.30 linux/include/asm-i386/hardirq.h - 1.23 linux/fs/proc/array.c - 1.47 linux/fs/exec.c - 1.65 linux/fs/buffer.c - 1.134 linux/fs/block_dev.c - 1.59 linux/drivers/char/vt.c - 1.27 linux/drivers/char/tty_ioctl.c - 1.8 linux/drivers/char/misc.c - 1.31 linux/drivers/char/console.c - 1.32 linux/drivers/char/Makefile - 1.73 linux/drivers/block/ll_rw_blk.c - 1.113 linux/arch/sparc64/vmlinux.lds - 1.14 linux/arch/sparc64/Makefile - 1.20 linux/arch/sparc/vmlinux.lds - 1.13 linux/arch/sparc/Makefile - 1.14 linux/arch/ppc/vmlinux.lds - 1.17 linux/arch/ppc/Makefile - 1.27 linux/arch/ppc/8xx_io/uart.c - 1.22 linux/arch/mips/Makefile - 1.13 linux/arch/m68k/vmlinux.lds - 1.14 linux/arch/m68k/Makefile - 1.10 linux/arch/i386/mm/init.c - 1.42 linux/arch/i386/mm/Makefile - 1.9 linux/arch/i386/kernel/traps.c - 1.59 linux/arch/i386/kernel/sys_i386.c - 1.9 linux/arch/i386/kernel/entry.S - 1.63 linux/arch/i386/config.in - 1.90 linux/arch/i386/Makefile - 1.31 linux/arch/arm/Makefile - 1.33 linux/arch/alpha/kernel/traps.c - 1.23 linux/arch/alpha/Makefile - 1.20 linux/Makefile - 1.217 linux/include/linux/ide.h - 1.63 linux/kernel/ptrace.c - 1.26 linux/arch/sh/Makefile - 1.13 linux/fs/proc/proc_misc.c - 1.41 linux/include/linux/mmzone.h - 1.26 linux/Documentation/usb/usb-serial.txt - 1.21 linux/Documentation/usb/ov511.txt - 1.19 linux/drivers/ieee1394/raw1394.c - 1.19 linux/drivers/ieee1394/ieee1394_core.h - 1.13 linux/drivers/ieee1394/pcilynx.h - 1.10 linux/drivers/ieee1394/pcilynx.c - 1.22 linux/drivers/ieee1394/ieee1394_core.c - 1.22 linux/drivers/ieee1394/ohci1394.h - 1.16 linux/drivers/ieee1394/ohci1394.c - 1.23 linux/drivers/ieee1394/hosts.h - 1.11 linux/drivers/ieee1394/hosts.c - 1.13 linux/drivers/ieee1394/csr.c - 1.8 linux/drivers/ieee1394/highlevel.c - 1.8 linux/arch/ia64/Makefile - 1.19 linux/arch/ia64/kernel/perfmon.c - 1.16 linux/arch/mips64/Makefile - 1.13 linux/include/linux/usb.h - 1.46 linux/drivers/usb/serial/usb-serial.h - 1.22 linux/drivers/ide/ide_modes.h - 1.9 linux/drivers/ide/ide.c - 1.66 linux/drivers/ide/ide-probe.c - 1.37 linux/drivers/ide/ide-dma.c - 1.30 linux/drivers/ide/Makefile - 1.29 linux/drivers/ide/Config.in - 1.33 linux/drivers/block/elevator.c - 1.22 linux/include/linux/elevator.h - 1.12 linux/drivers/usb/serial/keyspan_pda.c - 1.30 linux/drivers/usb/serial/ftdi_sio.c - 1.40 linux/drivers/usb/serial/usbserial.c - 1.41 linux/drivers/usb/serial/whiteheat.c - 1.29 linux/drivers/usb/serial/visor.c - 1.39 linux/drivers/usb/serial/omninet.c - 1.28 linux/drivers/usb/serial/digi_acceleport.c - 1.31 linux/arch/s390/Makefile - 1.10 linux/kdb/kdb_bt.c - 1.12 linux/kdb/kdbmain.c - 1.34 linux/drivers/usb/storage/usb.h - 1.17 linux/drivers/usb/storage/usb.c - 1.29 linux/drivers/usb/storage/transport.c - 1.27 linux/drivers/usb/storage/scsiglue.c - 1.26 linux/drivers/usb/storage/protocol.c - 1.11 linux/drivers/usb/storage/debug.h - 1.7 linux/drivers/usb/storage/debug.c - 1.10 linux/drivers/usb/serial/keyspan.h - 1.13 linux/drivers/usb/serial/keyspan.c - 1.32 linux/drivers/ieee1394/video1394.c - 1.21 linux/drivers/usb/storage/shuttle_usbat.c - 1.11 linux/drivers/usb/storage/sddr09.c - 1.18 linux/drivers/usb/storage/freecom.c - 1.14 linux/drivers/media/video/cpia_usb.c - 1.12 linux/drivers/usb/serial/belkin_sa.c - 1.24 linux/drivers/usb/serial/mct_u232.c - 1.23 linux/arch/parisc/vmlinux.lds - 1.5 linux/drivers/usb/serial/empeg.c - 1.28 linux/arch/parisc/Makefile - 1.6 linux/arch/cris/Makefile - 1.13 linux/arch/cris/cris.ld - 1.10 linux/arch/cris/kernel/traps.c - 1.10 linux/arch/s390x/Makefile - 1.10 linux/drivers/usb/serial/io_tables.h - 1.7 linux/drivers/usb/serial/io_edgeport.c - 1.28 linux/drivers/bluetooth/hci_usb.c - 1.10 linux/drivers/usb/serial/cyberjack.c - 1.17 linux/drivers/usb/serial/pl2303.c - 1.19 linux/arch/mips/ld.script.in - 1.3 linux/drivers/message/fusion/mptscsih.h - 1.5 linux/drivers/message/fusion/mptscsih.c - 1.9 linux/drivers/message/fusion/mptctl.c - 1.9 linux/drivers/message/fusion/mptbase.h - 1.6 linux/drivers/message/fusion/mptbase.c - 1.6 linux/drivers/message/fusion/lsi/mpi_type.h - 1.3 linux/drivers/message/fusion/lsi/mpi_targ.h - 1.4 linux/drivers/message/fusion/lsi/mpi_lan.h - 1.4 linux/drivers/message/fusion/lsi/mpi_ioc.h - 1.4 linux/drivers/message/fusion/lsi/mpi_init.h - 1.4 linux/drivers/message/fusion/lsi/mpi_fc.h - 1.4 linux/drivers/message/fusion/lsi/mpi_cnfg.h - 1.4 linux/drivers/message/fusion/lsi/mpi.h - 1.4 linux/drivers/message/fusion/Makefile - 1.7 linux/drivers/message/fusion/linux_compat.h - 1.3 linux/drivers/ieee1394/sbp2.c - 1.11 linux/drivers/ieee1394/sbp2.h - 1.9 linux/drivers/ieee1394/nodemgr.c - 1.11 linux/drivers/usb/storage/isd200.c - 1.9 linux/arch/mips/au1000/common/serial.c - 1.4 linux/drivers/isdn/hisax/st5481_init.c - 1.5 linux/lib/rbtree.c - 1.3 linux/include/linux/rbtree.h - 1.2 linux/include/asm-generic/tlb.h - 1.10 linux/drivers/usb/serial/ir-usb.c - 1.19 linux/fs/ext3/ialloc.c - 1.14 linux/fs/ext3/inode.c - 1.20 linux/fs/ext3/ioctl.c - 1.6 linux/fs/ext3/namei.c - 1.11 linux/fs/ext3/super.c - 1.23 linux/include/linux/ext3_fs.h - 1.8 linux/fs/ext3/balloc.c - 1.9 linux/fs/ext3/dir.c - 1.5 linux/fs/bio.c - 1.17 linux/include/linux/device.h - 1.16 linux/mm/mempool.c - 1.9 linux/drivers/usb/serial/ipaq.c - 1.13 linux/drivers/usb/serial/kl5kusb105.c - 1.12 linux/drivers/ieee1394/dv1394-private.h - 1.4 linux/drivers/ieee1394/dv1394.c - 1.6 linux/arch/i386/Config.help - 1.12 linux/drivers/base/core.c - 1.13 linux/arch/ppc/4xx_io/serial_sicc.c - 1.3 linux/arch/x86_64/Makefile - 1.8 linux/arch/x86_64/vmlinux.lds - 1.5 linux/arch/ppc64/Makefile - 1.8 linux/arch/ppc64/vmlinux.lds - 1.5 linux/drivers/ieee1394/eth1394.c - 1.2 linux/drivers/usb/image/microtek.c - 1.4 linux/drivers/usb/class/audio.c - 1.6 linux/drivers/usb/class/bluetty.c - 1.8 linux/drivers/usb/class/cdc-acm.c - 1.7 linux/drivers/usb/core/devices.c - 1.4 linux/drivers/usb/core/devio.c - 1.8 linux/drivers/usb/core/hcd.c - 1.11 linux/drivers/usb/core/hcd.h - 1.8 linux/drivers/usb/core/hub.c - 1.10 linux/drivers/usb/core/hub.h - 1.5 linux/drivers/usb/input/hid-core.c - 1.8 linux/drivers/usb/core/usb.c - 1.15 linux/drivers/usb/media/konicawc.c - 1.6 linux/drivers/usb/media/stv680.c - 1.7 linux/drivers/usb/media/usbvideo.c - 1.8 linux/drivers/usb/image/hpusbscsi.c - 1.6 linux/drivers/usb/image/mdc800.c - 1.7 linux/drivers/ieee1394/cmp.c - 1.2 linux/drivers/usb/image/microtek.h - 1.2 linux/drivers/usb/image/scanner.c - 1.10 linux/drivers/ieee1394/amdtp.h - 1.2 linux/drivers/ieee1394/amdtp.c - 1.3 linux/drivers/usb/input/hiddev.c - 1.9 linux/drivers/usb/input/usbkbd.c - 1.4 linux/drivers/usb/input/usbmouse.c - 1.4 linux/drivers/usb/input/wacom.c - 1.4 linux/drivers/usb/media/dabusb.c - 1.9 linux/drivers/usb/media/dsbr100.c - 1.4 linux/drivers/usb/media/ibmcam.c - 1.5 linux/drivers/usb/media/ov511.c - 1.7 linux/drivers/usb/media/ov511.h - 1.4 linux/drivers/usb/media/pwc-if.c - 1.5 linux/drivers/usb/serial/safe_serial.c - 1.7 linux/drivers/usb/media/se401.c - 1.9 linux/drivers/usb/net/usbnet.c - 1.10 linux/drivers/usb/net/rtl8150.c - 1.7 linux/drivers/usb/media/ultracam.c - 1.5 linux/drivers/usb/media/usbvideo.h - 1.6 linux/drivers/usb/net/pegasus.c - 1.8 linux/drivers/usb/media/vicam.c - 1.4 linux/drivers/usb/net/kaweth.c - 1.9 linux/drivers/usb/net/cdc-ether.c - 1.7 linux/drivers/usb/net/catc.c - 1.4 linux/mm/readahead.c - 1.9 linux/drivers/usb/misc/uss720.c - 1.3 linux/drivers/usb/misc/auerswald.c - 1.8 linux/drivers/usb/misc/emi26.c - 1.5 linux/drivers/usb/misc/rio500.c - 1.5 linux/drivers/usb/misc/tiglusb.c - 1.8 linux/drivers/usb/misc/brlvger.c - 1.7 linux/fs/ntfs/aops.c - 1.10 linux/include/linux/page-flags.h - 1.9 linux/drivers/usb/storage/raw_bulk.c - 1.3 linux/drivers/usb/class/usb-midi.c - 1.5 linux/arch/i386/kernel/cpu/transmeta.c - 1.3 linux/arch/i386/kernel/cpu/intel.c - 1.6 linux/arch/i386/kernel/cpu/amd.c - 1.3 linux/arch/i386/kernel/cpu/common.c - 1.6 linux/drivers/usb/input/aiptek.c - 1.6 linux/drivers/message/fusion/lsi/mpi_raid.h - 1.2 linux/drivers/input/joystick/iforce/iforce-usb.c - 1.4 linux/drivers/usb/input/powermate.c - 1.4 linux/drivers/usb/input/xpad.c - 1.4 linux/drivers/usb/serial/io_ti.c - 1.3 linux/mm/rmap.c - 1.7 linux/net/sched/sch_htb.c - 1.2 linux/drivers/usb/misc/speedtouch.c - 1.2 linux/drivers/usb/class/usblp.c - 1.2 linux/drivers/usb/misc/usblcd.c - 1.2 linux/drivers/ide/pci/pdc202xx.c - 1.2 linux/drivers/ide/setup-pci.c - 1.2 linux/drivers/ide/pci/via82cxxx.h - 1.2 linux/drivers/ide/pci/via82cxxx.c - 1.2 linux/drivers/ide/pci/trm290.h - 1.2 linux/drivers/ide/pci/trm290.c - 1.2 linux/drivers/ide/pci/slc90e66.h - 1.2 linux/drivers/ide/pci/slc90e66.c - 1.2 linux/drivers/ide/pci/sl82c105.h - 1.2 linux/drivers/ide/pci/sl82c105.c - 1.2 linux/drivers/ide/pci/sis5513.h - 1.2 linux/drivers/ide/pci/sis5513.c - 1.2 linux/drivers/ide/pci/siimage.h - 1.2 linux/drivers/ide/pci/siimage.c - 1.2 linux/drivers/ide/pci/serverworks.h - 1.2 linux/drivers/ide/pci/serverworks.c - 1.2 linux/drivers/ide/pci/rz1000.h - 1.2 linux/drivers/ide/pci/rz1000.c - 1.2 linux/drivers/ide/pci/piix.h - 1.2 linux/drivers/ide/pci/piix.c - 1.2 linux/drivers/ide/pci/pdcadma.h - 1.2 linux/drivers/ide/pci/pdcadma.c - 1.2 linux/drivers/ide/pci/pdc202xx_old.h - 1.2 linux/drivers/ide/pci/pdc202xx_old.c - 1.2 linux/drivers/ide/pci/pdc202xx_new.h - 1.2 linux/drivers/ide/pci/pdc202xx_new.c - 1.2 linux/drivers/ide/pci/pdc202xx.h - 1.2 linux/drivers/ide/pci/opti621.h - 1.2 linux/drivers/ide/pci/opti621.c - 1.2 linux/drivers/ide/pci/nvidia.h - 1.2 linux/drivers/ide/pci/nvidia.c - 1.2 linux/drivers/ide/pci/ns87415.h - 1.2 linux/drivers/ide/pci/ns87415.c - 1.2 linux/drivers/ide/pci/it8172.h - 1.2 linux/drivers/ide/pci/it8172.c - 1.2 linux/drivers/ide/pci/hpt366.h - 1.2 linux/drivers/ide/pci/hpt366.c - 1.2 linux/drivers/ide/pci/hpt34x.h - 1.2 linux/drivers/ide/pci/hpt34x.c - 1.2 linux/drivers/ide/pci/generic.h - 1.2 linux/drivers/ide/pci/generic.c - 1.2 linux/drivers/ide/pci/cy82c693.h - 1.2 linux/drivers/ide/pci/cy82c693.c - 1.2 linux/drivers/ide/pci/cs5530.h - 1.2 linux/drivers/ide/pci/cs5530.c - 1.2 linux/drivers/ide/pci/cmd64x.h - 1.2 linux/drivers/ide/pci/cmd64x.c - 1.2 linux/drivers/ide/pci/amd74xx.h - 1.2 linux/drivers/ide/pci/amd74xx.c - 1.2 linux/drivers/ide/pci/alim15x3.h - 1.2 linux/drivers/ide/pci/alim15x3.c - 1.2 linux/drivers/ide/pci/aec62xx.h - 1.2 linux/drivers/ide/pci/aec62xx.c - 1.2 linux/drivers/ide/pci/Makefile - 1.2 linux/drivers/ide/legacy/hd.c - 1.2 linux/drivers/ide/legacy/Makefile - 1.2 linux/drivers/ide/ide-lib.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Sep 20 09:30:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 09:30:36 -0700 (PDT) Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KGUVtG030574 for ; Fri, 20 Sep 2002 09:30:31 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Fri, 20 Sep 2002 09:35:58 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B01015A02@nasexs1.meridian-data.com> From: Marc Kaplan To: "'Gabe E. Nydick'" , linux-xfs Subject: RE: {evil tone} is it safe? Date: Fri, 20 Sep 2002 09:35:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-archive-position: 517 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: marc.kaplan@quantum.com Precedence: bulk X-list: linux-xfs Many companies are using XFS in products currently shipping to customers. Quantum for example, uses XFS on each Guardian network attached storage box we sell. The Guardian is an enterprise class product, and I've not heard of any customer who's ever had any sort of file system corruption problems. For a list of other companies using xfs see http://oss.sgi.com/projects/xfs/xfs_users.html >So, I was a pilot user of XFS 1.0 and it caused all sorts of problems and >corruptions, but I stuck with it until about 2.4.17, which was around when >ext3 was ready, give or take some time. I would like to get the performance >and scalability back of XFS, so here is the question. Is it finally ready? >What are the outstanding bugs that need to be fixed. > >- Gabe From owner-linux-xfs@oss.sgi.com Fri Sep 20 11:35:08 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 11:35:13 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KIZ8tG032567 for ; Fri, 20 Sep 2002 11:35:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA85442 for ; Fri, 20 Sep 2002 13:40:13 -0500 (CDT) Resent-From: hch@dhcp212.munich.sgi.com Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA41008 for ; Fri, 20 Sep 2002 13:40:12 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8L1t8B01983 for linux-xfs@oss.sgi.com; Fri, 20 Sep 2002 21:55:08 -0400 Resent-Message-Id: <200209210155.g8L1t8B01983@dhcp212.munich.sgi.com> Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id NAA12429 for ; Fri, 20 Sep 2002 13:14:32 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8L1TSr01963 for hch@sgi.com; Fri, 20 Sep 2002 21:29:28 -0400 Date: Fri, 20 Sep 2002 21:29:28 -0400 From: Christoph Hellwig Message-Id: <200209210129.g8L1TSr01963@dhcp212.munich.sgi.com> Subject: TAKE - Avoid buffer_heads in linvfs_readpage if possible Resent-Date: Fri, 20 Sep 2002 21:55:08 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 518 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@dhcp212.munich.sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Sep 20 11:13:52 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:127994a linux/fs/xfs/linux/xfs_aops.c - 1.8 - Switch from block_read_full_page to mpage_readpage From owner-linux-xfs@oss.sgi.com Fri Sep 20 12:02:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 12:02:44 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KJ2btG000787 for ; Fri, 20 Sep 2002 12:02:39 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id D5A911DAD48; Fri, 20 Sep 2002 12:07:49 -0700 (PDT) Date: Fri, 20 Sep 2002 12:07:49 -0700 From: Chris Wedgwood To: "N.C. Sunil" Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020920190749.GB10692@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B03F4.497B7EE4@tataelxsi.co.in> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 519 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 20, 2002 at 04:48:12PM +0530, N.C. Sunil wrote: > This is Sunil frm India. We are looking for a solution for the > problem of fragmentation caused during I/O transactions on the RAID > file system i.e.TP9400. Fragmentation is normal and will *always* occur at times. I assume what you really want is sufficiently low levels of fragmentation and high-performance in the face of fragments? XFS seems to do pretty well here, arguably better than anything else in the Linux world. Outside the Linux work it's a different story :) > We need to know if : > 1. SGI - XFS file system can do an on-fly defragmentation of the > data ? Sort of. There is a userspace utility which can in many cases defragment files, but there are some caveats here. > 2. Is it unique to only SGI - XFS file system ? Nothing is unique to XFS :) --cw From owner-linux-xfs@oss.sgi.com Fri Sep 20 12:38:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 12:38:19 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KJcDtG002119 for ; Fri, 20 Sep 2002 12:38:13 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 301841DAD40; Fri, 20 Sep 2002 12:43:26 -0700 (PDT) Date: Fri, 20 Sep 2002 12:43:26 -0700 From: Chris Wedgwood To: Juri Haberland Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020920194326.GB15065@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B75DC.1010305@koschikode.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 520 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 20, 2002 at 09:24:12PM +0200, Juri Haberland wrote: > Out of curiosity, could you elaborate on this a little bit? Sure. xfs_fsr defragments file be looking at which files are fragmented, create a new file preallocating space for a defragmented version of that file an copying the old file to the new file. However, xfs_fsr doesn't always know reliably when it can and cannot further defragment files. I mad fixed to my local version here when I saw it was trying to defragment files that *must* span multiple AGs because of their size (technically it's not the file size, but aggregated size of adjacent extents as holes don't count). Whe the file is copied, it tests to see if the original has changed and then 'swaps' the extents from the old to the new. Because xfs_fsr 'copies' the data, it's actually rather slow and can (usually) does slow access to the fs noticeably. It also means you cannot defragment files which are in use. The other things to consider is that it defagments *files* not filesystems, so potentially as you defragment files, you fragment free space. (I'm not sure in reality of this is a problem though, in practise if your filesystem is large compared to you average file size then probaby not). On last this to consider, a recent minor security fix means xfs_fsr cannot defragment non-root owned files... --cw From owner-linux-xfs@oss.sgi.com Fri Sep 20 12:46:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 12:46:05 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KJjqtG002593 for ; Fri, 20 Sep 2002 12:45:53 -0700 Received: from localhost (unknown [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 2DEE1101024; Fri, 20 Sep 2002 21:24:19 +0200 (CEST) Received: from warp9.sapienti-sat.org (pD9EB13C2.dip.t-dialin.net [217.235.19.194]) by batleth.sapienti-sat.org (Postfix) with ESMTP id DA8A710071E; Fri, 20 Sep 2002 21:24:18 +0200 (CEST) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id 6EA52D16; Fri, 20 Sep 2002 21:24:14 +0200 (CEST) Received: from koschikode.com (kaplah.sapienti-sat.org [192.168.200.15]) by warp9.sapienti-sat.org (Postfix) with ESMTP id ABD1A533; Fri, 20 Sep 2002 21:24:13 +0200 (CEST) Message-ID: <3D8B75DC.1010305@koschikode.com> Date: Fri, 20 Sep 2002 21:24:12 +0200 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 521 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > On Fri, Sep 20, 2002 at 04:48:12PM +0530, N.C. Sunil wrote: >> 1. SGI - XFS file system can do an on-fly defragmentation of the >> data ? > > Sort of. There is a userspace utility which can in many cases > defragment files, but there are some caveats here. Out of curiosity, could you elaborate on this a little bit? Thanks, Juri From owner-linux-xfs@oss.sgi.com Fri Sep 20 13:27:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 13:27:43 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KKRZtG003480 for ; Fri, 20 Sep 2002 13:27:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA86958 for ; Fri, 20 Sep 2002 15:32:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id PAA22154 for ; Fri, 20 Sep 2002 15:32:43 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8KKSgw05367; Fri, 20 Sep 2002 15:28:42 -0500 Message-Id: <200209202028.g8KKSgw05367@jen.americas.sgi.com> Date: Fri, 20 Sep 2002 15:28:42 -0500 Subject: TAKE - merge up to 2.5.37 To: linux-xfs@oss.sgi.com X-archive-position: 522 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs Another merge up with Linus. Steve Part of 2.5.37 merge, Code from Jens Axboe to update pagebuf with new bio infrastructure. axboe@suse.de Date: Fri Sep 20 13:24:47 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128018a linux/fs/xfs/pagebuf/page_buf.c - 1.62 - Start using bio_add_page(), added by Jens Axboe Subject: TAKE - merge up to 2.5.37 Date: Fri Sep 20 13:27:57 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128025a linux/arch/ppc/boot/include/cpc700.h - 1.1 linux/Documentation/driver-model/binding.txt - 1.1 linux/Documentation/driver-model/bus.txt - 1.1 linux/Documentation/driver-model/class.txt - 1.1 linux/Documentation/driver-model/device.txt - 1.1 linux/Documentation/driver-model/driver.txt - 1.1 linux/Documentation/driver-model/interface.txt - 1.1 linux/Documentation/driver-model/overview.txt - 1.1 linux/Documentation/driver-model/platform.txt - 1.1 linux/arch/i386/mach-visws/traps.c - 1.1 linux/arch/i386/mach-visws/smpboot_hooks.h - 1.1 linux/arch/ppc/boot/include/mpc10x.h - 1.1 linux/arch/ppc/boot/include/of1275.h - 1.1 linux/include/asm-i386/numnodes.h - 1.1 linux/arch/ppc/boot/common/mpc10x_memory.c - 1.1 linux/drivers/acpi/blacklist.c - 1.1 linux/arch/sparc64/mm/hugetlbpage.c - 1.1 linux/include/asm-i386/arch_hooks.h - 1.1 linux/include/asm-alpha/numnodes.h - 1.1 linux/arch/ppc/boot/common/cpc700_memory.c - 1.1 linux/arch/i386/mach-visws/irq_vectors.h - 1.1 linux/drivers/acpi/sleep.c - 1.1 linux/drivers/acpi/driverfs.c - 1.1 linux/kernel/pid.c - 1.1 linux/drivers/acpi/debug.c - 1.1 linux/net/bridge/netfilter/ebtables.c - 1.1 linux/net/bridge/netfilter/ebtable_nat.c - 1.1 linux/net/bridge/netfilter/ebtable_filter.c - 1.1 linux/net/bridge/netfilter/ebtable_broute.c - 1.1 linux/arch/ppc/boot/of1275/getprop.c - 1.1 linux/net/bridge/netfilter/ebt_vlan.c - 1.1 linux/arch/i386/kernel/reboot.c - 1.1 linux/arch/ppc64/kernel/asm-offsets.c - 1.1 linux/net/bridge/netfilter/ebt_snat.c - 1.1 linux/net/bridge/netfilter/ebt_redirect.c - 1.1 linux/arch/ppc/boot/of1275/ofinit.c - 1.1 linux/net/bridge/netfilter/ebt_mark_m.c - 1.1 linux/net/bridge/netfilter/ebt_mark.c - 1.1 linux/net/bridge/netfilter/ebt_log.c - 1.1 linux/net/bridge/netfilter/ebt_ip.c - 1.1 linux/arch/i386/mach-generic/Makefile - 1.1 linux/arch/i386/mach-generic/do_timer.h - 1.1 linux/arch/i386/mach-generic/entry_arch.h - 1.1 linux/arch/i386/mach-generic/irq_vectors.h - 1.1 linux/arch/i386/mach-generic/setup.c - 1.1 linux/arch/i386/mach-generic/setup_arch_post.h - 1.1 linux/arch/i386/mach-generic/setup_arch_pre.h - 1.1 linux/arch/i386/mach-generic/smpboot_hooks.h - 1.1 linux/arch/i386/mach-visws/Makefile - 1.1 linux/arch/i386/mach-visws/do_timer.h - 1.1 linux/arch/i386/mach-visws/entry_arch.h - 1.1 linux/arch/i386/mach-visws/setup_arch_post.h - 1.1 linux/arch/i386/mach-visws/mpparse.c - 1.1 linux/arch/i386/mach-visws/pci-visws.c - 1.1 linux/arch/i386/mach-visws/setup.c - 1.1 linux/net/bridge/netfilter/Config.in - 1.1 linux/arch/i386/mach-visws/setup_arch_pre.h - 1.1 linux/drivers/base/platform.c - 1.1 linux/drivers/acpi/event.c - 1.1 linux/arch/i386/mach-visws/visws_apic.c - 1.1 linux/net/bridge/netfilter/ebt_dnat.c - 1.1 linux/net/bridge/netfilter/ebt_arp.c - 1.1 linux/arch/ppc/boot/of1275/Makefile - 1.1 linux/net/ax25/TODO - 1.1 linux/net/bridge/netfilter/Makefile - 1.1 linux/arch/ppc/boot/of1275/claim.c - 1.1 linux/arch/ppc/boot/of1275/enter.c - 1.1 linux/include/linux/pid.h - 1.1 linux/arch/ppc/boot/of1275/exit.c - 1.1 linux/arch/ppc/boot/of1275/finddevice.c - 1.1 linux/mm/madvise.c - 1.1 linux/net/bridge/netfilter/Config.help - 1.1 linux/include/asm-ppc64/ppc_asm.h - 1.1 linux/drivers/acpi/scan.c - 1.1 linux/arch/ppc64/mm/numa.c - 1.1 linux/arch/ppc/boot/openfirmware/start.c - 1.1 linux/arch/ppc/boot/openfirmware/newworldmain.c - 1.1 linux/arch/ppc/boot/openfirmware/misc.S - 1.1 linux/include/asm-ppc64/numnodes.h - 1.1 linux/arch/ppc/boot/openfirmware/common.c - 1.1 linux/arch/ppc/boot/of1275/ofstdio.c - 1.1 linux/arch/ppc/boot/openfirmware/coffmain.c - 1.1 linux/arch/ppc/boot/openfirmware/chrpmain.c - 1.1 linux/arch/ppc/boot/openfirmware/Makefile - 1.1 linux/arch/ppc/boot/of1275/write.c - 1.1 linux/arch/ppc/boot/of1275/release.c - 1.1 linux/arch/ppc/boot/of1275/read.c - 1.1 linux/net/sunrpc/xprt.c - 1.33 linux/net/sunrpc/svcsock.c - 1.22 linux/net/sunrpc/svcauth.c - 1.5 linux/net/sunrpc/svc.c - 1.13 linux/net/sunrpc/clnt.c - 1.22 linux/net/sunrpc/auth_unix.c - 1.8 linux/net/sunrpc/auth_null.c - 1.8 linux/net/sunrpc/auth.c - 1.11 linux/net/rose/sysctl_net_rose.c - 1.4 linux/net/rose/rose_timer.c - 1.7 linux/net/rose/rose_subr.c - 1.7 linux/net/rose/rose_route.c - 1.10 linux/net/rose/rose_out.c - 1.6 linux/net/rose/rose_loopback.c - 1.6 linux/net/rose/rose_link.c - 1.8 linux/net/rose/rose_in.c - 1.6 linux/net/rose/rose_dev.c - 1.10 linux/net/rose/af_rose.c - 1.27 linux/net/netrom/sysctl_net_netrom.c - 1.4 linux/net/netrom/nr_timer.c - 1.7 linux/net/netrom/nr_subr.c - 1.6 linux/net/netrom/nr_route.c - 1.8 linux/net/netrom/nr_out.c - 1.6 linux/net/netrom/nr_loopback.c - 1.8 linux/net/netrom/nr_in.c - 1.5 linux/net/netrom/nr_dev.c - 1.9 linux/net/netrom/af_netrom.c - 1.26 linux/net/irda/irttp.c - 1.19 linux/net/irda/irqueue.c - 1.10 linux/net/irda/irlmp_frame.c - 1.12 linux/net/irda/irlmp_event.c - 1.18 linux/net/irda/irlmp.c - 1.21 linux/net/irda/irlap.c - 1.20 linux/net/irda/irlan/irlan_common.c - 1.19 linux/net/irda/irias_object.c - 1.14 linux/net/irda/iriap.c - 1.17 linux/net/irda/irda_device.c - 1.28 linux/net/irda/discovery.c - 1.8 linux/net/core/dev.c - 1.60 linux/net/bridge/br.c - 1.23 linux/net/bridge/Makefile - 1.6 linux/net/ax25/sysctl_net_ax25.c - 1.5 linux/net/ax25/ax25_uid.c - 1.7 linux/net/ax25/ax25_timer.c - 1.7 linux/net/ax25/ax25_subr.c - 1.8 linux/net/ax25/ax25_std_timer.c - 1.5 linux/net/ax25/ax25_std_subr.c - 1.4 linux/net/ax25/ax25_std_in.c - 1.5 linux/net/ax25/ax25_route.c - 1.8 linux/net/ax25/ax25_out.c - 1.8 linux/net/ax25/ax25_ip.c - 1.9 linux/net/ax25/ax25_in.c - 1.12 linux/net/ax25/ax25_iface.c - 1.5 linux/net/ax25/ax25_ds_timer.c - 1.6 linux/net/ax25/ax25_ds_subr.c - 1.5 linux/net/ax25/ax25_ds_in.c - 1.6 linux/net/ax25/ax25_dev.c - 1.5 linux/net/ax25/ax25_addr.c - 1.4 linux/net/ax25/af_ax25.c - 1.27 linux/net/ax25/Config.in - 1.6 linux/net/Makefile - 1.25 linux/net/Config.in - 1.28 linux/mm/vmscan.c - 1.113 linux/mm/swapfile.c - 1.64 linux/mm/swap_state.c - 1.49 linux/mm/swap.c - 1.26 linux/mm/slab.c - 1.40 linux/mm/page_io.c - 1.30 linux/mm/page_alloc.c - 1.92 linux/mm/mremap.c - 1.34 linux/mm/mprotect.c - 1.33 linux/mm/mmap.c - 1.60 linux/mm/mlock.c - 1.16 linux/mm/memory.c - 1.92 linux/mm/filemap.c - 1.135 linux/mm/Makefile - 1.17 linux/kernel/sysctl.c - 1.58 linux/kernel/sys.c - 1.40 linux/kernel/signal.c - 1.41 linux/kernel/printk.c - 1.24 linux/kernel/ksyms.c - 1.165 linux/kernel/fork.c - 1.70 linux/kernel/exit.c - 1.55 linux/kernel/Makefile - 1.34 linux/ipc/Makefile - 1.4 linux/init/main.c - 1.91 linux/include/net/irda/w83977af_ir.h - 1.6 linux/include/net/irda/irtty.h - 1.9 linux/include/net/irda/irqueue.h - 1.8 linux/include/net/irda/irlmp.h - 1.14 linux/include/net/ax25.h - 1.9 linux/include/linux/wireless.h - 1.10 linux/include/linux/uio.h - 1.4 linux/include/linux/sysctl.h - 1.62 linux/include/linux/sunrpc/xprt.h - 1.15 linux/include/linux/sunrpc/svcauth.h - 1.3 linux/include/linux/sunrpc/svc.h - 1.8 linux/include/linux/sunrpc/msg_prot.h - 1.3 linux/include/linux/sunrpc/clnt.h - 1.11 linux/include/linux/sunrpc/auth.h - 1.7 linux/include/linux/sched.h - 1.84 linux/include/linux/netdevice.h - 1.37 linux/include/linux/nbd.h - 1.16 linux/include/linux/mm.h - 1.101 linux/include/linux/lockd/lockd.h - 1.9 linux/include/linux/list.h - 1.19 linux/include/linux/fs.h - 1.191 linux/include/linux/cyclades.h - 1.8 linux/include/linux/blkdev.h - 1.69 linux/include/asm-sparc64/unistd.h - 1.25 linux/include/asm-sparc64/system.h - 1.23 linux/include/asm-sparc64/page.h - 1.19 linux/include/asm-sparc/unistd.h - 1.23 linux/include/asm-sparc/io.h - 1.11 linux/include/asm-ppc/vga.h - 1.8 linux/include/asm-ppc/user.h - 1.5 linux/include/asm-ppc/unistd.h - 1.26 linux/include/asm-ppc/unaligned.h - 1.5 linux/include/asm-ppc/ucontext.h - 1.5 linux/include/asm-ppc/uaccess.h - 1.12 linux/include/asm-ppc/types.h - 1.12 linux/include/asm-ppc/traps.h - 1.4 linux/include/asm-ppc/timex.h - 1.7 linux/include/asm-ppc/termios.h - 1.9 linux/include/asm-ppc/termbits.h - 1.6 linux/include/asm-ppc/system.h - 1.25 linux/include/asm-ppc/string.h - 1.6 linux/include/asm-ppc/statfs.h - 1.4 linux/include/asm-ppc/stat.h - 1.8 linux/include/asm-ppc/spinlock.h - 1.17 linux/include/asm-ppc/softirq.h - 1.17 linux/include/asm-ppc/sockios.h - 1.4 linux/include/asm-ppc/socket.h - 1.9 linux/include/asm-ppc/smp.h - 1.18 linux/include/asm-ppc/signal.h - 1.6 linux/include/asm-ppc/siginfo.h - 1.11 linux/include/asm-ppc/sigcontext.h - 1.4 linux/include/asm-ppc/shmparam.h - 1.6 linux/include/asm-ppc/setup.h - 1.5 linux/include/asm-ppc/serial.h - 1.13 linux/include/asm-ppc/semaphore.h - 1.10 linux/include/asm-ppc/segment.h - 1.5 linux/include/asm-ppc/scatterlist.h - 1.9 linux/include/asm-ppc/resource.h - 1.10 linux/include/asm-ppc/residual.h - 1.6 linux/include/asm-ppc/raven.h - 1.6 linux/include/asm-ppc/ptrace.h - 1.11 linux/include/asm-ppc/prom.h - 1.15 linux/include/asm-ppc/processor.h - 1.35 linux/include/asm-ppc/prep_nvram.h - 1.6 linux/include/asm-ppc/posix_types.h - 1.9 linux/include/asm-ppc/poll.h - 1.4 linux/include/asm-ppc/pnp.h - 1.5 linux/include/asm-ppc/pgtable.h - 1.39 linux/include/asm-ppc/pci-bridge.h - 1.11 linux/include/asm-ppc/param.h - 1.7 linux/include/asm-ppc/page.h - 1.17 linux/include/asm-ppc/ohare.h - 1.7 linux/include/asm-ppc/nvram.h - 1.7 linux/include/asm-ppc/namei.h - 1.6 linux/include/asm-ppc/mmu_context.h - 1.15 linux/include/asm-ppc/mmu.h - 1.11 linux/include/asm-ppc/mman.h - 1.8 linux/include/asm-ppc/mk48t59.h - 1.4 linux/include/asm-ppc/mediabay.h - 1.8 linux/include/asm-ppc/md.h - 1.5 linux/include/asm-ppc/machdep.h - 1.25 linux/include/asm-ppc/linux_logo.h - 1.9 linux/include/asm-ppc/kgdb.h - 1.6 linux/include/asm-ppc/irq.h - 1.17 linux/include/asm-ppc/ipc.h - 1.4 linux/include/asm-ppc/ioctls.h - 1.5 linux/include/asm-ppc/ioctl.h - 1.4 linux/include/asm-ppc/io.h - 1.19 linux/include/asm-ppc/ide.h - 1.22 linux/include/asm-ppc/hydra.h - 1.5 linux/include/asm-ppc/hardirq.h - 1.21 linux/include/asm-ppc/gg2.h - 1.5 linux/include/asm-ppc/floppy.h - 1.6 linux/include/asm-ppc/fcntl.h - 1.10 linux/include/asm-ppc/errno.h - 1.5 linux/include/asm-ppc/elf.h - 1.13 linux/include/asm-ppc/dma.h - 1.10 linux/include/asm-ppc/delay.h - 1.7 linux/include/asm-ppc/dbdma.h - 1.6 linux/include/asm-ppc/current.h - 1.5 linux/include/asm-ppc/checksum.h - 1.5 linux/include/asm-ppc/cache.h - 1.13 linux/include/asm-ppc/byteorder.h - 1.9 linux/include/asm-ppc/bugs.h - 1.4 linux/include/asm-ppc/bootx.h - 1.6 linux/include/asm-ppc/bootinfo.h - 1.11 linux/include/asm-ppc/bitops.h - 1.17 linux/include/asm-ppc/atomic.h - 1.12 linux/include/asm-ppc/amipcmcia.h - 1.5 linux/include/asm-ppc/amigayle.h - 1.5 linux/include/asm-ppc/amigappc.h - 1.6 linux/include/asm-ppc/amigaints.h - 1.7 linux/include/asm-ppc/amigahw.h - 1.6 linux/include/asm-ppc/a.out.h - 1.4 linux/include/asm-ppc/8xx_immap.h - 1.6 linux/include/asm-i386/page.h - 1.31 linux/include/asm-i386/irq.h - 1.7 linux/fs/smbfs/proc.c - 1.22 linux/fs/smbfs/inode.c - 1.40 linux/fs/smbfs/file.c - 1.33 linux/fs/smbfs/dir.c - 1.24 linux/fs/read_write.c - 1.25 linux/fs/proc/array.c - 1.48 linux/fs/pipe.c - 1.33 linux/fs/nfsd/nfssvc.c - 1.24 linux/fs/nfsd/nfscache.c - 1.11 linux/fs/nfs/nfs3xdr.c - 1.15 linux/fs/nfs/nfs2xdr.c - 1.18 linux/fs/nfs/inode.c - 1.53 linux/fs/namei.c - 1.61 linux/fs/fifo.c - 1.16 linux/fs/fcntl.c - 1.26 linux/fs/ext2/inode.c - 1.54 linux/fs/exec.c - 1.66 linux/fs/dquot.c - 1.60 linux/fs/devices.c - 1.21 linux/fs/buffer.c - 1.135 linux/fs/block_dev.c - 1.60 linux/fs/binfmt_script.c - 1.16 linux/fs/binfmt_misc.c - 1.26 linux/fs/binfmt_em86.c - 1.17 linux/fs/binfmt_elf.c - 1.47 linux/fs/binfmt_aout.c - 1.28 linux/fs/bad_inode.c - 1.14 linux/fs/Makefile - 1.69 linux/drivers/video/clgenfb.c - 1.29 linux/drivers/scsi/sg.c - 1.37 linux/drivers/scsi/sd.c - 1.69 linux/drivers/scsi/scsi_queue.c - 1.14 linux/drivers/scsi/scsi.h - 1.32 linux/drivers/scsi/scsi.c - 1.58 linux/drivers/scsi/Makefile - 1.39 linux/drivers/sbus/char/envctrl.c - 1.17 linux/drivers/sbus/char/Config.in - 1.10 linux/drivers/pci/proc.c - 1.30 linux/drivers/net/yellowfin.c - 1.33 linux/drivers/net/irda/w83977af_ir.c - 1.25 linux/drivers/net/irda/tekram.c - 1.10 linux/drivers/net/irda/irtty.c - 1.29 linux/drivers/net/irda/irport.c - 1.26 linux/drivers/net/irda/girbil.c - 1.12 linux/drivers/net/irda/actisys.c - 1.11 linux/drivers/net/hp100.c - 1.22 linux/drivers/net/epic100.c - 1.32 linux/drivers/net/eepro100.c - 1.49 linux/drivers/net/acenic.h - 1.21 linux/drivers/net/acenic.c - 1.42 linux/drivers/net/Makefile - 1.61 linux/drivers/net/Config.in - 1.65 linux/drivers/net/3c59x.c - 1.37 linux/drivers/net/3c509.c - 1.33 linux/drivers/char/tty_io.c - 1.52 linux/drivers/char/rtc.c - 1.31 linux/drivers/char/random.c - 1.30 linux/drivers/block/rd.c - 1.58 linux/drivers/block/loop.c - 1.65 linux/drivers/block/ll_rw_blk.c - 1.114 linux/drivers/block/floppy.c - 1.49 linux/arch/sparc64/prom/Makefile - 1.11 linux/arch/sparc64/mm/init.c - 1.50 linux/arch/sparc64/mm/fault.c - 1.24 linux/arch/sparc64/mm/Makefile - 1.9 linux/arch/sparc64/kernel/traps.c - 1.23 linux/arch/sparc64/kernel/systbls.S - 1.33 linux/arch/sparc64/kernel/sys_sparc.c - 1.26 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.48 linux/arch/sparc64/kernel/setup.c - 1.35 linux/arch/sparc64/defconfig - 1.76 linux/arch/sparc64/config.in - 1.61 linux/arch/sparc64/Makefile - 1.21 linux/arch/sparc/prom/Makefile - 1.6 linux/arch/sparc/mm/srmmu.c - 1.38 linux/arch/sparc/kernel/sparc_ksyms.c - 1.30 linux/arch/sparc/kernel/setup.c - 1.26 linux/arch/sparc/config.in - 1.44 linux/arch/sparc/Makefile - 1.15 linux/arch/ppc/mm/init.c - 1.45 linux/arch/ppc/mm/fault.c - 1.23 linux/arch/ppc/mm/extable.c - 1.6 linux/arch/ppc/mm/Makefile - 1.11 linux/arch/ppc/lib/string.S - 1.10 linux/arch/ppc/lib/strcase.c - 1.4 linux/arch/ppc/lib/locks.c - 1.13 linux/arch/ppc/lib/checksum.S - 1.8 linux/arch/ppc/lib/Makefile - 1.10 linux/arch/ppc/kernel/traps.c - 1.27 linux/arch/ppc/kernel/time.c - 1.22 linux/arch/ppc/kernel/syscalls.c - 1.15 linux/arch/ppc/kernel/softemu8xx.c - 1.8 linux/arch/ppc/kernel/smp.c - 1.44 linux/arch/ppc/kernel/signal.c - 1.19 linux/arch/ppc/kernel/setup.c - 1.51 linux/arch/ppc/kernel/ptrace.c - 1.15 linux/arch/ppc/kernel/prom.c - 1.31 linux/arch/ppc/kernel/process.c - 1.43 linux/arch/ppc/kernel/prep_nvram.c - 1.11 linux/arch/ppc/kernel/ppc_ksyms.c - 1.50 linux/arch/ppc/kernel/ppc_htab.c - 1.20 linux/arch/ppc/kernel/ppc8xx_pic.h - 1.7 linux/arch/ppc/kernel/ppc8xx_pic.c - 1.10 linux/arch/ppc/kernel/ppc-stub.c - 1.11 linux/arch/ppc/kernel/pci.c - 1.30 linux/arch/ppc/kernel/open_pic.c - 1.29 linux/arch/ppc/kernel/mk_defs.c - 1.19 linux/arch/ppc/kernel/misc.S - 1.47 linux/arch/ppc/kernel/irq.c - 1.40 linux/arch/ppc/kernel/indirect_pci.c - 1.9 linux/arch/ppc/kernel/idle.c - 1.26 linux/arch/ppc/kernel/i8259.c - 1.13 linux/arch/ppc/kernel/head.S - 1.35 linux/arch/ppc/kernel/find_name.c - 1.4 linux/arch/ppc/kernel/bitops.c - 1.6 linux/arch/ppc/kernel/align.c - 1.11 linux/arch/ppc/kernel/Makefile - 1.31 linux/arch/ppc/config.in - 1.59 linux/arch/ppc/boot/Makefile - 1.18 linux/arch/ppc/amiga/time.c - 1.6 linux/arch/ppc/amiga/ints.c - 1.8 linux/arch/ppc/amiga/config.c - 1.20 linux/arch/ppc/amiga/cia.c - 1.8 linux/arch/ppc/amiga/chipram.c - 1.6 linux/arch/ppc/amiga/bootinfo.c - 1.6 linux/arch/ppc/amiga/amisound.c - 1.4 linux/arch/ppc/amiga/amiints.c - 1.13 linux/arch/ppc/amiga/amiga_ksyms.c - 1.4 linux/arch/ppc/amiga/Makefile - 1.9 linux/arch/ppc/Makefile - 1.28 linux/arch/ppc/8xx_io/uart.c - 1.23 linux/arch/ppc/8xx_io/fec.c - 1.18 linux/arch/ppc/8xx_io/enet.c - 1.18 linux/arch/ppc/8xx_io/commproc.c - 1.13 linux/arch/ppc/8xx_io/Makefile - 1.9 linux/arch/mips/Makefile - 1.14 linux/arch/i386/mm/init.c - 1.43 linux/arch/i386/mm/Makefile - 1.10 linux/arch/i386/math-emu/Makefile - 1.8 linux/arch/i386/lib/checksum.S - 1.6 linux/arch/i386/kernel/visws_apic.c - 1.10 linux/arch/i386/kernel/traps.c - 1.60 linux/arch/i386/kernel/time.c - 1.26 linux/arch/i386/kernel/setup.c - 1.83 linux/arch/i386/kernel/process.c - 1.56 linux/arch/i386/kernel/mca.c - 1.14 linux/arch/i386/kernel/io_apic.c - 1.45 linux/arch/i386/kernel/i386_ksyms.c - 1.55 linux/arch/i386/kernel/entry.S - 1.64 linux/arch/i386/kernel/Makefile - 1.35 linux/arch/i386/config.in - 1.91 linux/arch/i386/Makefile - 1.32 linux/Makefile - 1.218 linux/MAINTAINERS - 1.117 linux/Documentation/sysctl/vm.txt - 1.9 linux/include/net/irda/smc-ircc.h - 1.8 linux/include/linux/ide.h - 1.64 linux/include/asm-ppc/hdreg.h - 1.4 linux/drivers/net/irda/toshoboe.c - 1.30 linux/drivers/net/irda/smc-ircc.c - 1.26 linux/arch/ppc/xmon/xmon.c - 1.21 linux/arch/ppc/xmon/subr_prf.c - 1.5 linux/arch/ppc/xmon/start.c - 1.21 linux/arch/ppc/xmon/setjmp.c - 1.3 linux/arch/ppc/xmon/privinst.h - 1.5 linux/arch/ppc/xmon/ppc.h - 1.3 linux/arch/ppc/xmon/ppc-opc.c - 1.4 linux/arch/ppc/xmon/ppc-dis.c - 1.3 linux/arch/ppc/xmon/nonstdio.h - 1.4 linux/arch/ppc/xmon/ansidecl.h - 1.3 linux/arch/ppc/xmon/adb.c - 1.3 linux/arch/ppc/xmon/Makefile - 1.6 linux/arch/mips/dec/prom/Makefile - 1.7 linux/arch/mips/baget/prom/Makefile - 1.5 linux/arch/mips/arc/Makefile - 1.6 linux/drivers/block/cpqarray.c - 1.55 linux/include/linux/threads.h - 1.6 linux/drivers/char/raw.c - 1.29 linux/drivers/net/ppp_generic.c - 1.31 linux/arch/i386/kernel/i8259.c - 1.33 linux/arch/ppc/math-emu/fdivs.c - 1.3 linux/arch/ppc/math-emu/fdiv.c - 1.3 linux/arch/ppc/math-emu/fctiwz.c - 1.3 linux/arch/ppc/math-emu/fctiw.c - 1.3 linux/arch/ppc/math-emu/fcmpu.c - 1.3 linux/arch/ppc/math-emu/fcmpo.c - 1.3 linux/arch/ppc/math-emu/fadds.c - 1.3 linux/arch/ppc/math-emu/fadd.c - 1.3 linux/arch/ppc/math-emu/fabs.c - 1.3 linux/arch/ppc/math-emu/double.h - 1.3 linux/arch/ppc/math-emu/Makefile - 1.4 linux/arch/ppc/kernel/semaphore.c - 1.8 linux/arch/ppc/kernel/head_8xx.S - 1.18 linux/arch/ppc/kernel/entry.S - 1.29 linux/drivers/block/DAC960.c - 1.54 linux/arch/ppc/math-emu/udivmodti4.c - 1.3 linux/arch/ppc/math-emu/types.c - 1.3 linux/arch/ppc/math-emu/stfs.c - 1.3 linux/arch/ppc/math-emu/stfiwx.c - 1.3 linux/arch/ppc/math-emu/stfd.c - 1.3 linux/arch/ppc/math-emu/soft-fp.h - 1.3 linux/arch/ppc/math-emu/single.h - 1.3 linux/arch/ppc/math-emu/sfp-machine.h - 1.4 linux/arch/ppc/math-emu/op-common.h - 1.3 linux/arch/ppc/math-emu/op-4.h - 1.4 linux/arch/ppc/math-emu/op-2.h - 1.3 linux/arch/ppc/math-emu/op-1.h - 1.3 linux/arch/ppc/math-emu/mtfsfi.c - 1.3 linux/arch/ppc/math-emu/mtfsf.c - 1.3 linux/arch/ppc/math-emu/mtfsb1.c - 1.3 linux/arch/ppc/math-emu/mtfsb0.c - 1.3 linux/arch/ppc/math-emu/mffs.c - 1.3 linux/arch/ppc/math-emu/mcrfs.c - 1.3 linux/arch/ppc/math-emu/math.c - 1.4 linux/arch/ppc/math-emu/lfs.c - 1.3 linux/arch/ppc/math-emu/lfd.c - 1.3 linux/arch/ppc/math-emu/fsubs.c - 1.3 linux/arch/ppc/math-emu/fsub.c - 1.3 linux/arch/ppc/math-emu/fsqrts.c - 1.3 linux/arch/ppc/math-emu/fsqrt.c - 1.3 linux/arch/ppc/math-emu/fsel.c - 1.3 linux/arch/ppc/math-emu/frsqrte.c - 1.3 linux/arch/ppc/math-emu/frsp.c - 1.3 linux/arch/ppc/math-emu/fres.c - 1.3 linux/arch/ppc/math-emu/fnmsubs.c - 1.3 linux/arch/ppc/math-emu/fnmsub.c - 1.3 linux/arch/ppc/math-emu/fnmadds.c - 1.3 linux/arch/ppc/math-emu/fnmadd.c - 1.3 linux/arch/ppc/math-emu/fneg.c - 1.3 linux/arch/ppc/math-emu/fnabs.c - 1.3 linux/arch/ppc/math-emu/fmuls.c - 1.3 linux/arch/ppc/math-emu/fmul.c - 1.3 linux/arch/ppc/math-emu/fmsubs.c - 1.3 linux/arch/ppc/math-emu/fmsub.c - 1.3 linux/arch/ppc/math-emu/fmr.c - 1.3 linux/arch/ppc/math-emu/fmadds.c - 1.3 linux/arch/ppc/math-emu/fmadd.c - 1.3 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.10 linux/net/irda/ircomm/ircomm_tty.c - 1.21 linux/net/irda/ircomm/ircomm_param.c - 1.9 linux/net/irda/ircomm/ircomm_lmp.c - 1.7 linux/net/irda/ircomm/ircomm_core.c - 1.16 linux/include/net/irda/ircomm_tty.h - 1.10 linux/include/asm-ppc/m48t35.h - 1.4 linux/include/asm-ppc/pci.h - 1.17 linux/drivers/net/pcmcia/pcnet_cs.c - 1.20 linux/include/linux/acpi.h - 1.29 linux/Documentation/filesystems/proc.txt - 1.10 linux/arch/ppc/kernel/qspan_pci.c - 1.7 linux/arch/ppc/kernel/m8xx_setup.c - 1.25 linux/arch/ppc/amiga/pcmcia.c - 1.3 linux/arch/i386/kernel/smpboot.c - 1.47 linux/include/asm-ppc/bseip.h - 1.4 linux/include/asm-ppc/mpc8xx.h - 1.9 linux/mm/highmem.c - 1.43 linux/fs/proc/proc_misc.c - 1.42 linux/include/asm-ppc/div64.h - 1.3 linux/include/asm-ppc/pgalloc.h - 1.13 linux/arch/ppc/mm/mem_pieces.h - 1.4 linux/arch/ppc/mm/mem_pieces.c - 1.7 linux/mm/numa.c - 1.13 linux/include/linux/mmzone.h - 1.27 linux/drivers/scsi/scsi_lib.c - 1.49 linux/drivers/i2c/i2c-philips-par.c - 1.8 linux/arch/i386/kernel/acpi.c - 1.30 linux/include/asm-ppc/hw_irq.h - 1.10 linux/arch/i386/kernel/apic.c - 1.34 linux/arch/i386/kernel/mpparse.c - 1.25 linux/drivers/ieee1394/Makefile - 1.16 linux/include/asm-ppc/shmbuf.h - 1.4 linux/include/asm-ppc/sembuf.h - 1.4 linux/include/asm-ppc/msgbuf.h - 1.4 linux/include/asm-ppc/ipcbuf.h - 1.4 linux/include/asm-i386/mpspec.h - 1.10 linux/drivers/net/irda/nsc-ircc.c - 1.23 linux/arch/ppc/kernel/pci-dma.c - 1.5 linux/include/asm-ppc/heathrow.h - 1.8 linux/drivers/net/8139too.c - 1.43 linux/net/bridge/br_forward.c - 1.6 linux/include/linux/if_bridge.h - 1.2 linux/net/bridge/br_private.h - 1.8 linux/net/bridge/br_input.c - 1.11 linux/drivers/net/tulip/tulip_core.c - 1.42 linux/drivers/net/tulip/tulip.h - 1.16 linux/drivers/net/tulip/interrupt.c - 1.16 linux/drivers/net/tulip/eeprom.c - 1.13 linux/include/asm-mips64/pgtable.h - 1.16 linux/include/asm-mips64/mmzone.h - 1.9 linux/arch/mips64/sgi-ip22/Makefile - 1.6 linux/arch/mips64/sgi-ip27/ip27-memory.c - 1.11 linux/arch/mips64/Makefile - 1.14 linux/arch/mips64/arc/Makefile - 1.6 linux/drivers/ide/ide.c - 1.67 linux/drivers/ide/ide-proc.c - 1.23 linux/drivers/ide/ide-probe.c - 1.38 linux/drivers/ide/ide-dma.c - 1.31 linux/drivers/ide/Makefile - 1.30 linux/drivers/usb/serial/visor.c - 1.40 linux/include/asm-ppc/mpc8260.h - 1.5 linux/include/asm-ppc/immap_8260.h - 1.6 linux/include/asm-ppc/cpm_8260.h - 1.7 linux/arch/ppc/xmon/start_8xx.c - 1.4 linux/arch/ppc/kernel/ppc8260_pic.h - 1.4 linux/arch/ppc/kernel/ppc8260_pic.c - 1.6 linux/arch/ppc/kernel/m8260_setup.c - 1.16 linux/arch/ppc/8260_io/uart.c - 1.13 linux/arch/ppc/8260_io/enet.c - 1.9 linux/arch/ppc/8260_io/commproc.c - 1.5 linux/arch/ppc/8260_io/Makefile - 1.5 linux/drivers/s390/net/iucv.c - 1.10 linux/arch/i386/kdb/Makefile - 1.11 linux/include/asm-ppc/backlight.h - 1.5 linux/include/asm-ppc/mc146818rtc.h - 1.4 linux/include/asm-ppc/time.h - 1.11 linux/drivers/acpi/tables/tbget.c - 1.13 linux/drivers/acpi/tables.c - 1.7 linux/drivers/acpi/resources/rsdump.c - 1.11 linux/drivers/acpi/parser/psxface.c - 1.12 linux/drivers/acpi/namespace/nsload.c - 1.13 linux/drivers/acpi/include/actypes.h - 1.14 linux/drivers/acpi/include/acpiosxf.h - 1.12 linux/drivers/acpi/include/acexcep.h - 1.10 linux/drivers/acpi/ec.c - 1.11 linux/drivers/acpi/dispatcher/dswload.c - 1.15 linux/drivers/acpi/dispatcher/dsobject.c - 1.16 linux/drivers/acpi/dispatcher/dsfield.c - 1.10 linux/drivers/acpi/Makefile - 1.19 linux/drivers/net/tun.c - 1.17 linux/kernel/user.c - 1.6 linux/drivers/net/natsemi.c - 1.23 linux/drivers/md/raid1.c - 1.25 linux/drivers/md/raid5.c - 1.34 linux/arch/ppc/8260_io/fcc_enet.c - 1.6 linux/drivers/acpi/include/acconfig.h - 1.17 linux/drivers/acpi/include/acdebug.h - 1.13 linux/drivers/acpi/include/acinterp.h - 1.12 linux/drivers/acpi/namespace/nsdump.c - 1.11 linux/drivers/block/cciss.c - 1.42 linux/drivers/md/linear.c - 1.13 linux/drivers/md/md.c - 1.55 linux/drivers/md/raid0.c - 1.12 linux/drivers/net/sundance.c - 1.18 linux/include/asm-ppc/highmem.h - 1.11 linux/include/asm-ppc/keylargo.h - 1.6 linux/include/asm-ppc/kmap_types.h - 1.12 linux/include/asm-ppc/uninorth.h - 1.6 linux/drivers/net/tulip/ChangeLog - 1.15 linux/net/irda/irsyms.c - 1.7 linux/include/asm-ppc/module.h - 1.4 linux/include/asm-ppc/xor.h - 1.3 linux/drivers/net/lasi_82596.c - 1.11 linux/mm/shmem.c - 1.46 linux/drivers/acpi/power.c - 1.7 linux/include/asm-ppc/parport.h - 1.3 linux/drivers/acpi/acpi_ksyms.c - 1.11 linux/arch/ppc/kernel/open_pic_defs.h - 1.6 linux/drivers/net/pci-skeleton.c - 1.13 linux/include/linux/hdlc.h - 1.4 linux/drivers/net/wan/n2.c - 1.5 linux/drivers/net/wan/hd6457x.c - 1.5 linux/drivers/net/wan/c101.c - 1.5 linux/drivers/sbus/char/bbc_envctrl.c - 1.2 linux/include/asm-alpha/mmzone.h - 1.4 linux/include/asm-ppc/rwsem.h - 1.4 linux/fs/freevxfs/vxfs_super.c - 1.11 linux/drivers/net/fealnx.c - 1.14 linux/drivers/net/irda/irda-usb.c - 1.22 linux/arch/ppc/boot/utils/mkprep.c - 1.2 linux/arch/ppc/boot/utils/mknote.c - 1.2 linux/arch/alpha/mm/numa.c - 1.6 linux/arch/ppc/boot/utils/hack-coff.c - 1.2 linux/arch/ppc/boot/utils/addnote.c - 1.2 linux/arch/ppc/boot/prep/vreset.c - 1.4 linux/arch/ppc/boot/prep/of1275.h - 1.2 linux/arch/ppc/boot/prep/of1275.c - 1.2 linux/arch/ppc/boot/prep/misc.c - 1.9 linux/arch/ppc/boot/prep/kbd.c - 1.3 linux/arch/ppc/boot/prep/iso_font.h - 1.2 linux/arch/ppc/boot/prep/head.S - 1.4 linux/arch/ppc/boot/prep/Makefile - 1.10 linux/arch/ppc/boot/pmac/start.c - 1.4 linux/arch/ppc/boot/pmac/misc.S - 1.2 linux/arch/ppc/boot/pmac/coffmain.c - 1.6 linux/arch/ppc/boot/pmac/chrpmain.c - 1.6 linux/arch/ppc/boot/pmac/Makefile - 1.7 linux/arch/ppc/boot/lib/zlib.c - 1.3 linux/arch/ppc/boot/lib/Makefile - 1.2 linux/arch/ppc/boot/include/zlib.h - 1.2 linux/arch/ppc/boot/include/rs6000.h - 1.2 linux/arch/ppc/boot/include/nonstdio.h - 1.3 linux/arch/ppc/boot/common/string.S - 1.2 linux/arch/ppc/boot/common/ns16550.c - 1.4 linux/arch/ppc/boot/common/misc-simple.c - 1.5 linux/arch/ppc/boot/common/crt0.S - 1.5 linux/arch/ppc/boot/chrp/start.c - 1.4 linux/arch/ppc/boot/chrp/misc.S - 1.2 linux/arch/ppc/boot/chrp/main.c - 1.6 linux/arch/ppc/boot/chrp/Makefile - 1.7 linux/include/linux/netfilter_bridge.h - 1.2 linux/drivers/bluetooth/hci_usb.c - 1.11 linux/drivers/acpi/executer/exstore.c - 1.10 linux/drivers/acpi/utilities/utmisc.c - 1.8 linux/drivers/acpi/utilities/utinit.c - 1.7 linux/drivers/acpi/utilities/utglobal.c - 1.12 linux/drivers/acpi/utilities/utdebug.c - 1.8 linux/drivers/acpi/utilities/utcopy.c - 1.9 linux/drivers/acpi/Config.in - 1.9 linux/drivers/acpi/include/acutils.h - 1.9 linux/drivers/net/wireless/airo.c - 1.19 linux/drivers/acpi/executer/exstoren.c - 1.7 linux/drivers/acpi/executer/exconvrt.c - 1.8 linux/drivers/acpi/executer/exmisc.c - 1.9 linux/drivers/acpi/executer/exresnte.c - 1.10 linux/drivers/acpi/executer/exresolv.c - 1.9 linux/drivers/acpi/executer/exresop.c - 1.10 linux/arch/ppc/mm/hashtable.S - 1.7 linux/drivers/net/irda/ali-ircc.c - 1.10 linux/drivers/net/dl2k.c - 1.16 linux/drivers/message/fusion/Makefile - 1.8 linux/arch/ppc/mm/4xx_mmu.c - 1.5 linux/arch/ppc/mm/cachemap.c - 1.6 linux/arch/ppc/mm/mmu_context.c - 1.4 linux/arch/ppc/mm/mmu_decl.h - 1.7 linux/arch/ppc/mm/pgtable.c - 1.9 linux/arch/ppc/mm/ppc_mmu.c - 1.5 linux/arch/ppc/mm/tlb.c - 1.7 linux/include/asm-ppc/btext.h - 1.3 linux/include/asm-ppc/cputable.h - 1.3 linux/arch/ppc/boot/common/ofcommon.c - 1.3 linux/arch/ppc/kernel/cputable.c - 1.7 linux/arch/ppc/kernel/btext.c - 1.5 linux/drivers/bluetooth/hci_vhci.c - 1.6 linux/include/asm-ppc/sections.h - 1.2 linux/drivers/isdn/hisax/st5481_init.c - 1.6 linux/drivers/md/multipath.c - 1.14 linux/fs/namespace.c - 1.23 linux/include/asm-ppc/commproc.h - 1.3 linux/drivers/pcmcia/sa1100_generic.c - 1.8 linux/drivers/pcmcia/sa1100.h - 1.4 linux/drivers/net/8139cp.c - 1.19 linux/drivers/char/eurotechwdt.c - 1.5 linux/drivers/acpi/executer/exoparg1.c - 1.9 linux/fs/ext3/inode.c - 1.21 linux/drivers/hotplug/pci_hotplug_core.c - 1.13 linux/drivers/hotplug/pci_hotplug.h - 1.3 linux/drivers/hotplug/cpqphp_ctrl.c - 1.4 linux/drivers/hotplug/cpqphp_core.c - 1.7 linux/drivers/hotplug/cpqphp.h - 1.3 linux/drivers/net/pcmcia/axnet_cs.c - 1.2 linux/include/linux/bio.h - 1.14 linux/fs/driverfs/inode.c - 1.22 linux/fs/bio.c - 1.18 linux/include/linux/device.h - 1.17 linux/mm/mempool.c - 1.10 linux/Documentation/driver-model.txt - 1.4 linux/include/linux/gfp.h - 1.4 linux/arch/i386/kernel/setup-visws.c - 1.3 linux/drivers/ide/ide-taskfile.c - 1.21 linux/drivers/ieee1394/dv1394.c - 1.7 linux/net/core/wireless.c - 1.4 linux/drivers/net/wireless/netwave_cs.c - 1.4 linux/drivers/net/wireless/wavelan.c - 1.4 linux/drivers/net/wireless/wavelan.p.h - 1.3 linux/drivers/net/wireless/wavelan_cs.c - 1.6 linux/drivers/net/wireless/wavelan_cs.p.h - 1.3 linux/include/net/iw_handler.h - 1.4 linux/arch/sparc64/Config.help - 1.5 linux/drivers/acpi/Config.help - 1.5 linux/drivers/net/Config.help - 1.7 linux/drivers/base/core.c - 1.14 linux/drivers/base/Makefile - 1.7 linux/arch/ppc/boot/common/dummy.c - 1.2 linux/arch/ppc/boot/common/util.S - 1.2 linux/arch/ppc/boot/ld.script - 1.3 linux/arch/ppc/boot/simple/Makefile - 1.5 linux/arch/ppc/boot/simple/embed_config.c - 1.4 linux/arch/ppc/boot/simple/gt64260_tty.c - 1.2 linux/arch/ppc/boot/simple/head.S - 1.2 linux/arch/ppc/boot/simple/iic.c - 1.2 linux/arch/ppc/boot/simple/m8260_tty.c - 1.2 linux/arch/ppc/boot/simple/m8xx_tty.c - 1.2 linux/arch/ppc/boot/simple/misc-embedded.c - 1.4 linux/arch/ppc/boot/simple/pci.c - 1.2 linux/arch/ppc/boot/simple/qspan_pci.c - 1.2 linux/arch/ppc/boot/utils/mktree.c - 1.2 linux/arch/ppc/kernel/iSeries_asm.h - 1.2 linux/arch/ppc/mm/iSeries_mmu.c - 1.3 linux/arch/ppc/platforms/Makefile - 1.4 linux/arch/ppc/platforms/apus_pci.c - 1.3 linux/arch/ppc/platforms/apus_pci.h - 1.2 linux/arch/ppc/platforms/apus_setup.c - 1.6 linux/arch/ppc/platforms/bseip.h - 1.2 linux/arch/ppc/platforms/chrp_pci.c - 1.3 linux/arch/ppc/platforms/chrp_setup.c - 1.10 linux/arch/ppc/platforms/chrp_smp.c - 1.5 linux/arch/ppc/platforms/chrp_time.c - 1.2 linux/arch/ppc/platforms/ep405.c - 1.4 linux/arch/ppc/platforms/error_log.c - 1.2 linux/arch/ppc/platforms/error_log.h - 1.2 linux/arch/ppc/platforms/est8260.h - 1.2 linux/arch/ppc/platforms/fads.h - 1.2 linux/arch/ppc/platforms/gemini.h - 1.2 linux/arch/ppc/platforms/gemini_pci.c - 1.3 linux/arch/ppc/platforms/gemini_prom.S - 1.2 linux/arch/ppc/platforms/gemini_serial.h - 1.2 linux/arch/ppc/platforms/gemini_setup.c - 1.5 linux/arch/ppc/platforms/iSeries_pic.c - 1.4 linux/arch/ppc/platforms/iSeries_smp.c - 1.4 linux/arch/ppc/platforms/iSeries_time.c - 1.3 linux/arch/ppc/platforms/ivms8.h - 1.2 linux/arch/ppc/platforms/mbx.h - 1.3 linux/arch/ppc/platforms/oak.h - 1.2 linux/arch/ppc/platforms/oak_setup.c - 1.3 linux/arch/ppc/platforms/oak_setup.h - 1.2 linux/arch/ppc/platforms/pmac_backlight.c - 1.2 linux/arch/ppc/platforms/pmac_feature.c - 1.4 linux/arch/ppc/platforms/pmac_nvram.c - 1.4 linux/arch/ppc/platforms/pmac_pci.c - 1.4 linux/arch/ppc/platforms/pmac_pic.c - 1.6 linux/arch/ppc/platforms/pmac_pic.h - 1.2 linux/arch/ppc/platforms/pmac_setup.c - 1.7 linux/arch/ppc/platforms/pmac_smp.c - 1.6 linux/arch/ppc/platforms/pmac_time.c - 1.3 linux/arch/ppc/platforms/prep_pci.c - 1.5 linux/arch/ppc/platforms/prep_setup.c - 1.10 linux/arch/ppc/platforms/prep_time.c - 1.2 linux/arch/ppc/platforms/proc_rtas.c - 1.3 linux/arch/ppc/platforms/residual.c - 1.3 linux/arch/ppc/platforms/rpxclassic.h - 1.4 linux/arch/ppc/platforms/rpxhiox.h - 1.2 linux/arch/ppc/platforms/rpxlite.h - 1.4 linux/arch/ppc/platforms/sleep.S - 1.2 linux/arch/ppc/platforms/spd8xx.h - 1.3 linux/arch/ppc/platforms/tqm8xx.h - 1.3 linux/sound/oss/cs4281/cs4281m.c - 1.4 linux/sound/Makefile - 1.9 linux/include/asm-ppc/ppc_asm.h - 1.4 linux/include/asm-ppc/ppc4xx_pic.h - 1.2 linux/include/asm-ppc/pc_serial.h - 1.2 linux/include/asm-ppc/open_pic.h - 1.4 linux/include/asm-ppc/i8259.h - 1.4 linux/include/asm-ppc64/hardirq.h - 1.6 linux/arch/ppc64/mm/init.c - 1.9 linux/include/asm-ppc64/irq.h - 1.2 linux/arch/ppc64/Makefile - 1.9 linux/arch/ppc64/kernel/LparData.c - 1.5 linux/arch/ppc64/kernel/Makefile - 1.8 linux/arch/ppc64/kernel/chrp_setup.c - 1.7 linux/arch/ppc64/kernel/entry.S - 1.8 linux/arch/ppc64/kernel/head.S - 1.7 linux/arch/ppc64/kernel/htab.c - 1.6 linux/arch/ppc64/kernel/hvCall.S - 1.2 linux/arch/ppc64/kernel/i8259.h - 1.2 linux/arch/ppc64/kernel/iSeries_VpdInfo.c - 1.3 linux/arch/ppc64/kernel/iSeries_pci.c - 1.6 linux/arch/ppc64/kernel/iSeries_setup.c - 1.7 linux/arch/ppc64/kernel/irq.c - 1.7 linux/arch/ppc64/kernel/lmb.c - 1.4 linux/arch/ppc64/kernel/local_irq.h - 1.2 linux/arch/ppc64/kernel/misc.S - 1.8 linux/arch/ppc64/kernel/mk_defs.c - 1.8 linux/arch/ppc64/kernel/open_pic.c - 1.5 linux/arch/ppc64/kernel/pSeries_hvCall.S - 1.2 linux/arch/ppc64/kernel/pSeries_pci.c - 1.7 linux/arch/ppc64/kernel/pci.c - 1.6 linux/arch/ppc64/kernel/pci_dma.c - 1.5 linux/arch/ppc64/kernel/pci_dn.c - 1.5 linux/arch/ppc64/kernel/ppc_asm.h - 1.4 linux/arch/ppc64/kernel/ppc_defs.head - 1.2 linux/arch/ppc64/kernel/proc_pmc.c - 1.4 linux/arch/ppc64/kernel/process.c - 1.8 linux/arch/ppc64/kernel/rtas.c - 1.5 linux/arch/ppc64/kernel/signal.c - 1.9 linux/arch/ppc64/kernel/signal32.c - 1.8 linux/arch/ppc64/kernel/stab.c - 1.6 linux/arch/ppc64/kernel/sys32.S - 1.4 linux/arch/ppc64/kernel/sys_ppc32.c - 1.8 linux/arch/ppc64/kernel/syscalls.c - 1.5 linux/arch/ppc64/kernel/time.c - 1.8 linux/arch/ppc64/kernel/traps.c - 1.7 linux/arch/ppc64/kernel/xics.c - 1.6 linux/arch/ppc64/kernel/xics.h - 1.2 linux/arch/ppc64/lib/checksum.S - 1.4 linux/arch/ppc64/lib/string.S - 1.6 linux/arch/ppc64/mm/Makefile - 1.2 linux/arch/ppc64/xmon/xmon.c - 1.7 linux/include/asm-ppc64/machdep.h - 1.7 linux/include/asm-ppc64/hw_irq.h - 1.4 linux/include/asm-ppc64/mman.h - 1.3 linux/include/asm-ppc64/unistd.h - 1.7 linux/include/asm-ppc64/tlb.h - 1.4 linux/include/asm-ppc64/semaphore.h - 1.3 linux/include/asm-ppc64/iSeries/LparData.h - 1.4 linux/include/asm-ppc64/pgtable.h - 1.7 linux/include/asm-ppc64/pci-bridge.h - 1.2 linux/include/asm-ppc64/page.h - 1.8 linux/drivers/hotplug/ibmphp_core.c - 1.7 linux/fs/jfs/inode.c - 1.14 linux/fs/jfs/jfs_logmgr.c - 1.17 linux/fs/quota_v2.c - 1.6 linux/fs/quota_v1.c - 1.5 linux/drivers/net/tg3.h - 1.10 linux/drivers/net/tg3.c - 1.11 linux/drivers/net/tulip/winbond-840.c - 1.4 linux/drivers/net/wan/hdlc_x25.c - 1.2 linux/drivers/net/tulip/xircom_tulip_cb.c - 1.3 linux/drivers/net/wan/hdlc_cisco.c - 1.2 linux/drivers/net/wan/hdlc_fr.c - 1.2 linux/drivers/net/wan/hdlc_generic.c - 1.2 linux/drivers/net/wan/hdlc_ppp.c - 1.2 linux/drivers/net/wan/hdlc_raw.c - 1.2 linux/drivers/net/e100/e100_main.c - 1.8 linux/drivers/acpi/acpi_bus.h - 1.5 linux/drivers/acpi/acpi_drivers.h - 1.6 linux/drivers/net/wan/comx-hw-munich.c - 1.5 linux/fs/libfs.c - 1.6 linux/include/asm-ppc/tlbflush.h - 1.5 linux/include/asm-ppc/cacheflush.h - 1.3 linux/include/asm-i386/irq_vectors.h - 1.2 linux/drivers/base/power.c - 1.4 linux/include/linux/percpu.h - 1.3 linux/scripts/mkcompile_h - 1.6 linux/drivers/block/umem.c - 1.8 linux/arch/i386/pci/Makefile - 1.2 linux/drivers/net/irda/mcp2120.c - 1.3 linux/arch/i386/pci/acpi.c - 1.4 linux/drivers/pci/pool.c - 1.4 linux/drivers/pci/probe.c - 1.7 linux/fs/fs-writeback.c - 1.7 linux/include/linux/page-flags.h - 1.10 linux/arch/i386/pci/visws.c - 1.3 linux/drivers/bluetooth/hci_h4.c - 1.2 linux/mm/page-writeback.c - 1.11 linux/include/linux/buffer_head.h - 1.10 linux/init/Makefile - 1.7 linux/include/linux/writeback.h - 1.8 linux/include/asm-ppc64/ppc_asm.tmpl - 1.2 linux/kernel/suspend.c - 1.12 linux/include/linux/mpage.h - 1.3 linux/fs/mpage.c - 1.8 linux/drivers/acpi/pci_bind.c - 1.2 linux/arch/ppc64/lib/copyuser.S - 1.2 linux/drivers/acpi/ac.c - 1.4 linux/drivers/acpi/battery.c - 1.5 linux/drivers/acpi/bus.c - 1.8 linux/drivers/acpi/pci_root.c - 1.6 linux/drivers/acpi/fan.c - 1.3 linux/drivers/acpi/pci_link.c - 1.5 linux/drivers/acpi/button.c - 1.4 linux/drivers/acpi/pci_irq.c - 1.6 linux/arch/ppc64/lib/memcpy.S - 1.2 linux/drivers/acpi/thermal.c - 1.5 linux/drivers/acpi/system.c - 1.9 linux/arch/ppc64/lib/copypage.S - 1.2 linux/drivers/acpi/processor.c - 1.6 linux/arch/i386/kernel/suspend.c - 1.6 linux/arch/i386/kernel/cpu/intel.c - 1.7 linux/arch/i386/kernel/cpu/amd.c - 1.4 linux/drivers/net/irda/act200l.c - 1.2 linux/include/net/llc_main.h - 1.4 linux/net/llc/llc_sock.c - 1.4 linux/net/llc/llc_actn.c - 1.4 linux/net/llc/llc_c_ac.c - 1.5 linux/net/llc/llc_c_ev.c - 1.5 linux/net/llc/llc_main.c - 1.5 linux/include/net/llc_actn.h - 1.3 linux/include/net/llc_c_ac.h - 1.3 linux/include/net/llc_c_ev.h - 1.4 linux/include/net/irda/af_irda.h - 1.2 linux/fs/direct-io.c - 1.6 linux/drivers/acpi/namespace/nsdumpdv.c - 1.3 linux/include/asm-ppc64/mmzone.h - 1.5 linux/arch/i386/mm/pgtable.c - 1.3 linux/arch/ppc64/kernel/rtas_flash.c - 1.2 linux/drivers/serial/sunsu.c - 1.3 linux/fs/aio.c - 1.4 linux/arch/i386/kernel/cpu/mtrr/mtrr.h - 1.3 linux/drivers/acpi/numa.c - 1.2 linux/include/asm-i386/max_numnodes.h - 1.2 linux/arch/i386/mm/discontig.c - 1.3 linux/arch/i386/kernel/numaq.c - 1.3 linux/include/asm-i386/mmzone.h - 1.3 linux/include/asm-i386/numaq.h - 1.3 linux/drivers/ide/ppc/Makefile - 1.2 linux/drivers/ide/pci/Makefile - 1.3 linux/drivers/ide/legacy/hd.c - 1.3 linux/drivers/ide/legacy/Makefile - 1.3 linux/drivers/ide/ide-lib.c - 1.3 linux/drivers/ide/arm/Makefile - 1.2 linux/arch/m68k/vmlinux.lds.S - 1.2 linux/arch/s390x/vmlinux.lds.S - 1.2 linux/arch/s390/vmlinux.lds.S - 1.2 linux/arch/i386/mm/hugetlbpage.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Sep 20 13:33:37 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 13:33:42 -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 g8KKXbtG003967 for ; Fri, 20 Sep 2002 13:33:37 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 946D11DAD7C; Fri, 20 Sep 2002 13:38:50 -0700 (PDT) Date: Fri, 20 Sep 2002 13:38:50 -0700 From: Chris Wedgwood To: Juri Haberland Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020920203850.GA15627@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> <3D8B86BD.6050101@koschikode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D8B86BD.6050101@koschikode.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 523 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 20, 2002 at 10:36:13PM +0200, Juri Haberland wrote: > Uhm, do I understand you right that xfs_fsr cannot defragment - say > /home/* ? Yes, with the current xfs_fsr and kernel from CVS, it won't work. "xfs_fsr -v -d" will sho allocation failures for non-root owned files. > That would make it a bit useless, wouldn't it? Arguably. But it is fixable if you *really* needed to defragment /home/ --cw From owner-linux-xfs@oss.sgi.com Fri Sep 20 13:50:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 13:50:26 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KKoLtG004529 for ; Fri, 20 Sep 2002 13:50:22 -0700 Received: from localhost (unknown [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 1EA58101027; Fri, 20 Sep 2002 22:55:34 +0200 (CEST) Received: from warp9.sapienti-sat.org (pD9EB13C2.dip.t-dialin.net [217.235.19.194]) by batleth.sapienti-sat.org (Postfix) with ESMTP id D3FBF101026; Fri, 20 Sep 2002 22:55:33 +0200 (CEST) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id 6F2D3D16; Fri, 20 Sep 2002 22:55:30 +0200 (CEST) Received: from koschikode.com (kaplah.sapienti-sat.org [192.168.200.15]) by warp9.sapienti-sat.org (Postfix) with ESMTP id A6246A7; Fri, 20 Sep 2002 22:55:29 +0200 (CEST) Message-ID: <3D8B8B3F.706@koschikode.com> Date: Fri, 20 Sep 2002 22:55:27 +0200 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> <3D8B86BD.6050101@koschikode.com> <20020920203850.GA15627@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 524 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > On Fri, Sep 20, 2002 at 10:36:13PM +0200, Juri Haberland wrote: > >> Uhm, do I understand you right that xfs_fsr cannot defragment - say >> /home/* ? > > Yes, with the current xfs_fsr and kernel from CVS, it won't work. > "xfs_fsr -v -d" will sho allocation failures for non-root owned files. > >> That would make it a bit useless, wouldn't it? > > Arguably. But it is fixable if you *really* needed to defragment > /home/ Allright. Thanks for that, Chris. And yes, in case of /home it would be easy to work around this limitation. But nonetheless, good that this tool exists and good, that one can learn every day something new ;) Cheers, Juri (of for vacation, phew) From owner-linux-xfs@oss.sgi.com Fri Sep 20 14:09:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 14:09:25 -0700 (PDT) Received: from batleth.sapienti-sat.org (batleth.sapienti-sat.org [217.111.19.42] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KL9BtG005196 for ; Fri, 20 Sep 2002 14:09:12 -0700 Received: from localhost (unknown [127.0.0.1]) by batleth.sapienti-sat.org (Postfix) with SMTP id 13172101024; Fri, 20 Sep 2002 22:36:19 +0200 (CEST) Received: from warp9.sapienti-sat.org (pD9EB13C2.dip.t-dialin.net [217.235.19.194]) by batleth.sapienti-sat.org (Postfix) with ESMTP id CCE7310071E; Fri, 20 Sep 2002 22:36:18 +0200 (CEST) Received: from localhost (localhost.sapienti-sat.org [127.0.0.1]) by warp9.sapienti-sat.org (Postfix) with SMTP id 42422D16; Fri, 20 Sep 2002 22:36:15 +0200 (CEST) Received: from koschikode.com (kaplah.sapienti-sat.org [192.168.200.15]) by warp9.sapienti-sat.org (Postfix) with ESMTP id 10163533; Fri, 20 Sep 2002 22:36:15 +0200 (CEST) Message-ID: <3D8B86BD.6050101@koschikode.com> Date: Fri, 20 Sep 2002 22:36:13 +0200 From: Juri Haberland Organization: totally unorganized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: de-DE, en MIME-Version: 1.0 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 525 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: juri@koschikode.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > On Fri, Sep 20, 2002 at 09:24:12PM +0200, Juri Haberland wrote: > >> Out of curiosity, could you elaborate on this a little bit? > > Sure. Thanks ;) > On last this to consider, a recent minor security fix means xfs_fsr > cannot defragment non-root owned files... Uhm, do I understand you right that xfs_fsr cannot defragment - say - /home/* ? That would make it a bit useless, wouldn't it? Juri From owner-linux-xfs@oss.sgi.com Fri Sep 20 14:41:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 14:41:58 -0700 (PDT) Received: from web40603.mail.yahoo.com (web40603.mail.yahoo.com [66.218.78.140]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KLfrtG005951 for ; Fri, 20 Sep 2002 14:41:53 -0700 Message-ID: <20020920214701.58788.qmail@web40603.mail.yahoo.com> Received: from [208.35.40.2] by web40603.mail.yahoo.com via HTTP; Fri, 20 Sep 2002 14:47:01 PDT Date: Fri, 20 Sep 2002 14:47:01 -0700 (PDT) From: Ravi Wijayaratne Subject: O(1) scheduler To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 526 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Hi All, Are there any pitfalls in incorporating Ingo Molnars O(1) scheduler to xfs-linux-2.4.18-r1.1 ? The patches in the current xfs CVS does not seem to be applicable. Any insights or experiences ? Thanx Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com From owner-linux-xfs@oss.sgi.com Fri Sep 20 15:04:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 15:04:02 -0700 (PDT) Received: from wks1.linux-works.org ([164.64.40.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8KM3xtG006672 for ; Fri, 20 Sep 2002 15:03:59 -0700 Received: from linux-works.org (andy.nmcourts.com [198.59.128.89]) by wks1.linux-works.org (8.11.6/8.11.6) with ESMTP id g8KM95r15445 for ; Fri, 20 Sep 2002 16:09:05 -0600 Message-ID: <3D8B9C5D.9040901@linux-works.org> Date: Fri, 20 Sep 2002 16:08:29 -0600 From: Andrew Mathews User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfsdump errors Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 527 X-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_mathews@linux-works.org Precedence: bulk X-list: linux-xfs I'm getting the following errors when running xfsdump on a Dell Latitude laptop running RH 7.3, 2.4.18-4SGI_XFS_1.1, and the following xfs rpms from oss.sgi.com: xfsprogs-2.2.2-0 xfsdump-2.1.5-0 xfsprogs-devel-2.2.2-0 attr-devel-2.0.9-0 libattr-2.0.9-0 attr-2.0.9-0 dmapi-2.0.5-0 dmapi-devel-2.0.5-0 acl-devel-2.0.18-0 libacl-2.0.18-0 acl-2.0.18-0 This is using an HP DAT24e tape drive. xfsdump: inv_core.c:79: get_counters: Assertion `((invt_counter_t *)(*cntpp))->ic_vernum == (inv_version_t) 1' failed. I've searched the archives but not found anything relevant. TIA- -- Andrew Mathews --------------------------------------------------------------------- 3:59pm up 136 days, 6 users, load average: 1.08, 1.06, 1.17 --------------------------------------------------------------------- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Poul Anderson From owner-linux-xfs@oss.sgi.com Fri Sep 20 15:45:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 15:45:07 -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 g8KMj4tG007341 for ; Fri, 20 Sep 2002 15:45:04 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 4724C7CCC; Fri, 20 Sep 2002 15:50:18 -0700 (PDT) Date: Fri, 20 Sep 2002 15:50:18 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: What is the proper way to unlink/free quota inodes? Message-ID: <20020920225018.GA16700@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 528 X-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 What is the proper way to unlink quota inodes (and hence free the space they use) when you no longer want to mess with quotas? I tried deleting all quotas for all users to see if it would do this automatically but it does not. Rather, I used xfs_db to null the values in "sb 0" and then had repair fix the dangling link... ... surely there is a better way? Thanks, --cw From owner-linux-xfs@oss.sgi.com Fri Sep 20 16:32:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 16:32:37 -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 g8KNWXtG008350 for ; Fri, 20 Sep 2002 16:32:34 -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 QAA00825 for ; Fri, 20 Sep 2002 16:32:32 -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 JAA07604; Sat, 21 Sep 2002 09:31:16 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA72010; Sat, 21 Sep 2002 09:31:15 +1000 (EST) Date: Sat, 21 Sep 2002 09:31:14 +1000 From: Nathan Scott To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: What is the proper way to unlink/free quota inodes? Message-ID: <20020921093114.D167828@wobbly.melbourne.sgi.com> References: <20020920225018.GA16700@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020920225018.GA16700@tapu.f00f.org>; from cw@f00f.org on Fri, Sep 20, 2002 at 03:50:18PM -0700 X-archive-position: 529 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Fri, Sep 20, 2002 at 03:50:18PM -0700, Chris Wedgwood wrote: > What is the proper way to unlink quota inodes (and hence free the > space they use) when you no longer want to mess with quotas? > > I tried deleting all quotas for all users to see if it would do this > automatically but it does not. Rather, I used xfs_db to null the > values in "sb 0" and then had repair fix the dangling link... > > ... surely there is a better way? > quotaoff(1) does this, in particular "-x delete". This issues the Q_XQUOTARM quotactl(2) command which XFS acts on to free the inode. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Sep 20 17:28:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 17:28:05 -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 g8L0S1tG010049 for ; Fri, 20 Sep 2002 17:28:02 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g8L0RtA07325; Sat, 21 Sep 2002 02:27:55 +0200 (MEST) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 17sY7m-0004i5-00; Sat, 21 Sep 2002 02:27:54 +0200 Date: Sat, 21 Sep 2002 02:27:54 +0200 From: christian.guggenberger@physik.uni-regensburg.de To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020921002754.GA17878@pc9391.physik.uni-regensburg.de> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> <3D8B86BD.6050101@koschikode.com> <20020920203850.GA15627@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020920203850.GA15627@tapu.f00f.org> User-Agent: Mutt/1.3.28i X-archive-position: 530 X-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 On Fri, Sep 20, 2002 at 01:38:50PM -0700, Chris Wedgwood wrote: > On Fri, Sep 20, 2002 at 10:36:13PM +0200, Juri Haberland wrote: > > > Uhm, do I understand you right that xfs_fsr cannot defragment - say > > /home/* ? > > Yes, with the current xfs_fsr and kernel from CVS, it won't work. > "xfs_fsr -v -d" will sho allocation failures for non-root owned files. > chris, sorry, but I'll need some clarification 'bout that. I just ran xfs_fsr on my server's data partitions, where all data is owned by non root, i.e. nis+ Users, and I didn't see any allocation errors. Would you please give any thougts about what I'm missing? What I've just seen, xfs_fsr will run under the same userID as the file's owner... Christian From owner-linux-xfs@oss.sgi.com Fri Sep 20 17:54:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Sep 2002 17:54: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 g8L0satG010683 for ; Fri, 20 Sep 2002 17:54:36 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 148811D307F; Fri, 20 Sep 2002 17:54:36 -0700 (PDT) Date: Fri, 20 Sep 2002 17:54:36 -0700 From: Chris Wedgwood To: christian.guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020921005436.GA18548@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> <3D8B86BD.6050101@koschikode.com> <20020920203850.GA15627@tapu.f00f.org> <20020921002754.GA17878@pc9391.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020921002754.GA17878@pc9391.physik.uni-regensburg.de> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 531 X-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 21, 2002 at 02:27:54AM +0200, christian.guggenberger@physik.uni-regensburg.de wrote: > sorry, but I'll need some clarification 'bout that. I just ran > xfs_fsr on my server's data partitions, where all data is owned by > non root, i.e. nis+ Users, and I didn't see any allocation > errors. Would you please give any thougts about what I'm missing? How old is your kernel? > What I've just seen, xfs_fsr will run under the same userID as the > file's owner... Yes, and in recent kernels a minor security fix means only root and preallocate space. --cw From owner-linux-xfs@oss.sgi.com Sat Sep 21 01:38:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 01:38:37 -0700 (PDT) Received: from server2.teleport.ch (server2.teleport.ch [157.161.16.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8L8cStG015430 for ; Sat, 21 Sep 2002 01:38:32 -0700 Received: from xxl.bi.corp.invoca.ch (cable-rhf3-015.teleport.ch [157.161.34.15]) by server2.teleport.ch (8.12.3/8.12.3) with ESMTP id g8L8cMBM071715; Sat, 21 Sep 2002 10:38:23 +0200 (CEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: from there (lappi.bi.corp.invoca.ch [192.168.10.22]) by xxl.bi.corp.invoca.ch (Postfix) with SMTP id C5F286A712; Sat, 21 Sep 2002 10:38:21 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Simon Matter Organization: Sauter AG, Basel To: Tadas =?iso-8859-1?q?=3Felionis?= , Simon Matter , Seth Mos Subject: Re: md + xfs (fwd) Date: Sat, 21 Sep 2002 10:38:18 +0200 X-Mailer: KMail [version 1.3.2] Cc: Linux XFS List References: In-Reply-To: MIME-Version: 1.0 Message-Id: <20020921083821.C5F286A712@xxl.bi.corp.invoca.ch> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8L8cWtG015431 X-archive-position: 532 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: simon.matter@ch.sauter-bc.com Precedence: bulk X-list: linux-xfs On Friday 20 September 2002 12:55, Tadas ?elionis wrote: > i have just experienced kernel crash/panic when tried to 'sync' disks when > md reconstruction was running. (no logs :/) > > system was debian woody 2.4.20-pre7, md raid1 autodetect, 2 scsi disks on > aic7xxx, SMP, filesystem btw was ext3 - not xfs > > there goes the strange part... when booting next time md started > reconstructing arrays as it should, but filesystems seemed clean... > > then there was a lot of input/output errors etc, i fsck'ed manually, but > system turned out unusable, ALL fs's were corrupted. had to reinstall. > > i don't know why all the fs's were corrupted - now testing that system > with 2.4.19. > > > wonder if those 'Warning - running *really* short on DMA buffers' have > anything todo with this. Hi, I don't know what happened with your system. The only time when I had data/fs corruption with md was on old 2.4.x kernels. The kernel delivered with RedHat 7.1, including the XFS enabled one from the RH 7.1 SGI XFS installer, were giving me horrible corruptions on several different IDE hardware. That said, I'm not too much surprised one can face this although I have no idea what went wrong in your case. Having data transfer errors on IDE DMA trasnsfers can likely result in a heavy damaged md and therefore the filesystem has no chance to survive. All this toghether with enabled write caching on the disk can really mess things up. Sorry, that's not much help but it can give you an idea what others faced before :) Simon > > > > I must add that the system is Slackware 8.0 based. The MD support is > > > compiled in kernel (no modules support). The partitions are of type > > > > RAID > > > > > autodetect so linux can detect them at boot time. Also the / and /home > > > partitions are NOT on the md0 divice. Only /var is. > > > > I do not really have any suggestions for you as to why the log appeared > > clean, maybe you really were not mounted when the power was pulled. > > As for the filesystem, all you can do is run xfs_check when you get a > > chance. > > > > Steve From owner-linux-xfs@oss.sgi.com Sat Sep 21 03:35:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 03:35:23 -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 g8LAZHtG016485 for ; Sat, 21 Sep 2002 03:35:18 -0700 Received: from pc9391.physik.uni-regensburg.de (pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.11.6+Sun/8.11.6) with ESMTP id g8LAZEA01048; Sat, 21 Sep 2002 12:35:14 +0200 (MEST) Received: from guc28561 by pc9391.physik.uni-regensburg.de with local (Exim 3.35 #1 (Debian)) id 17shbW-0002EH-00; Sat, 21 Sep 2002 12:35:14 +0200 Date: Sat, 21 Sep 2002 12:35:14 +0200 From: christian.guggenberger@physik.uni-regensburg.de To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020921103514.GA8447@pc9391.physik.uni-regensburg.de> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> <3D8B86BD.6050101@koschikode.com> <20020920203850.GA15627@tapu.f00f.org> <20020921002754.GA17878@pc9391.physik.uni-regensburg.de> <20020921005436.GA18548@tapu.f00f.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020921005436.GA18548@tapu.f00f.org> User-Agent: Mutt/1.3.28i X-archive-position: 533 X-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 On Fri, Sep 20, 2002 at 05:54:36PM -0700, Chris Wedgwood wrote: > On Sat, Sep 21, 2002 at 02:27:54AM +0200, christian.guggenberger@physik.uni-regensburg.de wrote: > > > sorry, but I'll need some clarification 'bout that. I just ran > > xfs_fsr on my server's data partitions, where all data is owned by > > non root, i.e. nis+ Users, and I didn't see any allocation > > errors. Would you please give any thougts about what I'm missing? > > How old is your kernel? > CVS of August, 27th. christian > > What I've just seen, xfs_fsr will run under the same userID as the > > file's owner... > > Yes, and in recent kernels a minor security fix means only root and > preallocate space. > > > > > --cw From owner-linux-xfs@oss.sgi.com Sat Sep 21 06:04:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 06:04:52 -0700 (PDT) Received: from 21cn.com ([61.140.60.248]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8LD4jtG020272 for ; Sat, 21 Sep 2002 06:04:47 -0700 Received: from 21cn.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jm83d8c965f; Sat, 21 Sep 2002 21:03:44 +0800 Received: from 21cn.com([10.2.1.1]) by 21cn.com(AIMC 2.9.5.1) with SMTP id jm63d8ca85e; Sat, 21 Sep 2002 21:03:44 +0800 Received: from oss.sgi.com([127.0.0.1]) by 21cn.com(AIMC 2.9.5.2) with SMTP id jmf3d87ef64; Wed, 18 Sep 2002 03:03:02 +0800 Received: from oss.sgi.com([128.167.58.27]) by 21cn.com(AIMC 2.9.5.1) with SMTP id jmb43d87a5ae; Wed, 18 Sep 2002 03:03:02 +0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.5/8.12.5) with ESMTP id g8HIwltG017454; Tue, 17 Sep 2002 11:58:48 -0700 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Sep 2002 11:58:36 -0700 (PDT) Received: from notes.guilford.edu ([192.154.63.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8HIwUtG017375 for ; Tue, 17 Sep 2002 11:58:31 -0700 Subject: Can Windows read XFS? To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: vricks@guilford.edu Date: Tue, 17 Sep 2002 15:03:13 -0400 X-MIMETrack: Serialize by Router on notes.guilford.edu/Guilford(Release 5.0.10 |March 22, 2002) at 09/17/2002 03:03:31 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 444 X-ecartis-version: Ecartis v1.0.0 X-original-sender: vricks@guilford.edu Precedence: bulk X-list: linux-xfs X-archive-position: 534 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vricks@guilford.edu Precedence: bulk X-list: linux-xfs I've unsuccessfully checked the archives for the answer to the above question. Are there any programs that allow Windows NT/2k/XP systems to read XFS filesystem data? I have a dual-boot XP/Linux system with the /home partition formatted XFS. Thanks Vance Ricks Assistant Professor of Philosophy Guilford College Greensboro, NC 27410 John M Trostel ntum.com> cc: linux-xfs@oss.sgi.com Sent by: Subject: Re: 2.4.17 + XFS? linux-xfs-bounce@ oss.sgi.com 09/17/02 02:22 PM Hi Jose The currently supported kernel in the CVS tree is 2.4.19 (not 2.4.9). The currently supported kernel for RPM installs with version 1.1 of XFS is kernel 2.4.18. Only if one wants a RH 7.1 or 7.2 rpm install, is the kernel version 2.4.9-x used. I would upgrade my kernel from 2.4.17 to 2.4.19 and take advantage of that advance also, if possible. You could also be somewhat more conservative and upgrade to the version 1.1 of XFS on the 2.4.18 kernel level. (Actually, I have kept my laptop up with the CVS tree... but I enjoy living dangerously.) On Tue, 2002-09-17 at 13:50, jose Hernandez wrote: > Hello. > > I would like to install the XFS support for my kernel (2.4.17).but I > have seen that the supported kernel is 2.4.9. > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > 2.4.9? > > Thanks a lot for your help. > > > > > -- John M. Trostel Senior Software Engineer Quantum Corp. john.trostel@quantum.com From owner-linux-xfs@oss.sgi.com Sat Sep 21 06:35:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 06:35:43 -0700 (PDT) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8LDZbtG020906 for ; Sat, 21 Sep 2002 06:35:38 -0700 Received: from fwd00.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17skQ4-0001jr-0C; Sat, 21 Sep 2002 15:35:36 +0200 Received: from CBINDER (310078580701-0001@[217.0.89.141]) by fwd00.sul.t-online.com with esmtp id 17skQ0-0V0fxYC; Sat, 21 Sep 2002 15:35:32 +0200 From: christian_binder@t-online.de To: linux-xfs@oss.sgi.com Subject: xfs-patch on kernel 2-4-19 X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Sat, 21 Sep 2002 15:35:03 +0200 X-MIMETrack: Serialize by Im Leerlauf on christian(Version 5.0.2c (Intl)|08 Februar 2000) at 21.09.2002 15:35:24, Serialize complete at 21.09.2002 15:35:24 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: 310078580701-0001@t-dialin.net X-archive-position: 535 X-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_binder@t-online.de Precedence: bulk X-list: linux-xfs Hello ! I am using the xfs-Filesystem for nearly 36 Month on some Debian 2.2 Potato - Systems and it works very well. I was very glad, that I now have a robust and stable Filesystem on my Linuxsystems. Since patching, compiling and installing the kernel 2.4.19, I have big troubles on some partitions, to mount them, and other Filesystemtroubles. The 2.4.18 Kernel with the xfs-Patch worked very well for some month. I tought, that I can boot the well-working Kernel 2.4.18 and my problems hide away, but this was only a wish. Now I need someone, who can give me a help. A "dmesg" give me after booting the machine the following text: ========cut============== Starting kswapd Detected PS/2 Mouse Port. pty: 256 Unix98 ptys configured block: 128 slots per queue, batch=32 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: WDC AC22500L, ATA DISK drive hdc: ST320423A, ATA DISK drive hdd: TOSHIBA CD-ROM XM-6002B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 4999680 sectors (2560 MB) w/256KiB Cache, CHS=620/128/63 hdc: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=39693/16/63 Partition check: hda: hda1 hda2 hda3 hda4 hdc: [DM6:DDO] [remap +63] [2490/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 > Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 62M agpgart: no supported devices found. [drm] Initialized tdfx 1.0.0 20010216 on minor 0 [drm] Initialized radeon 1.1.1 20010405 on minor 1 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 60k freed Adding Swap: 455608k swap-space (priority -1) isapnp: Scanning for PnP cards... isapnp: Card 'ELSA QuickStep 1000' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug & Play cards detected total eth0: 3c5x9 at 0x220, 10baseT port, address 00 60 97 50 65 74, IRQ 5. 3c509.c:1.18a 17Nov2001becker@scyld.com http://www.scyld.com/network/3c509.html Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A SGI XFS with no debug enabled XFS mounting filesystem ide1(22,2) Starting XFS recovery on filesystem: ide1(22,2) (dev: 22/2) Ending XFS recovery on filesystem: ide1(22,2) (dev: 22/2) XFS mounting filesystem ide1(22,3) XFS: corrupted root inode XFS: device 0x1603- Root inode 128 is not a directory Unable to handle kernel NULL pointer dereference at virtual address 0000002c printing eip: c68c151b *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010246 eax: 00000000 ebx: c375d2a4 ecx: c375d140 edx: c1187138 esi: c3acfa00 edi: c375d2a4 ebp: c3acfa14 esp: c3acf974 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 76, stackpage=c3acf000) Stack: c68c1689 c375d2a4 00000080 00000000 c68a4c13 c375d2a4 c3acfa00 c375d2a4 00001603 00000000 c5d6d88b 000ac154 00000000 00000004 000560a8 00000000 00000019 00000000 c5c3b1e8 00000000 00000004 00000000 00000001 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 2c c3 90 83 ec 70 57 56 53 8b b4 24 80 00 00 00 8b bc eth0: Setting Rx mode to 1 addresses. xfs_create looping, dir ino 0xc30739, ino 0xc307c1, ide1(22,2) ========end===================== A "tail -f /var/log/messages" tell me this: ==========begin=========== Sep 21 16:37:39 thira kernel: [xfs:__insmod_xfs_S.data_L2708+2440/2720] [set_devname+39/84] [do_kern_mount+170/316] [xfs:__insmod_xfs_S.data_L2708+2440/2720] [do_add_mount+32/472] [do_mount+311/336] Sep 21 16:37:39 thira kernel: [copy_mount_options+80/164] [sys_mount+132/196] [system_call+51/64] Sep 21 16:37:39 thira kernel: Sep 21 16:37:39 thira kernel: Code: 8b 40 2c c3 90 83 ec 70 57 56 53 8b b4 24 80 00 00 00 8b bc Sep 21 16:37:39 thira kernel: eth0: Setting Rx mode to 1 addresses. Sep 21 16:37:47 thira kernel: xfs_create looping, dir ino 0xc30739, ino 0xc307c1, ide1(22,2) Sep 21 16:37:47 thira kernel: =======end========== the "lsmod" shows nothing out of the ordinary: =======begin========= Module Size Used by Not tainted floppy 45724 2 (autoclean) xfs 413776 5 (autoclean) xfs_support 6770 0 (autoclean) [xfs] serial 43940 0 (autoclean) 3c509 7764 1 isa-pnp 27700 0 [serial 3c509] vfat 9196 1 fat 28920 0 [vfat] ==========end======== all partitions except the /usr - Partition, wich is also a xfs-Partition aren`t mounted after the boot-process. (BTW:The / Partition is a ext2 - Partition.) I was very surprised, that a "ls" in some directories of the /usr - Partition shows me files (e. g. the smbd.pid-Sambafile), and a "ls -lia" shows me the same files not. A "rm filename" says, that there is no such file or directory. If I want to do a "xfs_check" on the other Partitions, it wouldnt start; the process hangs up. A "xfs_repair" do the same. What can I do, to rescue the worthfull datas on the partitions of the harddisk ? Thanks for help ! Christian From owner-linux-xfs@oss.sgi.com Sat Sep 21 06:55:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 06:55:27 -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 g8LDtOtG021424 for ; Sat, 21 Sep 2002 06:55:25 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 9D9764B7E7E; Sat, 21 Sep 2002 08:55:26 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 2995E4B7E7D; Sat, 21 Sep 2002 08:55:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 2074EC00440; Sat, 21 Sep 2002 08:55:25 -0500 (EST) Date: Sat, 21 Sep 2002 08:55:24 -0500 (EST) From: Mike Burger To: vricks@guilford.edu Cc: linux-xfs@oss.sgi.com Subject: Re: Can Windows read XFS? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-archive-position: 536 X-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 No...there is nothing currently available which will allow a Windows system to read an XFS formatted filesystem. On Tue, 17 Sep 2002 vricks@guilford.edu wrote: > > I've unsuccessfully checked the archives for the answer to the above > question. Are there any programs that allow Windows NT/2k/XP systems to > read XFS filesystem data? I have a dual-boot XP/Linux system with the > /home partition formatted XFS. > > Thanks > Vance Ricks > Assistant Professor of Philosophy > Guilford College > Greensboro, NC 27410 > > > > John M Trostel > > ntum.com> cc: linux-xfs@oss.sgi.com > Sent by: Subject: Re: 2.4.17 + XFS? > linux-xfs-bounce@ > oss.sgi.com > > > 09/17/02 02:22 PM > > > > > > > Hi Jose > > The currently supported kernel in the CVS tree is 2.4.19 (not 2.4.9). > The currently supported kernel for RPM installs with version 1.1 of XFS > is kernel 2.4.18. Only if one wants a RH 7.1 or 7.2 rpm install, is the > kernel version 2.4.9-x used. > > I would upgrade my kernel from 2.4.17 to 2.4.19 and take advantage of > that advance also, if possible. You could also be somewhat more > conservative and upgrade to the version 1.1 of XFS on the 2.4.18 kernel > level. > > (Actually, I have kept my laptop up with the CVS tree... but I enjoy > living dangerously.) > > On Tue, 2002-09-17 at 13:50, jose Hernandez wrote: > > Hello. > > > > I would like to install the XFS support for my kernel (2.4.17).but I > > have seen that the supported kernel is 2.4.9. > > > > Can I to install XFS on my kernel 2.4.17 or Have I to downgrade to > > 2.4.9? > > > > Thanks a lot for your help. > > > > > > > > > > > -- > John M. Trostel > Senior Software Engineer > Quantum Corp. > john.trostel@quantum.com > > > > > > > > From owner-linux-xfs@oss.sgi.com Sat Sep 21 10:13:35 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 10:13:40 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8LHDYtG023836 for ; Sat, 21 Sep 2002 10:13:34 -0700 Received: (qmail 30984 invoked by uid 500); 21 Sep 2002 17:13:22 -0000 Subject: Re: xfs-patch on kernel 2-4-19 From: Austin Gonyou To: christian_binder@t-online.de Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032628402.30945.15.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 21 Sep 2002 12:13:22 -0500 X-archive-position: 537 X-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 got a similar error with 2.4.19 and FS made by old tools. What I ended up doing was ensuring that I had a good backup, then ran xfs_repair on each FS. If it segfaults on you, then you might want to do xfs_repair -L to dump the log. it should check and then mount. Lemme know what happens. On Sat, 2002-09-21 at 08:35, christian_binder@t-online.de wrote: > Hello ! > > I am using the xfs-Filesystem for nearly 36 Month on some Debian 2.2 > Potato - Systems and it works very well. > I was very glad, that I now have a robust and stable Filesystem on my > Linuxsystems. > Since patching, compiling and installing the kernel 2.4.19, I have > big > troubles on some partitions, to mount them, and other > Filesystemtroubles. > The 2.4.18 Kernel with the xfs-Patch worked very well for some month. > I tought, that I can boot the well-working Kernel 2.4.18 and my > problems > hide away, but this was only a wish. > Now I need someone, who can give me a help. > > A "dmesg" give me after booting the machine the following text: > ========cut============== > Starting kswapd > Detected PS/2 Mouse Port. > pty: 256 Unix98 ptys configured > block: 128 slots per queue, batch=32 > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > hda: WDC AC22500L, ATA DISK drive > hdc: ST320423A, ATA DISK drive > hdd: TOSHIBA CD-ROM XM-6002B, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 4999680 sectors (2560 MB) w/256KiB Cache, CHS=620/128/63 > hdc: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=39693/16/63 > Partition check: > hda: hda1 hda2 hda3 hda4 > hdc: [DM6:DDO] [remap +63] [2490/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 > hdc6 > hdc7 hdc8 hdc9 hdc10 > > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 62M > agpgart: no supported devices found. > [drm] Initialized tdfx 1.0.0 20010216 on minor 0 > [drm] Initialized radeon 1.1.1 20010405 on minor 1 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 8192 bind 8192) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > VFS: Mounted root (ext2 filesystem) readonly. > Freeing unused kernel memory: 60k freed > Adding Swap: 455608k swap-space (priority -1) > isapnp: Scanning for PnP cards... > isapnp: Card 'ELSA QuickStep 1000' > isapnp: Card '3Com 3C509B EtherLink III' > isapnp: 2 Plug & Play cards detected total > eth0: 3c5x9 at 0x220, 10baseT port, address 00 60 97 50 65 74, IRQ 5. > 3c509.c:1.18a 17Nov2001becker@scyld.com > http://www.scyld.com/network/3c509.html > Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ > SERIAL_PCI ISAPNP enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > SGI XFS with no debug enabled > XFS mounting filesystem ide1(22,2) > Starting XFS recovery on filesystem: ide1(22,2) (dev: 22/2) > Ending XFS recovery on filesystem: ide1(22,2) (dev: 22/2) > XFS mounting filesystem ide1(22,3) > XFS: corrupted root inode > XFS: device 0x1603- Root inode 128 is not a directory > Unable to handle kernel NULL pointer dereference at virtual address > 0000002c > printing eip: > c68c151b > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010246 > eax: 00000000 ebx: c375d2a4 ecx: c375d140 edx: c1187138 > esi: c3acfa00 edi: c375d2a4 ebp: c3acfa14 esp: c3acf974 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 76, stackpage=c3acf000) > Stack: c68c1689 c375d2a4 00000080 00000000 c68a4c13 c375d2a4 c3acfa00 > c375d2a4 > 00001603 00000000 c5d6d88b 000ac154 00000000 00000004 000560a8 > 00000000 > 00000019 00000000 c5c3b1e8 00000000 00000004 00000000 00000001 > 00000000 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] > > Code: 8b 40 2c c3 90 83 ec 70 57 56 53 8b b4 24 80 00 00 00 8b bc > eth0: Setting Rx mode to 1 addresses. > xfs_create looping, dir ino 0xc30739, ino 0xc307c1, ide1(22,2) > > ========end===================== > > > A "tail -f /var/log/messages" tell me this: > > ==========begin=========== > Sep 21 16:37:39 thira kernel: > [xfs:__insmod_xfs_S.data_L2708+2440/2720] > [set_devname+39/84] [do_kern_mount+170/316] > [xfs:__insmod_xfs_S.data_L2708+2440/2720] [do_add_mount+32/472] > [do_mount+311/336] > Sep 21 16:37:39 thira kernel: [copy_mount_options+80/164] > [sys_mount+132/196] [system_call+51/64] > Sep 21 16:37:39 thira kernel: > Sep 21 16:37:39 thira kernel: Code: 8b 40 2c c3 90 83 ec 70 57 56 53 > 8b b4 > 24 80 00 00 00 8b bc > Sep 21 16:37:39 thira kernel: eth0: Setting Rx mode to 1 addresses. > Sep 21 16:37:47 thira kernel: xfs_create looping, dir ino 0xc30739, > ino > 0xc307c1, ide1(22,2) > Sep 21 16:37:47 thira kernel: > > =======end========== > > the "lsmod" shows nothing out of the ordinary: > =======begin========= > Module Size Used by Not tainted > floppy 45724 2 (autoclean) > xfs 413776 5 (autoclean) > xfs_support 6770 0 (autoclean) [xfs] > serial 43940 0 (autoclean) > 3c509 7764 1 > isa-pnp 27700 0 [serial 3c509] > vfat 9196 1 > fat 28920 0 [vfat] > ==========end======== > > all partitions except the /usr - Partition, wich is also a > xfs-Partition > aren`t mounted after the boot-process. > (BTW:The / Partition is a ext2 - Partition.) > > I was very surprised, that a "ls" in some directories of the /usr - > Partition shows me files (e. g. the smbd.pid-Sambafile), and a "ls > -lia" > shows me the same files not. A "rm filename" says, that there is no > such > file or directory. > > If I want to do a "xfs_check" on the other Partitions, it wouldnt > start; > the process hangs up. > A "xfs_repair" do the same. > > What can I do, to rescue the worthfull datas on the partitions of the > harddisk ? > > Thanks for help ! > > Christian > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Sat Sep 21 10:37:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 10:37: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 g8LHbhtG024387 for ; Sat, 21 Sep 2002 10:37:43 -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 MAA90412; Sat, 21 Sep 2002 12:37:38 -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 MAA04337; Sat, 21 Sep 2002 12:37:37 -0500 (CDT) Date: Sat, 21 Sep 2002 12:31:56 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: christian_binder@t-online.de cc: linux-xfs@oss.sgi.com Subject: Re: xfs-patch on kernel 2-4-19 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 538 X-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 Christian - On Sat, 21 Sep 2002 christian_binder@t-online.de wrote: > A "dmesg" give me after booting the machine the following text: ... > SGI XFS with no debug enabled > XFS mounting filesystem ide1(22,2) > Starting XFS recovery on filesystem: ide1(22,2) (dev: 22/2) > Ending XFS recovery on filesystem: ide1(22,2) (dev: 22/2) That one mounted fine... > XFS mounting filesystem ide1(22,3) > XFS: corrupted root inode > XFS: device 0x1603- Root inode 128 is not a directory And this one has problems. > Unable to handle kernel NULL pointer dereference at virtual address Can you run this through ksymoops? > xfs_create looping, dir ino 0xc30739, ino 0xc307c1, ide1(22,2) This is odd, this is on the filesystem that said it mounted OK... > I was very surprised, that a "ls" in some directories of the /usr - > Partition shows me files (e. g. the smbd.pid-Sambafile), and a "ls -lia" > shows me the same files not. A "rm filename" says, that there is no such > file or directory. > > If I want to do a "xfs_check" on the other Partitions, it wouldnt start; > the process hangs up. > A "xfs_repair" do the same. Maybe you can do an strace of the process to see where it stops? Also, make sure you have the latest version of the tool... -Eric From owner-linux-xfs@oss.sgi.com Sat Sep 21 13:03:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 13:04:04 -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 g8LK3xtG025789 for ; Sat, 21 Sep 2002 13:03:59 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 54A281E0056; Sat, 21 Sep 2002 13:03:59 -0700 (PDT) Date: Sat, 21 Sep 2002 13:03:59 -0700 From: Chris Wedgwood To: christian.guggenberger@physik.uni-regensburg.de Cc: linux-xfs@oss.sgi.com Subject: Re: Clarification Message-ID: <20020921200359.GA25563@tapu.f00f.org> References: <3D8B03F4.497B7EE4@tataelxsi.co.in> <20020920190749.GB10692@tapu.f00f.org> <3D8B75DC.1010305@koschikode.com> <20020920194326.GB15065@tapu.f00f.org> <3D8B86BD.6050101@koschikode.com> <20020920203850.GA15627@tapu.f00f.org> <20020921002754.GA17878@pc9391.physik.uni-regensburg.de> <20020921005436.GA18548@tapu.f00f.org> <20020921103514.GA8447@pc9391.physik.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020921103514.GA8447@pc9391.physik.uni-regensburg.de> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 539 X-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 21, 2002 at 12:35:14PM +0200, christian.guggenberger@physik.uni-regensburg.de wrote: > CVS of August, 27th. Did you run it with '-d -v' ? --cw From owner-linux-xfs@oss.sgi.com Sat Sep 21 15:14:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 15:14:49 -0700 (PDT) Received: from mail47.fg.online.no (mail47-s.fg.online.no [148.122.161.47]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8LMEgtG028041 for ; Sat, 21 Sep 2002 15:14:42 -0700 Received: from spam.no (ti400720a080-0907.bb.online.no [80.212.163.139]) by mail47.fg.online.no (8.9.3/8.9.3) with SMTP id AAA10063 for ; Sun, 22 Sep 2002 00:14:35 +0200 (MEST) Date: Sun, 22 Sep 2002 00:14:52 +0200 From: Michael To: linux-xfs@oss.sgi.com Subject: Undeletion Message-Id: <20020922001452.52752d52.soppscum@online.no> X-Mailer: Sylpheed version 0.8.2 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 540 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: soppscum@online.no Precedence: bulk X-list: linux-xfs I'm certain XFS will probably never be rewritten to support undeletion. But I'm just curious if this was conscious and why?(maybe just "wasn't important"?) Thanks =D From owner-linux-xfs@oss.sgi.com Sat Sep 21 15:54:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 15:54:31 -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 g8LMogtG028626 for ; Sat, 21 Sep 2002 15:54:28 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 6B84611C5D; Sat, 21 Sep 2002 15:50:34 -0700 (PDT) Date: Sat, 21 Sep 2002 15:50:34 -0700 From: Chris Wedgwood To: Michael Cc: linux-xfs@oss.sgi.com Subject: Re: Undeletion Message-ID: <20020921225034.GA26759@tapu.f00f.org> References: <20020922001452.52752d52.soppscum@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020922001452.52752d52.soppscum@online.no> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 541 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Sun, Sep 22, 2002 at 12:14:52AM +0200, Michael wrote: > I'm certain XFS will probably never be rewritten to support > undeletion. Well, in a sense to support undeletion *well*, you pretty much need to design the fs with this idea in mind. I think NWFS has some smarts to deal with undeletion internally for example (and has done for a long time). > But I'm just curious if this was conscious and why?(maybe just > "wasn't important"?) Much of the time for most people it just isn't required... there are userspace solutions that work pretty well for most people most of the time. Undeletion doesn't help when you scribble over a file or save the wrong version in the wrong place, so in a sense you don't really want undeletion but RO snapshots that do COW on the underlying extents as required. This is what WAFL provides and it works really well. --cw From owner-linux-xfs@oss.sgi.com Sat Sep 21 16:05:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 16:06:00 -0700 (PDT) Received: from picasso.animezone.org (CPE3236333133323237.cpe.net.cable.rogers.com [24.100.159.193] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8LN5stG029217 for ; Sat, 21 Sep 2002 16:05:55 -0700 Received: (from andrewho@localhost) by picasso.animezone.org (8.11.6/8.11.6) id g8LN8ou21818 for linux-xfs@oss.sgi.com; Sat, 21 Sep 2002 19:08:50 -0400 Date: Sat, 21 Sep 2002 19:08:50 -0400 From: Andrew Ho Message-Id: <200209212308.g8LN8ou21818@picasso.animezone.org> To: linux-xfs@oss.sgi.com Subject: Re: MosiX Cluster with XFS - Tried anyone ? X-archive-position: 542 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrewho@animezone.org Precedence: bulk X-list: linux-xfs uergen Sauer wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, did anyone successfully tried to build a mosix cluster with XFS ? Reffer to http://www.mosix.org http://www.openmosix.org Yes, I did. I got 2.4.17-xfs first, then patched the mosix-kernel for Linux-2.4.17. I did not have any problems of the compilation, and it was working perfectly. Now, I am working on 2.4.19-xfs with mosix. From owner-linux-xfs@oss.sgi.com Sat Sep 21 17:25:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 17:25:48 -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 g8M0PgtG030067 for ; Sat, 21 Sep 2002 17:25:42 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id AE6AF145F4; Sun, 22 Sep 2002 02:25:36 +0200 (MEST) Date: Sun, 22 Sep 2002 02:25:36 +0200 From: Andi Kleen To: Michael Cc: linux-xfs@oss.sgi.com Subject: Re: Undeletion Message-ID: <20020922022536.A28975@wotan.suse.de> References: <20020922001452.52752d52.soppscum@online.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020922001452.52752d52.soppscum@online.no> User-Agent: Mutt/1.3.22.1i X-archive-position: 543 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Sun, Sep 22, 2002 at 12:14:52AM +0200, Michael wrote: > I'm certain XFS will probably never be rewritten to support undeletion. > But I'm just curious if this was conscious and why?(maybe just "wasn't important"?) Actually XFS internally does something very similar to undeletion. In Unix it is possible to delete all links to a file and still have the file open by some process. The file is then deleted when the process exits. When the system crashes before that happens these unnamed files need to be cleaned up somehow, otherwise you would lose disk space after reboot. On a non journaled unix filesystem that is done by fsck after the unclean shutdown. On a journaled filesystem this doesn't work. XFS puts these files into a special data structure on disk and deletes them on the next mount. I guess it would be possible to extend this to put files that have been marked somehow (e.g. with a special extended attribute) on unlink into this store as well and only free them when the disk space runs low. Of course someone would need to implement this. I don't think it would need a "rewrite" however. -Andi From owner-linux-xfs@oss.sgi.com Sat Sep 21 20:31:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Sep 2002 20:31:08 -0700 (PDT) Received: from mta2.sucs.soton.ac.uk (mta2.sucs.soton.ac.uk [152.78.128.141]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8M3V2tG031824 for ; Sat, 21 Sep 2002 20:31:03 -0700 Received: from dumbo (dhcp-135-208.staff.sucs.soton.ac.uk [152.78.135.208]) (authenticated bits=0) by mta2.sucs.soton.ac.uk (8.12.3/8.12.3) with ESMTP id g8GEqM7O001327; Mon, 16 Sep 2002 15:52:22 +0100 Reply-To: From: "Ian D. Hardy" To: "'Stephen Lord'" Cc: , Subject: RE: Re-occurance of NFS server panics Date: Mon, 16 Sep 2002 15:52:23 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: <1025114895.1280.10.camel@n236> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-MailScanner: Believed to be clean X-archive-position: 544 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: I.D.Hardy@soton.ac.uk Precedence: bulk X-list: linux-xfs Steve +, Sorry to bother you again. You may remember that we've corresponded several times over the past ~9months with regards to kernel memory allocation problems and fragmented files (see bellow). We had a period of relative stability, however the last few weeks we have gone back to a situation of having one or more crashes/hangs every week and are now having to again review our continued use of XFS. Therefore any update on progress towards a fix for these problems would be very useful (I'd hate to go though the pain of converting our ~1Tbyte filesystem to Reiser of ext3 if there are fixes immanent). We have been running a 2.4.18 XFS CVS kernel from Mid May for some time now, I'm just in the process of compiling and testing the current 2.4.19 XFS CVS, is this likely to help? (looking through the list archive I can't find anything of direct relevance but may have missed something). We appear to be running at a lower overall system fragmentation level now (currently 13% in the past it has been 28% or more), though I guess it is possible for only a couple of large very fragmented files to result in kernel memory allocation problems and still have reasonably low overall FS fragmentation levels? Unfortunately the NFS load on our server is such that it is difficult/impossible to predict times of light NFS load in which to run fsr and as reported before we've had several incidents of filesystem corruption and the kernel taking the FS offline running fsr under a NFS load. Thanks for your time (BTW: We've persevered with XFS for so long as it seems to give better performance for our workload than ext3 or ReiserFS, however, stability is again becoming a problem). Regards Ian Hardy Research Support Services ISS Southampton University, UK -----Original Message----- From: Stephen Lord [mailto:lord@sgi.com] Sent: 26 June 2002 19:08 To: Ian D. Hardy Cc: linux-xfs@oss.sgi.com; I.D.Hardy@soton.ac.uk; O.G.Parchment@soton.ac.uk Subject: Re: Re-occurance of NFS server panics On Wed, 2002-06-26 at 12:36, Ian D. Hardy wrote: Sorry, you dropped through the cracks there, and I am currently sitting in the back of a talk at the Ottawa Linux Symposium, so my coding time is a little limited this week. Next week there will also be no one in the office (except the Australian contingent). Seems you have two issues, first file fragmentation and the fact that fsr appears to have issues on a live system. Yes I agree that running fsr during down time is the best solution available right now. I do not know if you have an idle time where you could actually run fsr on a known idle system. I think it has options to run for a fixed amount of time instead of running to completion. If you have known times when activity is low you could possibly run fsr during this period. The fundamental issue is the amount of memory which one of these fragmented files needs to hold its extents and the ideal solution to to change how this memory is organized. I have tinkered with the idea, but it is a non-trivial project and I do not know when I might get to do it. So I don't really have a code solution for you right now, we need to look into what is happening to fsr under nfs load, there should be something we can do to fix that faster than the extent allocation code. Steve > Steve ++ Colleagues, > > Sorry to bother you (I understand that your busy & short > staffed) - it would be useful to get some feedback on > the problems/issues I raised a couple of weeks ago (I did note that > you mentioned continuing problems due to fragmentation in another > thread a few days ago). Do you have any idea if/when it should be > possible to fix this problem? (I feel bad asking; but I'm getting > preasure to look again at alternatives ...... which I'd rather not do > - as I'm sure they have their own problems!). > > FYI: in the last ~20 days we've had another panic, that looked like > another memory alloc error (I was on leave - so didn't get the full > details) + a couple of system lockups (high load average and failing > to fileserve); possibly not related. We reduced the load by > introducing another server/filesystem (reiserfs !!) and moving some > users onto that, today we had some scheduled maintenance time and did > an ofline defrag of the XFS filesystem bringing it down from ~28% to > <1%. > > Is there anything that I can do (remember I'm not a kernel > writer/expert) to help, any further diagnostics that would help. > > Again many thanks for your help. > > Ian Hardy > > > /////////////Technical Coordination, Research Services//////////////////// > Ian Hardy Tel: 023 80 593577 > Computing Services Mobile: 0709 2127503 > Southampton University email: idh@soton.ac.uk > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for > netstat)\ From owner-linux-xfs@oss.sgi.com Sun Sep 22 12:27:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Sep 2002 12:27:05 -0700 (PDT) Received: from mail.lbsd.net (mail.lbsd.net [196.25.111.97]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8MJQwtG019497 for ; Sun, 22 Sep 2002 12:27:00 -0700 Received: from localhost (nkukard@localhost) by mail.lbsd.net (8.12.1/8.12.1) with ESMTP id g8MJQt4v010075 for ; Sun, 22 Sep 2002 21:26:56 +0200 Date: Sun, 22 Sep 2002 21:26:54 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: XFS + grsecurity patches Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 545 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nkukard@lbsd.net Precedence: bulk X-list: linux-xfs I've created some patches for grsecurity + XFS, in detail grsecurity-1.9.7-2.4.19 and xfs-2.4.19-all patches can be found .... http://www.lbsd.net Special thanks to the XFS team! -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd nigel@lando.co.za www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036 Hoheisen Park Bellville, Cape Town National Internet Service Provider The best language to use is the language that was designed for what you want to use it for. - Nigel Kukard 1997 ===================================================================== Disclaimer ---------- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please notify the sender immediately by reply e-mail and then destroy the message and any copies thereof. Opinions, conclusions and other information in this message may be personal to the sender and is not that of Lando Technologies Africa or any of it's subsideries, associated companies or principals and is therefore not endorsed by any of the Lando groups of companies. Due to e-maill communication being insecure, Lando groups of companies do not guarantee confidentiality, security, accuracy or performance of the e-mail. Any liability for viruses is excluded to the fullest extent. From owner-linux-xfs@oss.sgi.com Sun Sep 22 12:47:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Sep 2002 12:47:35 -0700 (PDT) Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8MJlUtG020065 for ; Sun, 22 Sep 2002 12:47:30 -0700 Received: from fwd11.sul.t-online.de by mailout03.sul.t-online.com with smtp id 17tChR-00078M-0L; Sun, 22 Sep 2002 21:47:25 +0200 Received: from CBINDER (310078580701-0001@[217.2.76.33]) by fwd11.sul.t-online.com with esmtp id 17tChM-1cBIieC; Sun, 22 Sep 2002 21:47:20 +0200 From: christian_binder@t-online.de To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Antwort: Re: xfs-patch on kernel 2-4-19 X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Sun, 22 Sep 2002 21:44:48 +0200 X-MIMETrack: Serialize by Im Leerlauf on christian(Version 5.0.2c (Intl)|08 Februar 2000) at 22.09.2002 21:47:11, Serialize complete at 22.09.2002 21:47:11, Serialize by Im Leerlauf on christian(Version 5.0.2c (Intl)|08 Februar 2000) at 22.09.2002 21:47:12 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: 310078580701-0001@t-dialin.net X-archive-position: 546 X-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_binder@t-online.de Precedence: bulk X-list: linux-xfs Hi Eric, thank`s a lot for your fast answer ! I have compiled the newest xfs-tools and I was able to recover the Fileystem ide1(22,2) (=/usr) which has the same Problems at booting the machine as the ide1(22,3). After installing a minimal Debian on a new harddisk, I was able to do the xfs_repair on the ide1(22,2), and I was able to mount this partition and was glad, that all files of this partition where ok. I do the same at the ide1(22,3) and mounted it, but there was only the "lost+found" directory with many "lost+found" files. A simply "df" showed me, that the capacity shows 80 % (the same as before the crash.) Is there a chance, to rescue my files on this (=/home) Partition ? Thank you for your help Christian Eric Sandeen 21.09.2002 19:31 An: christian_binder@t-online.de Kopie: linux-xfs@oss.sgi.com Thema: Re: xfs-patch on kernel 2-4-19 Hi Christian - On Sat, 21 Sep 2002 christian_binder@t-online.de wrote: > A "dmesg" give me after booting the machine the following text: ... > SGI XFS with no debug enabled > XFS mounting filesystem ide1(22,2) > Starting XFS recovery on filesystem: ide1(22,2) (dev: 22/2) > Ending XFS recovery on filesystem: ide1(22,2) (dev: 22/2) That one mounted fine... > XFS mounting filesystem ide1(22,3) > XFS: corrupted root inode > XFS: device 0x1603- Root inode 128 is not a directory And this one has problems. > Unable to handle kernel NULL pointer dereference at virtual address Can you run this through ksymoops? > xfs_create looping, dir ino 0xc30739, ino 0xc307c1, ide1(22,2) This is odd, this is on the filesystem that said it mounted OK... > I was very surprised, that a "ls" in some directories of the /usr - > Partition shows me files (e. g. the smbd.pid-Sambafile), and a "ls -lia" > shows me the same files not. A "rm filename" says, that there is no such > file or directory. > > If I want to do a "xfs_check" on the other Partitions, it wouldnt start; > the process hangs up. > A "xfs_repair" do the same. Maybe you can do an strace of the process to see where it stops? Also, make sure you have the latest version of the tool... -Eric From owner-linux-xfs@oss.sgi.com Sun Sep 22 12:47:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Sep 2002 12:47:35 -0700 (PDT) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8MJlWtG020074 for ; Sun, 22 Sep 2002 12:47:32 -0700 Received: from fwd11.sul.t-online.de by mailout04.sul.t-online.com with smtp id 17tChR-00015q-07; Sun, 22 Sep 2002 21:47:25 +0200 Received: from CBINDER (310078580701-0001@[217.2.76.33]) by fwd11.sul.t-online.com with esmtp id 17tChN-1cBIifC; Sun, 22 Sep 2002 21:47:21 +0200 From: christian_binder@t-online.de To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Antwort: Re: xfs-patch on kernel 2-4-19 X-Mailer: Lotus Notes Version 5.0.2c (Intl) 08 Februar 2000 Message-ID: Date: Sun, 22 Sep 2002 21:46:55 +0200 X-MIMETrack: Serialize by Im Leerlauf on christian(Version 5.0.2c (Intl)|08 Februar 2000) at 22.09.2002 21:47:12, Serialize complete at 22.09.2002 21:47:12 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: 310078580701-0001@t-dialin.net X-archive-position: 547 X-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_binder@t-online.de Precedence: bulk X-list: linux-xfs Thank you ! On one Partition, it works with new xfs-tools very good, but the other ... (See at the answer to Eric.) Christian Austin Gonyou 21.09.2002 19:13 An: christian_binder@t-online.de Kopie: linux-xfs@oss.sgi.com Thema: Re: xfs-patch on kernel 2-4-19 I got a similar error with 2.4.19 and FS made by old tools. What I ended up doing was ensuring that I had a good backup, then ran xfs_repair on each FS. If it segfaults on you, then you might want to do xfs_repair -L to dump the log. it should check and then mount. Lemme know what happens. On Sat, 2002-09-21 at 08:35, christian_binder@t-online.de wrote: > Hello ! > > I am using the xfs-Filesystem for nearly 36 Month on some Debian 2.2 > Potato - Systems and it works very well. > I was very glad, that I now have a robust and stable Filesystem on my > Linuxsystems. > Since patching, compiling and installing the kernel 2.4.19, I have > big > troubles on some partitions, to mount them, and other > Filesystemtroubles. > The 2.4.18 Kernel with the xfs-Patch worked very well for some month. > I tought, that I can boot the well-working Kernel 2.4.18 and my > problems > hide away, but this was only a wish. > Now I need someone, who can give me a help. > > A "dmesg" give me after booting the machine the following text: > ========cut============== > Starting kswapd > Detected PS/2 Mouse Port. > pty: 256 Unix98 ptys configured > block: 128 slots per queue, batch=32 > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with > idebus=xx > hda: WDC AC22500L, ATA DISK drive > hdc: ST320423A, ATA DISK drive > hdd: TOSHIBA CD-ROM XM-6002B, ATAPI CD/DVD-ROM drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 4999680 sectors (2560 MB) w/256KiB Cache, CHS=620/128/63 > hdc: 40011300 sectors (20486 MB) w/512KiB Cache, CHS=39693/16/63 > Partition check: > hda: hda1 hda2 hda3 hda4 > hdc: [DM6:DDO] [remap +63] [2490/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 > hdc6 > hdc7 hdc8 hdc9 hdc10 > > Linux agpgart interface v0.99 (c) Jeff Hartmann > agpgart: Maximum main memory to use for agp memory: 62M > agpgart: no supported devices found. > [drm] Initialized tdfx 1.0.0 20010216 on minor 0 > [drm] Initialized radeon 1.1.1 20010405 on minor 1 > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 8192 bind 8192) > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > VFS: Mounted root (ext2 filesystem) readonly. > Freeing unused kernel memory: 60k freed > Adding Swap: 455608k swap-space (priority -1) > isapnp: Scanning for PnP cards... > isapnp: Card 'ELSA QuickStep 1000' > isapnp: Card '3Com 3C509B EtherLink III' > isapnp: 2 Plug & Play cards detected total > eth0: 3c5x9 at 0x220, 10baseT port, address 00 60 97 50 65 74, IRQ 5. > 3c509.c:1.18a 17Nov2001becker@scyld.com > http://www.scyld.com/network/3c509.html > Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ > SERIAL_PCI ISAPNP enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > SGI XFS with no debug enabled > XFS mounting filesystem ide1(22,2) > Starting XFS recovery on filesystem: ide1(22,2) (dev: 22/2) > Ending XFS recovery on filesystem: ide1(22,2) (dev: 22/2) > XFS mounting filesystem ide1(22,3) > XFS: corrupted root inode > XFS: device 0x1603- Root inode 128 is not a directory > Unable to handle kernel NULL pointer dereference at virtual address > 0000002c > printing eip: > c68c151b > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010246 > eax: 00000000 ebx: c375d2a4 ecx: c375d140 edx: c1187138 > esi: c3acfa00 edi: c375d2a4 ebp: c3acfa14 esp: c3acf974 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 76, stackpage=c3acf000) > Stack: c68c1689 c375d2a4 00000080 00000000 c68a4c13 c375d2a4 c3acfa00 > c375d2a4 > 00001603 00000000 c5d6d88b 000ac154 00000000 00000004 000560a8 > 00000000 > 00000019 00000000 c5c3b1e8 00000000 00000004 00000000 00000001 > 00000000 > Call Trace: [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] [] [] > [] > [] [] [] > > Code: 8b 40 2c c3 90 83 ec 70 57 56 53 8b b4 24 80 00 00 00 8b bc > eth0: Setting Rx mode to 1 addresses. > xfs_create looping, dir ino 0xc30739, ino 0xc307c1, ide1(22,2) > > ========end===================== > > > A "tail -f /var/log/messages" tell me this: > > ==========begin=========== > Sep 21 16:37:39 thira kernel: > [xfs:__insmod_xfs_S.data_L2708+2440/2720] > [set_devname+39/84] [do_kern_mount+170/316] > [xfs:__insmod_xfs_S.data_L2708+2440/2720] [do_add_mount+32/472] > [do_mount+311/336] > Sep 21 16:37:39 thira kernel: [copy_mount_options+80/164] > [sys_mount+132/196] [system_call+51/64] > Sep 21 16:37:39 thira kernel: > Sep 21 16:37:39 thira kernel: Code: 8b 40 2c c3 90 83 ec 70 57 56 53 > 8b b4 > 24 80 00 00 00 8b bc > Sep 21 16:37:39 thira kernel: eth0: Setting Rx mode to 1 addresses. > Sep 21 16:37:47 thira kernel: xfs_create looping, dir ino 0xc30739, > ino > 0xc307c1, ide1(22,2) > Sep 21 16:37:47 thira kernel: > > =======end========== > > the "lsmod" shows nothing out of the ordinary: > =======begin========= > Module Size Used by Not tainted > floppy 45724 2 (autoclean) > xfs 413776 5 (autoclean) > xfs_support 6770 0 (autoclean) [xfs] > serial 43940 0 (autoclean) > 3c509 7764 1 > isa-pnp 27700 0 [serial 3c509] > vfat 9196 1 > fat 28920 0 [vfat] > ==========end======== > > all partitions except the /usr - Partition, wich is also a > xfs-Partition > aren`t mounted after the boot-process. > (BTW:The / Partition is a ext2 - Partition.) > > I was very surprised, that a "ls" in some directories of the /usr - > Partition shows me files (e. g. the smbd.pid-Sambafile), and a "ls > -lia" > shows me the same files not. A "rm filename" says, that there is no > such > file or directory. > > If I want to do a "xfs_check" on the other Partitions, it wouldnt > start; > the process hangs up. > A "xfs_repair" do the same. > > What can I do, to rescue the worthfull datas on the partitions of the > harddisk ? > > Thanks for help ! > > Christian > > -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Sun Sep 22 13:23:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 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 g8MKN7tG021257 for ; Sun, 22 Sep 2002 13:23:07 -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 PAA97000; Sun, 22 Sep 2002 15:23:00 -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 PAA86722; Sun, 22 Sep 2002 15:23:00 -0500 (CDT) Date: Sun, 22 Sep 2002 15:17:09 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: christian_binder@t-online.de cc: linux-xfs@oss.sgi.com Subject: Re: Antwort: Re: xfs-patch on kernel 2-4-19 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 548 X-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 Sun, 22 Sep 2002 christian_binder@t-online.de wrote: > I do the same at the ide1(22,3) and mounted it, but there was only the > "lost+found" directory with many "lost+found" files. Well, I guess I should have thought of this sooner. Since your root directory was in trouble, -everything- wound up in lost+found when you ran xfs_repair. So, you have probably not lost your files, but you did lose your file names... At this point, I think you'll just have to sort through lost+found and see what you can recognize. -Eric From owner-linux-xfs@oss.sgi.com Sun Sep 22 19:19:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Sep 2002 19:19:42 -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 g8N2JZtG023843 for ; Sun, 22 Sep 2002 19:19:35 -0700 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.55.232]) 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 TAA00033 for ; Sun, 22 Sep 2002 19:19:34 -0700 (PDT) mail_from (kaos@sherman.melbourne.sgi.com) Received: (from kaos@localhost) by sherman.melbourne.sgi.com (8.11.6/8.11.6) id g8N2JLD04703; Mon, 23 Sep 2002 12:19:21 +1000 Date: Mon, 23 Sep 2002 12:19:21 +1000 From: Keith Owens Message-Id: <200209230219.g8N2JLD04703@sherman.melbourne.sgi.com> Subject: TAKE - Tidy up uart_handle_kdb X-archive-position: 549 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Clean up the code and ifdefs in uart_handle_kdb. No functional change. Date: Sun Sep 22 19:18:18 PDT 2002 Workarea: sherman.melbourne.sgi.com:/build/kaos/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128132a linux/include/linux/serial_core.h - 1.3 From owner-linux-xfs@oss.sgi.com Sun Sep 22 21:33:32 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Sep 2002 21:34:17 -0700 (PDT) Received: from otto.cfht.hawaii.edu (otto.colonization.com [128.171.80.37]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8N4XTtG025676 for ; Sun, 22 Sep 2002 21:33:31 -0700 Received: (from lksi@localhost) by otto.cfht.hawaii.edu (8.8.8/8.8.8) id SAA11334; Sun, 22 Sep 2002 18:32:11 -1000 Date: Sun, 22 Sep 2002 18:32:10 -1000 From: Sidik Isani To: Stephen Lord Cc: Sidik Isani , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: kernel OOPS in xlog_do_log_recovery (2.4.19) Message-ID: <20020922183210.A11295@cfht.hawaii.edu> References: <20020918140359.A30339@cfht.hawaii.edu> <20020918162359.A30809@cfht.hawaii.edu> <20020919042202.GC586@frodo> <20020918201241.A31826@cfht.hawaii.edu> <1032436696.1114.8.camel@laptop.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1032436696.1114.8.camel@laptop.americas.sgi.com>; from lord@sgi.com on Thu, Sep 19, 2002 at 06:58:14AM -0500 X-archive-position: 550 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lksi@cfht.hawaii.edu Precedence: bulk X-list: linux-xfs --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 19, 2002 at 06:58:14AM -0500, Stephen Lord wrote: > On Thu, 2002-09-19 at 01:12, Sidik Isani wrote: > > On Thu, Sep 19, 2002 at 02:22:02PM +1000, Nathan Scott wrote: > > > Hi, > > > > > > On Wed, Sep 18, 2002 at 04:23:59PM -1000, Sidik Isani wrote: > > > > > > > > Anyway, the crash still happens right after "Starting XFS recovery". > > > > Please let me know what I should do next... > > > > > > > > > > I seem to remember Steve fixing an endian problem in the log code > > > at one point several months ago - this may be what's biting you - > > > perhaps you have a little endian number somewhere in the on disk > > > log and the new kernel is expecting it is as big endian. > > > > > > If so, the right thing to do would be to run recovery using the > > > old kernel - so first mount, then unmount the filesystem. This > > > should complete fine with the old kernel. Then run xfs_repair > > > on the filesystem. This will zero out the log in phase 2, so > > > you can start afresh. Once you've done those things you should > > > be able to mount and use this filesystem with the latest kernel. > > > > Great. That makes perfect sense. I guess it is not reasonable > > to expect the kernel itself to repair damage from previous bugs. > > Could it help you to have a copy of my log anyway, to at least > > make the new kernel detect this corruption in a more elegant way > > than crashing? I do see checks in there masking bits for valid > > version numbers and all. I wonder why these are not finding it. > > Another RAID with totally different data on it does the same thing. > > Thanks for solving my problem (well ... I'll let you know soon ;-) > > > > Be seeing you, > > > > - Sidik > > > > This is what I fixed: > > revision 1.240 > date: 2002/08/29 21:26:29; author: lord; state: Exp; lines: +2 -1 > modid: 2.4.x-xfs:slinx:126410a > when processing unlinked inodes and dealing with the di_next_unlinked > field, endian flip it. > > However, this code is purely in recovery dealing with what is in the > log, not with how the log is layed down. An old kernel would have > crashed in the same way on this problem. Basically it would arise on > a crash where the log had a lot of unlinked files to remove. There > were some earlier fixes, too, but nothing which would make things > worse so far as I can see. > > I presume in your original message you are saying you have the > fs and the 2.4.16 kernel will mount it and the 2.4.19 one will not? > Is this something you have done more than one? If you are mounting > readonly, you must also be specifying norecovery, otherwise the first > mount will actually have done a recovery on the fs. > > Probably too late for this, but if not, can you send a complete > backtrace, and the xlog printout you have, you might want to get new > commands first, there have been changes in logprint I think, we are at > 2.3.3 now. Ok. Two attachments. One is the backtrace from the serial console from an attempt to mount with 2.4.19 (same thing happens with CVS kernel from last week.) The last thing that happened to the filesystem was a clean "Ending recovery" message from 2.4.16. It rebooted cleanly. The second attachment is xfs_logprint output. Please let me know what I should do next... Thanks, - Sidik --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="minicom.cap" XFS mounting filesystem md(9,0) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: md(9,0) (dev: 9/0) Unable to handle kernel NULL pointer dereference at virtual address 00000044 printing eip: c0200733 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010286 eax: 00000034 ebx: 00000018 ecx: f7cac41c edx: 00000060 esi: f6b680d4 edi: f6b71dac ebp: f78b1a7c esp: f78b1a64 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 717, stackpage=f78b1000) Stack: f7cac41c f6b68074 f6b68068 f78b1b74 f6b71dac f7920524 f78b1ab0 c0202313 f7cac41c f6b68074 00000060 00000000 f78b1b74 f7d88dcc 00000006 f6b0a4d8 f6b68068 0000000d f6b684e8 f78b1bb4 c02031c2 f7d88dcc f78b1b74 f7df1400 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 58 10 85 db 74 1d 3b 58 0c 75 18 8b 45 08 83 c0 24 50 e8 Entering kdb (current=0xf78b0000, pid 717) on processor 0 Oops: Oops due to oops @ 0xc0200733 eax = 0x00000034 ebx = 0x00000018 ecx = 0xf7cac41c edx = 0x00000060 esi = 0xf6b680d4 edi = 0xf6b71dac esp = 0xf78b1a64 eip = 0xc0200733 ebp = 0xf78b1a7c xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010286 xds = 0x00000018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf78b1a30 [0]kdb> bt EBP EIP Function (args) 0xf78b1a7c 0xc0200733 xlog_recover_add_to_trans+0xb3 (0xf7cac41c, 0xf6b68074, 0x60, 0x0, 0xf78b1b74) kernel .text 0xc0100000 0xc0200680 0xc02007fc 0xf78b1ab0 0xc0202313 xlog_recover_process_data+0x213 (0xf7d88dcc, 0xf78b1b74, 0xf7df1400, 0xf6b68074, 0x1) kernel .text 0xc0100000 0xc0202100 0xc020237c 0xf78b1bb4 0xc02031c2 xlog_do_recovery_pass+0x3e6 (0xf7d88dcc, 0x36c58, 0x0, 0x36220, 0x0) kernel .text 0xc0100000 0xc0202ddc 0xc020396c 0xf78b1be8 0xc020399f xlog_do_log_recovery+0x33 (0xf7d88dcc, 0x36c58, 0x0, 0x36220, 0x0) kernel .text 0xc0100000 0xc020396c 0xc0203a34 0xf78b1c18 0xc0203a56 xlog_do_recover+0x22 (0xf7d88dcc, 0x36c58, 0x0, 0x36220, 0x0) kernel .text 0xc0100000 0xc0203a34 0xc0203bec 0xf78b1c6c 0xc0203c80 xlog_recover+0x94 (0xf7d88dcc, 0x1, 0xf6bc9c00, 0x40000, 0x5f800080) kernel .text 0xc0100000 0xc0203bec 0xc0203cac 0xf78b1c8c 0xc01f9a43 xfs_log_mount+0xc7 (0xf6bc9c00, 0x900, 0x5f800080, 0x0, 0x40000) kernel .text 0xc0100000 0xc01f997c 0xc01f9a78 0xf78b1da0 0xc0208911 xfs_mountfs+0xa95 (0xf7c94b04, 0xf6bc9c00, 0x900, 0x0, 0xf7cdb800) kernel .text 0xc0100000 0xc0207e7c 0xc0208e74 0xf78b1ddc 0xc0212c24 xfs_cmountfs+0x528 (0xf7c94b04, 0x900, 0x900, 0x0, 0xf7cdb800) kernel .text 0xc0100000 0xc02126fc 0xc0212cbc 0xf78b1e0c 0xc0212d01 xfs_mount+0x45 (0xf7c94b04, 0xf7cdb800, 0x0, 0xc0484f80, 0xf6bfa000) kernel .text 0xc0100000 0xc0212cbc 0xc0212d0c 0xf78b1e80 0xc02284d4 linvfs_read_super+0x128 (0xf6bfa000, 0xf6bca000, 0x0, 0xf6bfa000, 0xc048c5ac) [0]more> kernel .text 0xc0100000 0xc02283ac 0xc022863c 0xf78b1edc 0xc014a2ab get_sb_bdev+0x26b (0xc048c5ac, 0x0, 0xf6bcb000, 0xf6bca000, 0xf6bcc000) kernel .text 0xc0100000 0xc014a040 0xc014a344 0xf78b1f00 0xc014a50b do_kern_mount+0x57 (0xf6bcc000, 0x1, 0xf6bcb000, 0xf6bca000, 0x1) kernel .text 0xc0100000 0xc014a4b4 0xc014a5b4 0xf78b1f34 0xc015f819 do_add_mount+0x6d (0xf78b1f68, 0xf6bcc000, 0x1, 0x0, 0xf6bcb000) kernel .text 0xc0100000 0xc015f7ac 0xc015f8fc 0xf78b1f84 0xc015fae0 do_mount+0x140 (0xf6bcb000, 0xf78d7000, 0xf6bcc000, 0xc0ed0001, 0xf6bca000) kernel .text 0xc0100000 0xc015f9a0 0xc015fafc 0xf78b1fbc 0xc01600c8 sys_mount+0xd4 (0x8058e18, 0x8058e28, 0x8055366, 0xc0ed0001, 0x8058e58) kernel .text 0xc0100000 0xc015fff4 0xc0160154 0xc0109353 system_call+0x33 kernel .text 0xc0100000 0xc0109320 0xc0109358 [0]kdb> --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfs_logprint.out" xfs_logprint version 2.3.3 xfs_logprint: data device: 0x900 log device: 0x900 daddr: 1602224256 length: 262144 cycle: 190 version: 1 lsn: 190,224344 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224345 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224346 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224347 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224348 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224349 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224350 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224351 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224352 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224353 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224354 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224355 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224356 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224357 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224358 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224359 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224360 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224361 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224362 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224363 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224364 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224365 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224366 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224367 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224368 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224369 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224370 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224371 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224372 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224373 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224374 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224375 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224376 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224377 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224378 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224379 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224380 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224381 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224382 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224383 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224384 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224385 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224386 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224387 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224388 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224389 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224390 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224391 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224392 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224393 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224394 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224395 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224396 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224397 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224398 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224399 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224400 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224401 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224402 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224403 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224404 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224405 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224406 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224407 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224408 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224409 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224410 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224411 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224412 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224413 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224414 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224415 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224416 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224417 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224418 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224419 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224420 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224421 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224422 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224423 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224424 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224425 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224426 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224427 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224428 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224429 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224430 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224431 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224432 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224433 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224434 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224435 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224436 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224437 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224438 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224439 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224440 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224441 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224442 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224443 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224444 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224445 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224446 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224447 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224448 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224449 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224450 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224451 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224452 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224453 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224454 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224455 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224456 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224457 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224458 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224459 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224460 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224461 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224462 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224463 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224464 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224465 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224466 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224467 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224468 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224469 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224470 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224471 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224472 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224473 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224474 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224475 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224476 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224477 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224478 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224479 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224480 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224481 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224482 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224483 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224484 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224485 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224486 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224487 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224488 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224489 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224490 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224491 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224492 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224493 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224494 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224495 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224496 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224497 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224498 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224499 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224500 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224501 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224502 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224503 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224504 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224505 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224506 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224507 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224508 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224509 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224510 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224511 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224512 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224513 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224514 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224515 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224516 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224517 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224518 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224519 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224520 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224521 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224522 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224523 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224524 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224525 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224526 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224527 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224528 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224529 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224530 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224531 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224532 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224533 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224534 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224535 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224536 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224537 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224538 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224539 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224540 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224541 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224542 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224543 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224544 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224545 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224546 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224547 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224548 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224549 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224550 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224551 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224552 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224553 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224554 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224555 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224556 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224557 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224558 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224559 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224560 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224561 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224562 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224563 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224564 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224565 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224566 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224567 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224568 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224569 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224570 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224571 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224572 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224573 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224574 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224575 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224576 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224577 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224578 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224579 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224580 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224581 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224582 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224583 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224584 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224585 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224586 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224587 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224588 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224589 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224590 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224591 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224592 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224593 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224594 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224595 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224596 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224597 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224598 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224599 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224600 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224601 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224602 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224603 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224604 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224605 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224606 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224607 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224608 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224609 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224610 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224611 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224612 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224613 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224614 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224615 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224616 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224617 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224618 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224619 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224620 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224621 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224622 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224623 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224624 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224625 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224626 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224627 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224628 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224629 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224630 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224631 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224632 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224633 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224634 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224635 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224636 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224637 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224638 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224639 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224640 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224641 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224642 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224643 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224644 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224645 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224646 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224647 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224648 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224649 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224650 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224651 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224652 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224653 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224654 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224655 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224656 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224657 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224658 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224659 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224660 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224661 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224662 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224663 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224664 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224665 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224666 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224667 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224668 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224669 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224670 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224671 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224672 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224673 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224674 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224675 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224676 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224677 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224678 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224679 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224680 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224681 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224682 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224683 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224684 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224685 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224686 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224687 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224688 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224689 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224690 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224691 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224692 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224693 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224694 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224695 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224696 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224697 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224698 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224699 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224700 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224701 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224702 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224703 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224704 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224705 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224706 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224707 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224708 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224709 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224710 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224711 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224712 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224713 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224714 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224715 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224716 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224717 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224718 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224719 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224720 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224721 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224722 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224723 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224724 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224725 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224726 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224727 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224728 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224729 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224730 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224731 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224732 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224733 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224734 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224735 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224736 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224737 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224738 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224739 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224740 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224741 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224742 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224743 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224744 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224745 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224746 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224747 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224748 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224749 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224750 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224751 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224752 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224753 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224754 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224755 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224756 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224757 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224758 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224759 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224760 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224761 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224762 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224763 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224764 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224765 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224766 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224767 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224768 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224769 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224770 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224771 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224772 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224773 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224774 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224775 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224776 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224777 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224778 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224779 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224780 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224781 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224782 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224783 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224784 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224785 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224786 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224787 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224788 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224789 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224790 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224791 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224792 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224793 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224794 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224795 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224796 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224797 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224798 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224799 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224800 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224801 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224802 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224803 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224804 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224805 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224806 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224807 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224808 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224809 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224810 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224811 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224812 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224813 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224814 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224815 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224816 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224817 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224818 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224819 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224820 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224821 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224822 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224823 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224824 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224825 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224826 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224827 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224828 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224829 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224830 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224831 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224832 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224833 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224834 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224835 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224836 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224837 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224838 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224839 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224840 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224841 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224842 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224843 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224844 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224845 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224846 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224847 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224848 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224849 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224850 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224851 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224852 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224853 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224854 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 190 version: 1 lsn: 190,224855 tail_lsn: 191,221728 length of Log Record: 0 prev offset: 0 num ops: 0 uuid: 00000000-0000-0000-0000-000000000000 format: unknown ============================================================================ cycle: 1073744000 version: 391417 lsn: 387108,1073965118 tail_lsn : 2152921482,1073964549 length of Log Record: 1073742954 prev offset: 1075053603 num ops: -155887980 uuid: 4e4c039c-4213-1729-7504-e2522710142e format: ? (687867997) Out of Memory: Killed process 801 (xfs_logprint). --mP3DRpeJDSE+ciuQ-- From owner-linux-xfs@oss.sgi.com Mon Sep 23 06:33:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 06:34: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 g8NDXttG023839 for ; Mon, 23 Sep 2002 06:33: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 IAA00317 for ; Mon, 23 Sep 2002 08:33:50 -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 IAA33264 for ; Mon, 23 Sep 2002 08:33:48 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8NKmeC20027 for linux-xfs@oss.sgi.com; Mon, 23 Sep 2002 16:48:40 -0400 Resent-Message-Id: <200209232048.g8NKmeC20027@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 IAA92729 for ; Mon, 23 Sep 2002 08:31:11 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8NKk2F19490 for hch@sgi.com; Mon, 23 Sep 2002 16:46:02 -0400 Date: Mon, 23 Sep 2002 16:46:02 -0400 From: Christoph Hellwig Message-Id: <200209232046.g8NKk2F19490@dhcp212.munich.sgi.com> Subject: TAKE - More mount code cleanups Resent-Date: Mon, 23 Sep 2002 16:48:40 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 551 X-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: Mon Sep 23 06:30:20 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:128159a linux/fs/xfs/xfs_vfsops.c - 1.383 - - move setting the blocksize on rt and log subvolume back into xfs_cmountfs - make xfs_start_flags/xfs_finish_flags static and sanitize agruments - on Linux the ap pointer can't be NULL as there is no mountroot VFSOP. From owner-linux-xfs@oss.sgi.com Mon Sep 23 07:00:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 07:00:30 -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 g8NE0OtG026301 for ; Mon, 23 Sep 2002 07:00:24 -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 JAA03557 for ; Mon, 23 Sep 2002 09:00:19 -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 JAA67624 for ; Mon, 23 Sep 2002 09:00:18 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8NLFAM23799 for linux-xfs@oss.sgi.com; Mon, 23 Sep 2002 17:15:10 -0400 Resent-Message-Id: <200209232115.g8NLFAM23799@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 IAA92073 for ; Mon, 23 Sep 2002 08:59:35 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8NLERP23787 for hch@sgi.com; Mon, 23 Sep 2002 17:14:27 -0400 Date: Mon, 23 Sep 2002 17:14:27 -0400 From: Christoph Hellwig Message-Id: <200209232114.g8NLERP23787@dhcp212.munich.sgi.com> Subject: TAKE - Remove XFS defconfig entries Resent-Date: Mon, 23 Sep 2002 17:15:10 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 552 X-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 The mainline architecture maintainers will re-add them in the proper place once they regenerate their default configs. I've kept the kdb entries on i386 and ia64 for now. Date: Mon Sep 23 06:57:16 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128161a linux/arch/sparc64/defconfig - 1.77 linux/arch/sparc/defconfig - 1.35 linux/arch/ppc/defconfig - 1.44 linux/arch/mips/defconfig - 1.24 linux/arch/m68k/defconfig - 1.14 linux/arch/i386/defconfig - 1.112 linux/arch/arm/defconfig - 1.22 linux/arch/alpha/defconfig - 1.31 linux/arch/sh/defconfig - 1.22 linux/arch/ppc/configs/walnut_defconfig - 1.19 linux/arch/ppc/configs/oak_defconfig - 1.19 linux/arch/ppc/configs/mbx_defconfig - 1.14 linux/arch/ppc/configs/gemini_defconfig - 1.21 linux/arch/ppc/configs/common_defconfig - 1.31 linux/arch/ppc/configs/apus_defconfig - 1.17 linux/arch/ia64/defconfig - 1.20 linux/arch/mips64/defconfig - 1.20 linux/arch/s390/defconfig - 1.13 linux/arch/ppc/configs/rpxlite_defconfig - 1.14 linux/arch/ppc/configs/rpxcllf_defconfig - 1.15 linux/arch/ppc/configs/est8260_defconfig - 1.16 linux/arch/ppc/configs/bseip_defconfig - 1.14 linux/arch/parisc/defconfig - 1.7 linux/arch/ppc/configs/power3_defconfig - 1.12 linux/arch/ppc/configs/ibmchrp_defconfig - 1.12 linux/arch/cris/defconfig - 1.13 linux/arch/s390x/defconfig - 1.12 linux/arch/ppc/configs/TQM860L_defconfig - 1.14 linux/arch/ppc/configs/TQM850L_defconfig - 1.12 linux/arch/ppc/configs/TQM823L_defconfig - 1.12 linux/arch/ppc/configs/SPD823TS_defconfig - 1.12 linux/arch/ppc/configs/SM850_defconfig - 1.12 linux/arch/ppc/configs/IVMS8_defconfig - 1.14 - remove XFS entries From owner-linux-xfs@oss.sgi.com Mon Sep 23 08:12:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 08:12: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 g8NFCmtG029798 for ; Mon, 23 Sep 2002 08:12:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA02980; Mon, 23 Sep 2002 10:12:42 -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 KAA60116; Mon, 23 Sep 2002 10:12:42 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8NF8EN18903; Mon, 23 Sep 2002 10:08:14 -0500 Subject: Re: Antwort: Re: xfs-patch on kernel 2-4-19 From: Steve Lord To: christian_binder@t-online.de Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 23 Sep 2002 10:08:14 -0500 Message-Id: <1032793694.18592.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 553 X-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 Sun, 2002-09-22 at 15:17, Eric Sandeen wrote: > On Sun, 22 Sep 2002 christian_binder@t-online.de wrote: > > > I do the same at the ide1(22,3) and mounted it, but there was only the > > "lost+found" directory with many "lost+found" files. > > Well, I guess I should have thought of this sooner. Since your root > directory was in trouble, -everything- wound up in lost+found when > you ran xfs_repair. > > So, you have probably not lost your files, but you did lose your file names... > > At this point, I think you'll just have to sort through lost+found and > see what you can recognize. > > -Eric > You should only have lost names in the root directory, they would be replaced by inode numbers. After that, the directories should have the correct contents. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Sep 23 08:33:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 08:33:12 -0700 (PDT) Received: from VSCANMAIL (vscanmail.ukl.uni-freiburg.de [193.196.199.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8NFX8tG001454 for ; Mon, 23 Sep 2002 08:33:09 -0700 Received: FROM msm10.ukl.uni-freiburg.de BY VSCANMAIL ; Mon Sep 23 17:32:22 2002 +0200 Received: from GW-DOM-MTA by msm10.ukl.uni-freiburg.de with Novell_GroupWise; Mon, 23 Sep 2002 17:33:06 +0200 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0.1 Date: Mon, 23 Sep 2002 17:32:37 +0200 From: "Manfred Baumstark" To: , Subject: Antw: Can Windows read XFS? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 554 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Manfred.Baumstark@msm10.ukl.uni-freiburg.de Precedence: bulk X-list: linux-xfs Possibly using VMware could solve your problem. You could run windows within a virtual VMware mashine on the Linux host. The later exports the XFS filesystem via samba which you can map without problems from the windows computer. Manfred >>> 17.09.2002 21:03 >>> I've unsuccessfully checked the archives for the answer to the above question. Are there any programs that allow Windows NT/2k/XP systems to read XFS filesystem data? I have a dual-boot XP/Linux system with the /home partition formatted XFS. From owner-linux-xfs@oss.sgi.com Mon Sep 23 08:38:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 08:38:17 -0700 (PDT) Received: from notes.guilford.edu ([192.154.63.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8NFcEtG001917 for ; Mon, 23 Sep 2002 08:38:15 -0700 Subject: Re: Antw: Can Windows read XFS? To: "Manfred Baumstark" Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: vricks@guilford.edu Date: Mon, 23 Sep 2002 11:37:53 -0400 X-MIMETrack: Serialize by Router on notes.guilford.edu/Guilford(Release 5.0.10 |March 22, 2002) at 09/23/2002 11:38:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 555 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vricks@guilford.edu Precedence: bulk X-list: linux-xfs Thanks, everyone, for the prompt replies. I think that I'll either just live with the situation, or else reformat my /home partition to ext2 or ext3. There are Windows programs I'm aware of that can read ext2/3 filesystems. VMware is great, but I don't have a real excuse for using it. Thanks again, Vance "Manfred Baumstark" , reiburg.de> cc: Subject: Antw: Can Windows read XFS? 09/23/02 11:32 AM Possibly using VMware could solve your problem. You could run windows within a virtual VMware mashine on the Linux host. The later exports the XFS filesystem via samba which you can map without problems from the windows computer. Manfred >>> 17.09.2002 21:03 >>> I've unsuccessfully checked the archives for the answer to the above question. Are there any programs that allow Windows NT/2k/XP systems to read XFS filesystem data? I have a dual-boot XP/Linux system with the /home partition formatted XFS. From owner-linux-xfs@oss.sgi.com Mon Sep 23 08:42:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 08:42: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 g8NFg2tG002387 for ; Mon, 23 Sep 2002 08:42:03 -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 KAA99461 for ; Mon, 23 Sep 2002 10:41:57 -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 KAA44852 for ; Mon, 23 Sep 2002 10:41:56 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8NMumS30569 for linux-xfs@oss.sgi.com; Mon, 23 Sep 2002 18:56:48 -0400 Resent-Message-Id: <200209232256.g8NMumS30569@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 KAA06557 for ; Mon, 23 Sep 2002 10:41:20 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8NMuCT30518 for hch@sgi.com; Mon, 23 Sep 2002 18:56:12 -0400 Date: Mon, 23 Sep 2002 18:56:12 -0400 From: Christoph Hellwig Message-Id: <200209232256.g8NMuCT30518@dhcp212.munich.sgi.com> Subject: TAKE - Remove leftover from old Posix ACL code Resent-Date: Mon, 23 Sep 2002 18:56:48 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 556 X-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: Mon Sep 23 08:40:25 PDT 2002 Workarea: dhcp212.munich.sgi.com:/home/hch/repo/ptools/linux-2.5-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128168a linux/include/linux/fs.h - 1.192 - Remove dead S_POSIXACL flag From owner-linux-xfs@oss.sgi.com Mon Sep 23 10:48:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 10:48: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 g8NHmetG009663 for ; Mon, 23 Sep 2002 10:48:40 -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 MAA05452 for ; Mon, 23 Sep 2002 12:48:34 -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 MAA74517 for ; Mon, 23 Sep 2002 12:48:33 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8O13PL31392 for linux-xfs@oss.sgi.com; Mon, 23 Sep 2002 21:03:25 -0400 Resent-Message-Id: <200209240103.g8O13PL31392@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 MAA32984 for ; Mon, 23 Sep 2002 12:47:50 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8O12gP31308 for hch@sgi.com; Mon, 23 Sep 2002 21:02:42 -0400 Date: Mon, 23 Sep 2002 21:02:42 -0400 From: Christoph Hellwig Message-Id: <200209240102.g8O12gP31308@dhcp212.munich.sgi.com> Subject: TAKE - Fix the mount-cleanup for single-subvolume filesystems. Resent-Date: Mon, 23 Sep 2002 21:03:25 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 557 X-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: Mon Sep 23 10:47:17 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:128192a linux/fs/xfs/xfs_vfsops.c - 1.384 - Remove bogus checks for non-null and separate logvolume From owner-linux-xfs@oss.sgi.com Mon Sep 23 12:04:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 12:04:07 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8NJ3xtG012301 for ; Mon, 23 Sep 2002 12:04: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 OAA06028 for ; Mon, 23 Sep 2002 14:03:53 -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 OAA82175 for ; Mon, 23 Sep 2002 14:03:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8NIxHB32669; Mon, 23 Sep 2002 13:59:17 -0500 Message-Id: <200209231859.g8NIxHB32669@jen.americas.sgi.com> Date: Mon, 23 Sep 2002 13:59:17 -0500 Subject: TAKE - Merge kernel up to 2.5.38 To: linux-xfs@oss.sgi.com X-archive-position: 558 X-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 easier. Date: Mon Sep 23 11:58:56 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:128200a linux/arch/ia64/lib/carta_random.S - 1.1 linux/arch/ia64/pci/pci.c - 1.1 linux/arch/ia64/mm/hugetlbpage.c - 1.1 linux/arch/ia64/pci/Makefile - 1.1 linux/fs/ncpfs/getopt.c - 1.1 linux/fs/ncpfs/getopt.h - 1.1 linux/include/asm-ia64/suspend.h - 1.1 linux/net/irda/irlan/irlan_common.c - 1.20 linux/net/irda/irlan/irlan_client_event.c - 1.7 linux/net/irda/irlan/irlan_client.c - 1.12 linux/net/irda/af_irda.c - 1.40 linux/kernel/sys.c - 1.41 linux/kernel/sched.c - 1.82 linux/kernel/ksyms.c - 1.166 linux/include/linux/ncp_mount.h - 1.6 linux/include/linux/ncp_fs_sb.h - 1.8 linux/include/linux/ncp.h - 1.5 linux/include/linux/nbd.h - 1.17 linux/include/linux/genhd.h - 1.24 linux/include/linux/cdrom.h - 1.23 linux/fs/ncpfs/sock.c - 1.13 linux/fs/ncpfs/ncpsign_kernel.h - 1.4 linux/fs/ncpfs/ncpsign_kernel.c - 1.5 linux/fs/ncpfs/ncplib_kernel.c - 1.13 linux/fs/ncpfs/ioctl.c - 1.18 linux/fs/ncpfs/inode.c - 1.37 linux/fs/ncpfs/Makefile - 1.6 linux/fs/block_dev.c - 1.61 linux/drivers/scsi/sr_ioctl.c - 1.27 linux/drivers/scsi/sr.c - 1.51 linux/drivers/scsi/sd.c - 1.70 linux/drivers/net/irda/irtty.c - 1.30 linux/drivers/net/irda/actisys.c - 1.12 linux/drivers/cdrom/sonycd535.c - 1.27 linux/drivers/cdrom/sjcd.c - 1.21 linux/drivers/cdrom/sbpcd.c - 1.28 linux/drivers/cdrom/optcd.c - 1.22 linux/drivers/cdrom/mcdx.c - 1.19 linux/drivers/cdrom/mcd.c - 1.21 linux/drivers/cdrom/gscd.c - 1.21 linux/drivers/cdrom/cm206.c - 1.23 linux/drivers/cdrom/cdu31a.c - 1.21 linux/drivers/cdrom/cdrom.c - 1.47 linux/drivers/cdrom/aztcd.c - 1.24 linux/drivers/block/xd.c - 1.44 linux/drivers/block/swim3.c - 1.20 linux/drivers/block/rd.c - 1.59 linux/drivers/block/ps2esdi.c - 1.46 linux/drivers/block/paride/pf.c - 1.28 linux/drivers/block/paride/pd.c - 1.36 linux/drivers/block/paride/pcd.c - 1.24 linux/drivers/block/nbd.c - 1.43 linux/drivers/block/loop.c - 1.66 linux/drivers/block/genhd.c - 1.33 linux/drivers/block/floppy.c - 1.50 linux/drivers/block/acsi.c - 1.37 linux/drivers/acorn/block/mfmhd.c - 1.30 linux/drivers/acorn/block/fd1772.c - 1.20 linux/arch/m68k/atari/stram.c - 1.18 linux/arch/i386/kernel/vm86.c - 1.18 linux/Makefile - 1.219 linux/include/linux/ide.h - 1.65 linux/include/linux/blkpg.h - 1.3 linux/drivers/block/cpqarray.c - 1.56 linux/fs/partitions/check.c - 1.52 linux/drivers/block/DAC960.c - 1.55 linux/net/irda/ircomm/ircomm_tty_ioctl.c - 1.9 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.11 linux/net/irda/ircomm/ircomm_tty.c - 1.22 linux/net/irda/ircomm/ircomm_ttp.c - 1.6 linux/net/irda/ircomm/ircomm_param.c - 1.10 linux/net/irda/ircomm/ircomm_lmp.c - 1.8 linux/net/irda/ircomm/ircomm_core.c - 1.17 linux/drivers/block/swim_iop.c - 1.15 linux/fs/udf/lowlevel.c - 1.11 linux/mm/numa.c - 1.14 linux/drivers/sbus/char/jsflash.c - 1.22 linux/drivers/net/irda/nsc-ircc.c - 1.24 linux/arch/ia64/kernel/head.S - 1.12 linux/arch/ia64/kernel/semaphore.c - 1.9 linux/arch/ia64/kernel/gate.S - 1.12 linux/arch/ia64/kernel/entry.S - 1.30 linux/arch/ia64/kernel/efi.c - 1.18 linux/arch/ia64/kernel/acpi.c - 1.17 linux/arch/ia64/kernel/Makefile - 1.15 linux/arch/ia64/ia32/sys_ia32.c - 1.30 linux/arch/ia64/hp/Makefile - 1.6 linux/arch/ia64/tools/print_offsets.c - 1.14 linux/arch/ia64/config.in - 1.36 linux/arch/ia64/Makefile - 1.20 linux/arch/ia64/tools/print_offsets.awk - 1.7 linux/arch/ia64/kernel/init_task.c - 1.6 linux/arch/ia64/kernel/irq.c - 1.23 linux/arch/ia64/kernel/signal.c - 1.18 linux/arch/ia64/kernel/sys_ia64.c - 1.14 linux/arch/ia64/kernel/time.c - 1.16 linux/arch/ia64/lib/Makefile - 1.15 linux/arch/ia64/kernel/ivt.S - 1.18 linux/arch/ia64/kernel/pci.c - 1.16 linux/arch/ia64/kernel/ptrace.c - 1.17 linux/arch/ia64/kernel/process.c - 1.20 linux/arch/ia64/kernel/perfmon.c - 1.17 linux/arch/ia64/mm/tlb.c - 1.14 linux/arch/ia64/kernel/mca.c - 1.14 linux/arch/ia64/mm/init.c - 1.21 linux/arch/ia64/mm/Makefile - 1.3 linux/arch/ia64/kernel/pal.S - 1.9 linux/include/asm-ia64/ide.h - 1.13 linux/include/asm-ia64/hardirq.h - 1.16 linux/include/asm-ia64/siginfo.h - 1.15 linux/include/linux/raid/md_k.h - 1.27 linux/include/asm-ia64/sal.h - 1.12 linux/include/asm-ia64/processor.h - 1.25 linux/include/linux/raid/md.h - 1.19 linux/include/asm-ia64/machvec.h - 1.11 linux/include/asm-ia64/machvec_dig.h - 1.4 linux/include/asm-ia64/machvec_hpsim.h - 1.4 linux/include/asm-ia64/pal.h - 1.10 linux/include/asm-ia64/page.h - 1.16 linux/include/asm-ia64/machvec_sn1.h - 1.6 linux/include/asm-ia64/mmu_context.h - 1.10 linux/include/asm-ia64/spinlock.h - 1.10 linux/include/asm-ia64/unistd.h - 1.24 linux/include/asm-ia64/signal.h - 1.7 linux/include/asm-ia64/rse.h - 1.2 linux/include/asm-ia64/timex.h - 1.3 linux/include/asm-ia64/system.h - 1.19 linux/drivers/ide/ide.c - 1.68 linux/drivers/ide/ide-probe.c - 1.39 linux/drivers/ide/ide-floppy.c - 1.36 linux/drivers/ide/ide-disk.c - 1.48 linux/drivers/ide/ide-cd.c - 1.48 linux/arch/ia64/kernel/smpboot.c - 1.14 linux/arch/ia64/kernel/ia64_ksyms.c - 1.16 linux/drivers/mtd/ftl.c - 1.23 linux/drivers/mtd/mtdblock.c - 1.21 linux/drivers/block/cciss.c - 1.43 linux/drivers/md/md.c - 1.56 linux/arch/ia64/kernel/iosapic.c - 1.12 linux/drivers/s390/block/xpram.c - 1.24 linux/include/asm-ia64/perfmon.h - 1.6 linux/drivers/net/irda/irda-usb.c - 1.23 linux/include/linux/mii.h - 1.5 linux/drivers/mtd/nftlcore.c - 1.23 linux/drivers/mtd/mtdblock_ro.c - 1.12 linux/include/asm-ia64/tlb.h - 1.6 linux/drivers/message/i2o/i2o_block.c - 1.21 linux/drivers/net/8139cp.c - 1.20 linux/drivers/net/wireless/wavelan_cs.c - 1.7 linux/drivers/net/wireless/wavelan_cs.p.h - 1.4 linux/drivers/net/mii.c - 1.4 linux/drivers/pci/pci-driver.c - 1.10 linux/fs/jfs/file.c - 1.12 linux/fs/jfs/jfs_dmap.c - 1.9 linux/fs/jfs/jfs_dmap.h - 1.4 linux/fs/jfs/jfs_extent.c - 1.6 linux/fs/jfs/jfs_incore.h - 1.11 linux/fs/jfs/jfs_imap.c - 1.9 linux/fs/jfs/jfs_logmgr.c - 1.18 linux/fs/jfs/super.c - 1.15 linux/fs/jfs/jfs_txnmgr.c - 1.16 linux/include/asm-ia64/machvec_sn2.h - 1.2 linux/include/asm-ia64/machvec_hpzx1.h - 1.3 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.6 linux/arch/ia64/hp/zx1/Makefile - 1.3 linux/arch/ia64/hp/common/Makefile - 1.3 linux/arch/ia64/hp/common/sba_iommu.c - 1.6 linux/drivers/block/umem.c - 1.9 linux/drivers/acpi/pci_bind.c - 1.3 linux/drivers/acpi/ac.c - 1.5 linux/drivers/acpi/battery.c - 1.6 linux/drivers/acpi/fan.c - 1.4 linux/drivers/acpi/button.c - 1.5 linux/drivers/acpi/thermal.c - 1.6 linux/drivers/acpi/processor.c - 1.7 linux/drivers/s390/block/dasd_genhd.c - 1.6 linux/drivers/net/irda/ma600.c - 1.2 linux/fs/jfs/xattr.c - 1.4 linux/drivers/acpi/numa.c - 1.3 linux/drivers/ide/setup-pci.c - 1.3 linux/drivers/ide/pci/cy82c693.c - 1.3 linux/drivers/ide/legacy/hd.c - 1.4 From owner-linux-xfs@oss.sgi.com Mon Sep 23 14:38:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 14:38:27 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8NLcMtG016333 for ; Mon, 23 Sep 2002 14:38:22 -0700 Received: (qmail 26230 invoked by uid 500); 23 Sep 2002 21:38:02 -0000 Subject: Re: Antwort: Re: xfs-patch on kernel 2-4-19 From: Austin Gonyou To: Eric Sandeen Cc: christian_binder@t-online.de, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032817082.26137.8.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 23 Sep 2002 16:38:02 -0500 X-archive-position: 559 X-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 Yikes!!!! Ouch. Sorry, I very much apologize. I didn't realize it was your root! :( I guess I should've mentioned that a real repair action involving files and inodes would result in a lot of files ending up in lost+found. BTW, you using v1 logs? On Sun, 2002-09-22 at 15:17, Eric Sandeen wrote: > On Sun, 22 Sep 2002 christian_binder@t-online.de wrote: > > > I do the same at the ide1(22,3) and mounted it, but there was only > the > > "lost+found" directory with many "lost+found" files. > > Well, I guess I should have thought of this sooner. Since your root > directory was in trouble, -everything- wound up in lost+found when > you ran xfs_repair. > > So, you have probably not lost your files, but you did lose your file > names... > > At this point, I think you'll just have to sort through lost+found and > see what you can recognize. > > -Eric -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 23 15:05:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 15:05: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 g8NM5atG017084 for ; Mon, 23 Sep 2002 15:05:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA21992 for ; Mon, 23 Sep 2002 17:05:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id RAA50439 for ; Mon, 23 Sep 2002 17:05:30 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8NM0sE02893; Mon, 23 Sep 2002 17:00:54 -0500 Message-Id: <200209232200.g8NM0sE02893@jen.americas.sgi.com> Date: Mon, 23 Sep 2002 17:00:54 -0500 Subject: TAKE - cleanup xfs_fsync code To: linux-xfs@oss.sgi.com X-archive-position: 560 X-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 Fold some code paths together in the xfs fsync implementation. Code inspection revealed two large chunks of code on different sides of an if which were identical except for one line. Date: Mon Sep 23 15:04:49 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:128239a linux/fs/xfs/xfs_vnodeops.c - 1.565 - fold together the if and else cases for syncing an inode to disk using a transaction. They were identical except for one line. From owner-linux-xfs@oss.sgi.com Mon Sep 23 17:49:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Sep 2002 17:49:34 -0700 (PDT) Received: from picasso.animezone.org (CPE3236333133323237.cpe.net.cable.rogers.com [24.100.159.193] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8O0nRtG031694 for ; Mon, 23 Sep 2002 17:49:28 -0700 Received: from animezone.org (localhost [127.0.0.1]) by picasso.animezone.org (8.11.6/8.11.6) with ESMTP id g8O0qLx03758 for ; Mon, 23 Sep 2002 20:52:22 -0400 Message-ID: <3D8FB744.15ECD2E7@animezone.org> Date: Mon, 23 Sep 2002 20:52:20 -0400 From: Andrew Ho X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-xfs-lvm1.0.5 i686) X-Accept-Language: en, zh-TW MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Mail Test Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 561 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: andrewho@animezone.org Precedence: bulk X-list: linux-xfs From owner-linux-xfs@oss.sgi.com Tue Sep 24 10:40:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 10:41: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 g8OHestG023164 for ; Tue, 24 Sep 2002 10:40:55 -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 DAA30256; Wed, 25 Sep 2002 03:21:58 +0930 Message-ID: <3D90A689.BADD6032@rebel.net.au> Date: Wed, 25 Sep 2002 03:23:13 +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: vricks@guilford.edu CC: Manfred Baumstark , linux-xfs@oss.sgi.com Subject: Re: Antw: Can Windows read XFS? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 562 X-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.... > filesystems. VMware is great, but I don't have a real excuse for using it. Apart from being able to read your files stored on it... DSL -- I reniad lin ne mor, nuithannen In gwidh ristennin, i fae narchannen I lach Anor ed ardhon gwannen (Soundtrack LOTR) From owner-linux-xfs@oss.sgi.com Tue Sep 24 11:32:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 11:32: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 g8OIWqtG024049 for ; Tue, 24 Sep 2002 11:32:52 -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 NAA53364 for ; Tue, 24 Sep 2002 13:32:46 -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 NAA33490 for ; Tue, 24 Sep 2002 13:32:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8OIS1e11799; Tue, 24 Sep 2002 13:28:01 -0500 Message-Id: <200209241828.g8OIS1e11799@jen.americas.sgi.com> Date: Tue, 24 Sep 2002 13:28:01 -0500 Subject: TAKE - Fix kdb serial input To: linux-xfs@oss.sgi.com X-archive-position: 563 X-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 Finally fix up 2.5 kdb so it can accept input on the serial console. This has been broken for quite a while. Date: Tue Sep 24 11:31:22 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:128293a linux/arch/i386/kdb/kdba_io.c - 1.18 - rework the use of config defines a little, we were using the wrong one. linux/drivers/serial/8250.c - 1.4 - do not stop at the first setup call in setting up kdb console info, there is insufficient data in the structure first time through. From owner-linux-xfs@oss.sgi.com Tue Sep 24 14:39:43 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 14:39:47 -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 g8OLdhtG031575 for ; Tue, 24 Sep 2002 14:39: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 QAA48663 for ; Tue, 24 Sep 2002 16:39:37 -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 QAA89193 for ; Tue, 24 Sep 2002 16:39:37 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8OLdZ418977; Tue, 24 Sep 2002 16:39:35 -0500 Message-Id: <200209242139.g8OLdZ418977@stout.americas.sgi.com> Date: Tue, 24 Sep 2002 16:39:35 -0500 Subject: TAKE - Add buffer to inode's dirty list after truncate() X-archive-position: 564 X-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 block_truncate_page() does a __mark_buffer_dirty(bh) at the end, but it does not file the buffer on the inode's dirty data queue, so only bdflush can ever get to it, and other sync mechanisms which call fsync_inode_data_buffers() do not see it. This was the root cause of the mapcheck program failing on fsr'd files, it found data past EOF as a result of the failed sync after truncate. This one seems to have the Kernel Gods' blessings, and will hopefully be in 2.4.20. It should not be necessary for 2.5.x, the problem does not seem to exist there. Add buffer to inode's dirty list after truncate() Date: Tue Sep 24 14:36:23 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:128332a linux/fs/buffer.c - 1.110 - Add buffer to inode's dirty list after truncate() From owner-linux-xfs@oss.sgi.com Tue Sep 24 15:11:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 15:11:24 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8OMBLtG032253 for ; Tue, 24 Sep 2002 15:11:21 -0700 Received: (qmail 30467 invoked by uid 500); 24 Sep 2002 22:10:57 -0000 Subject: Re: Antw: Can Windows read XFS? From: Austin Gonyou To: David Lloyd Cc: vricks@guilford.edu, Manfred Baumstark , linux-xfs@oss.sgi.com In-Reply-To: <3D90A689.BADD6032@rebel.net.au> References: <3D90A689.BADD6032@rebel.net.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032905457.28510.7.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 24 Sep 2002 17:10:57 -0500 X-archive-position: 565 X-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 Been quiet on this but...why use windows at all? Can't one of the Codeweaver's products help you, or perhaps winex? On Tue, 2002-09-24 at 12:53, David Lloyd wrote: > Hmmm.... > > > filesystems. VMware is great, but I don't have a real excuse for > using it. > > Apart from being able to read your files stored on it... > > DSL > -- > I reniad lin ne mor, nuithannen > In gwidh ristennin, i fae narchannen > I lach Anor ed ardhon gwannen > (Soundtrack LOTR) -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 24 15:23:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 15:23:40 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8OMNatG032756 for ; Tue, 24 Sep 2002 15:23:36 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 1FA0D1EFDD; Tue, 24 Sep 2002 15:23:36 -0700 (PDT) Date: Tue, 24 Sep 2002 15:23:36 -0700 From: Chris Wedgwood To: Austin Gonyou Cc: David Lloyd , vricks@guilford.edu, Manfred Baumstark , linux-xfs@oss.sgi.com Subject: Re: Antw: Can Windows read XFS? Message-ID: <20020924222336.GA23091@tapu.f00f.org> References: <3D90A689.BADD6032@rebel.net.au> <1032905457.28510.7.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032905457.28510.7.camel@UberGeek.coremetrics.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 566 X-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 24, 2002 at 05:10:57PM -0500, Austin Gonyou wrote: > Been quiet on this but...why use windows at all? Can't one of the > Codeweaver's products help you, or perhaps winex? That really isn't the issue. At present, there is no support for XFS under Windows. People who *need* to access non-windows filesystems under Windows should probably not use XFS. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 24 15:42:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 15:42:29 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8OMgPtG000832 for ; Tue, 24 Sep 2002 15:42:26 -0700 Received: (qmail 30801 invoked by uid 500); 24 Sep 2002 22:42:06 -0000 Subject: Re: Antw: Can Windows read XFS? From: Austin Gonyou To: Chris Wedgwood Cc: David Lloyd , vricks@guilford.edu, Manfred Baumstark , linux-xfs@oss.sgi.com In-Reply-To: <20020924222336.GA23091@tapu.f00f.org> References: <20020924222336.GA23091@tapu.f00f.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032907325.28530.12.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 24 Sep 2002 17:42:06 -0500 X-archive-position: 567 X-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 Well, why would anyone need access to windows? Windows apps? Well, identify which ones you can't run on linux, then see if win4lin or vmware fits the bill. If not then I can understand the dilemma, otherwise, keep all you data, while in linux, on the VFAT partition that you share with your windows half. That way when you boot in to either OS, it's on both. On Tue, 2002-09-24 at 17:23, Chris Wedgwood wrote: > On Tue, Sep 24, 2002 at 05:10:57PM -0500, Austin Gonyou wrote: > > > Been quiet on this but...why use windows at all? Can't one of the > > Codeweaver's products help you, or perhaps winex? > > That really isn't the issue. > > At present, there is no support for XFS under Windows. People who > *need* to access non-windows filesystems under Windows should probably > not use XFS. > > > --cw -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Tue Sep 24 15:49:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 15:49: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 g8OMnctG001313 for ; Tue, 24 Sep 2002 15:49:38 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 064401010F2; Tue, 24 Sep 2002 15:49:35 -0700 (PDT) Date: Tue, 24 Sep 2002 15:49:35 -0700 From: Chris Wedgwood To: Austin Gonyou Cc: David Lloyd , vricks@guilford.edu, Manfred Baumstark , linux-xfs@oss.sgi.com Subject: Re: Antw: Can Windows read XFS? Message-ID: <20020924224935.GA23334@tapu.f00f.org> References: <20020924222336.GA23091@tapu.f00f.org> <1032907325.28530.12.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032907325.28530.12.camel@UberGeek.coremetrics.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 568 X-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 Getting VERY off-topic... On Tue, Sep 24, 2002 at 05:42:06PM -0500, Austin Gonyou wrote: > Well, why would anyone need access to windows? I have no idea. Perhaps you should ask them? > Windows apps? Maybe, I really don't know. Maybe they like the pretty animated hourglass? > Well, identify which ones you can't run on linux, then see if > win4lin or vmware fits the bill. If not then I can understand the > dilemma, otherwise, keep all you data, while in linux, on the VFAT > partition that you share with your windows half. That way when you > boot in to either OS, it's on both. Someone asked if there was XFS access under Windows, and the answer is pretty much *NO* (without something like vmware). Whether they need to run Windows, or choose to isn't the issue for this list. Arguably, it's none of anyones business but theirs. --cw From owner-linux-xfs@oss.sgi.com Tue Sep 24 18:51:06 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 18:51:12 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8P1p6tG003867 for ; Tue, 24 Sep 2002 18:51:06 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) 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 SAA00584 for ; Tue, 24 Sep 2002 18:51:04 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA43340; Wed, 25 Sep 2002 11:49:46 +1000 (AEST) Date: Wed, 25 Sep 2002 11:49:46 +1000 From: Tim Shimmin To: Andrew Mathews Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump errors Message-ID: <20020925114946.J92301@boing.melbourne.sgi.com> References: <3D8B9C5D.9040901@linux-works.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <3D8B9C5D.9040901@linux-works.org>; from andrew_mathews@linux-works.org on Fri, Sep 20, 2002 at 04:08:29PM -0600 X-archive-position: 569 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Hi Andrew, I'll report this as an SGI bug for our xfsdump person to look at. Looking at the code, you should have received an error message as well which would output the value which made the assertion fail: mlog( MLOG_NORMAL | MLOG_INV, "INV : Unknown version %d - Expected version %d \n", (int) ( (invt_counter_t *)(*cntpp))->ic_vernum, (int) INV_VERSION ); Could you please send us this output. Also, could you run xfsdump with -v5 and send us the output. If it is a large dump then just send the output from the beginning and the end near the failure. Thanks, Tim. On Fri, Sep 20, 2002 at 04:08:29PM -0600, Andrew Mathews wrote: > I'm getting the following errors when running xfsdump on a Dell Latitude > laptop running RH 7.3, 2.4.18-4SGI_XFS_1.1, and the following xfs rpms > from oss.sgi.com: > xfsprogs-2.2.2-0 > xfsdump-2.1.5-0 > xfsprogs-devel-2.2.2-0 > attr-devel-2.0.9-0 > libattr-2.0.9-0 > attr-2.0.9-0 > dmapi-2.0.5-0 > dmapi-devel-2.0.5-0 > acl-devel-2.0.18-0 > libacl-2.0.18-0 > acl-2.0.18-0 > This is using an HP DAT24e tape drive. > > xfsdump: inv_core.c:79: get_counters: Assertion `((invt_counter_t > *)(*cntpp))->ic_vernum == (inv_version_t) 1' failed. > > I've searched the archives but not found anything relevant. > TIA- > -- > Andrew Mathews From owner-linux-xfs@oss.sgi.com Tue Sep 24 21:15:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Sep 2002 21:15: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 g8P4FmtG011413 for ; Tue, 24 Sep 2002 21:15:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA53191 for ; Tue, 24 Sep 2002 23:15:43 -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 XAA79357 for ; Tue, 24 Sep 2002 23:15:43 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g8P4FcE02036; Tue, 24 Sep 2002 23:15:38 -0500 Message-Id: <200209250415.g8P4FcE02036@stout.americas.sgi.com> Date: Tue, 24 Sep 2002 23:15:38 -0500 Subject: TAKE - Remove unused function xfs_vn_iget() X-archive-position: 570 X-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 Remove unused function xfs_vn_iget() Date: Tue Sep 24 21:15:06 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:128363a linux/fs/xfs/xfs_iget.c - 1.172 linux/fs/xfs/xfs_inode.h - 1.168 - Remove unused function xfs_vn_iget() From owner-linux-xfs@oss.sgi.com Wed Sep 25 00:50:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 00:50:07 -0700 (PDT) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8P7o1tG016173 for ; Wed, 25 Sep 2002 00:50:02 -0700 Received: from bolero.cs.tu-berlin.de (daemon@bolero.cs.tu-berlin.de [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id JAA17613 for ; Wed, 25 Sep 2002 09:45:15 +0200 (MET DST) Received: (from doko@localhost) by bolero.cs.tu-berlin.de (8.11.6+Sun/8.9.3) id g8P7jES25901; Wed, 25 Sep 2002 09:45:14 +0200 (MEST) From: Matthias Klose MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15761.27018.659158.237109@gargle.gargle.HOWL> Date: Wed, 25 Sep 2002 09:45:14 +0200 To: linux-xfs@oss.sgi.com Subject: XFS "freezes" on AMD systems X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid X-archive-position: 571 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doko@cs.tu-berlin.de Precedence: bulk X-list: linux-xfs When unpacking large tarballs or copying data bigger than 20MB on a XFS file system, the system seems to freeze for about three to five seconds, HDD LEDs always on (until all caches are synced to disk?). In this time, you cannot move the mouse, type in characters etc. I see this behaviour with 2.4.18 and 2.4.19, but only on Athlon/Duron based systems, both using IDE drives. I don't see this type of freeze on a Celeron based system. Any hints how to investigate this further? From owner-linux-xfs@oss.sgi.com Wed Sep 25 00:58:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 00:58:47 -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 g8P7witG017544 for ; Wed, 25 Sep 2002 00:58:45 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id C4AA11E113F; Wed, 25 Sep 2002 00:58:44 -0700 (PDT) Date: Wed, 25 Sep 2002 00:58:44 -0700 From: Chris Wedgwood To: Matthias Klose Cc: linux-xfs@oss.sgi.com Subject: Re: XFS "freezes" on AMD systems Message-ID: <20020925075844.GA26750@tapu.f00f.org> References: <15761.27018.659158.237109@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15761.27018.659158.237109@gargle.gargle.HOWL> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 572 X-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 25, 2002 at 09:45:14AM +0200, Matthias Klose wrote: > When unpacking large tarballs or copying data bigger than 20MB on a > XFS file system, the system seems to freeze for about three to five > seconds [...] > but only on Athlon/Duron based systems, both using IDE drives. I > don't see this type of freeze on a Celeron based system. At a guess... What IDE chipset? I would guess the chipset used on the Duran/Athlon systems isn't using DMA for IDE transfer but rather PIO. hdparm(8) may help here, or you may beed to recompile the kernel with different IDE chipset support[1]. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 25 02:27:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 02:27:24 -0700 (PDT) Received: from hammail1.truenorth.com (h-213.61.138.102.host.de.colt.net [213.61.138.102]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8P9RItG030026 for ; Wed, 25 Sep 2002 02:27:19 -0700 Received: from hamburg.fcb.com ([170.200.66.61]) by hammail1.truenorth.com (Netscape Messaging Server 4.15) with ESMTP id H2ZMER00.F54; Wed, 25 Sep 2002 11:30:27 +0200 Message-ID: <3D91D5C0.5090104@hamburg.fcb.com> Date: Wed, 25 Sep 2002 11:26:56 -0400 From: Harald Wagener Organization: FCB Wilkens User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020909 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthias Klose CC: linux-xfs@oss.sgi.com Subject: Re: XFS "freezes" on AMD systems References: <15761.27018.659158.237109@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 573 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hwagener@hamburg.fcb.com Precedence: bulk X-list: linux-xfs Matthias Klose wrote: >When unpacking large tarballs or copying data bigger than 20MB on a >XFS file system, the system seems to freeze for about three to five >seconds, HDD LEDs always on (until all caches are synced to disk?). In >this time, you cannot move the mouse, type in characters etc. I see >this behaviour with 2.4.18 and 2.4.19, but only on Athlon/Duron based >systems, both using IDE drives. I don't see this type of freeze on a >Celeron based system. > >Any hints how to investigate this further? > > > I would rather check for the IDE chipset. Is it programmed correctly? I am using an Athlon at home, and it works without any problems on XFS. (PS: This is true for RedHat 7.1; Mandrake 8.0; gentoo-1.4). Regards, Harald -- Harald Wagener*An der Alster 42*20099 Hamburg*http://www.fcb-wilkens.com From owner-linux-xfs@oss.sgi.com Wed Sep 25 06:33:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 06:33:50 -0700 (PDT) Received: from notes.guilford.edu ([192.154.63.11]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PDXltG011918 for ; Wed, 25 Sep 2002 06:33:47 -0700 Subject: Re: Antw: Can Windows read XFS? To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: vricks@guilford.edu Date: Wed, 25 Sep 2002 09:33:34 -0400 X-MIMETrack: Serialize by Router on notes.guilford.edu/Guilford(Release 5.0.10 |March 22, 2002) at 09/25/2002 09:33:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-archive-position: 574 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vricks@guilford.edu Precedence: bulk X-list: linux-xfs All right, all right, I didn't mean to start such a brouhaha. As Chris points out, my original question was answered, which is what I had hoped would happen when I asked it. Thanks again. Vance V. Ricks Assistant Professor of Philosophy Guilford College Greensboro, NC 27410 USA Chris Wedgwood To: Austin Gonyou Sent by: cc: David Lloyd , vricks@guilford.edu, Manfred linux-xfs-bounce@ Baumstark , oss.sgi.com linux-xfs@oss.sgi.com Subject: Re: Antw: Can Windows read XFS? 09/24/02 06:49 PM Getting VERY off-topic... On Tue, Sep 24, 2002 at 05:42:06PM -0500, Austin Gonyou wrote: > Well, why would anyone need access to windows? I have no idea. Perhaps you should ask them? > Windows apps? Maybe, I really don't know. Maybe they like the pretty animated hourglass? > Well, identify which ones you can't run on linux, then see if > win4lin or vmware fits the bill. If not then I can understand the > dilemma, otherwise, keep all you data, while in linux, on the VFAT > partition that you share with your windows half. That way when you > boot in to either OS, it's on both. Someone asked if there was XFS access under Windows, and the answer is pretty much *NO* (without something like vmware). Whether they need to run Windows, or choose to isn't the issue for this list. Arguably, it's none of anyones business but theirs. --cw From owner-linux-xfs@oss.sgi.com Wed Sep 25 07:39:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 07:39:26 -0700 (PDT) Received: from web40502.mail.yahoo.com (web40502.mail.yahoo.com [66.218.78.119]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PEdLtG013033 for ; Wed, 25 Sep 2002 07:39:21 -0700 Message-ID: <20020925143916.16309.qmail@web40502.mail.yahoo.com> Received: from [216.140.242.89] by web40502.mail.yahoo.com via HTTP; Wed, 25 Sep 2002 07:39:16 PDT Date: Wed, 25 Sep 2002 07:39:16 -0700 (PDT) From: Chris de Vidal Reply-To: chris@devidal.tv Subject: Upgrading from v1.0.x to 1.1.x To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 575 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cdevidal@yahoo.com Precedence: bulk X-list: linux-xfs I have a few filesystems created with a 1.0.x kernel and driver. I recently installed a kernel with 1.1.x and wanted to know if there was anything I had to do to the filesystem to upgrade it? I suppose the binary tools should be updated, too. CD __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-linux-xfs@oss.sgi.com Wed Sep 25 07:45:45 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 07:45:47 -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 g8PEjitG013530 for ; Wed, 25 Sep 2002 07:45:45 -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 JAA44753; Wed, 25 Sep 2002 09:45: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 JAA15273; Wed, 25 Sep 2002 09:45:38 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8PEeiv23744; Wed, 25 Sep 2002 09:40:44 -0500 Subject: Re: Upgrading from v1.0.x to 1.1.x From: Steve Lord To: chris@devidal.tv Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020925143916.16309.qmail@web40502.mail.yahoo.com> References: <20020925143916.16309.qmail@web40502.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Sep 2002 09:40:44 -0500 Message-Id: <1032964844.21812.50.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 576 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-25 at 09:39, Chris de Vidal wrote: > I have a few filesystems created with a 1.0.x kernel and driver. I > recently installed a kernel with 1.1.x and wanted to know if there > was anything I had to do to the filesystem to upgrade it? I suppose > the binary tools should be updated, too. > > CD Your tools should be upgraded, you do not need to do anything to the filesystem, the on disk format is not changing with releases (I suppose we should make that clear somewhere). Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 25 07:54:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 07:54:44 -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 g8PEsetG014047 for ; Wed, 25 Sep 2002 07:54:41 -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 g8PEsWlN053185; Wed, 25 Sep 2002 16:54:32 +0200 (CEST) Message-Id: <4.3.2.7.2.20020925164721.037af718@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Sep 2002 16:48:47 +0200 To: chris@devidal.tv, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Upgrading from v1.0.x to 1.1.x In-Reply-To: <20020925143916.16309.qmail@web40502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 577 X-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 07:39 25-9-2002 -0700, Chris de Vidal wrote: >I have a few filesystems created with a 1.0.x kernel and driver. I >recently installed a kernel with 1.1.x and wanted to know if there >was anything I had to do to the filesystem to upgrade it? I suppose >the binary tools should be updated, too. Yes, the 1.1 release requires => 2.0 tools. The filesystem format will not change since it must maintain compatability with Irix. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 25 09:02:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 09:03:01 -0700 (PDT) Received: from taz2.fiberhosting.com (IDENT:Jky86llQSaCUFPok2oU4oi7oKVOytUOl@KNIGHT.01.dios.net [65.222.230.112]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PG2stG002917 for ; Wed, 25 Sep 2002 09:02:54 -0700 Received: (qmail 20486 invoked by uid 2526); 25 Sep 2002 16:02:34 -0000 To: chris@devidal.tv, Chris de Vidal Subject: Re: Upgrading from v1.0.x to 1.1.x Message-ID: <1032969754.3d91de1a3a9f5@webmail.smithconcepts.com> Date: Wed, 25 Sep 2002 12:02:34 -0400 (EDT) From: "Bryan J. Smith" Cc: linux-xfs@oss.sgi.com References: <20020925143916.16309.qmail@web40502.mail.yahoo.com> In-Reply-To: <20020925143916.16309.qmail@web40502.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.7 X-Originating-IP: 208.246.35.243 X-archive-position: 578 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: b.j.smith@ieee.org Precedence: bulk X-list: linux-xfs Quoting Chris de Vidal : > I have a few filesystems created with a 1.0.x kernel and driver. I > recently installed a kernel with 1.1.x and wanted to know if there > was anything I had to do to the filesystem to upgrade it? I suppose > the binary tools should be updated, too. Only the tools need to be upgraded with the kernel. You're going to run into that with every JFS out there, so it's always a good move in general -- although be sure to _always_ read the docs that accompany both. Unlike some JFS' out there, XFS' structure remains relatively unchanged. I thank God almost everyday that SGI ported XFS from Irix -- damn sweet design in the first place. From my understanding, changes of the on-disc structure have beene few and far between in the Linux port itself. MIPS->Intel default blocksize and only a few other things if I remember correctly? So version upgrading is effortless -- at least on the same platform. -- Bryan J. Smith, E.I. Contact Info: http://thebs.org A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA --------------------------------------------------------------- limit guilt = { psychopath, remorse->0 innocent } From owner-linux-xfs@oss.sgi.com Wed Sep 25 10:18:05 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 10:18:10 -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 g8PHI4tG004792 for ; Wed, 25 Sep 2002 10:18:05 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8PHHrSt069913; Wed, 25 Sep 2002 19:17:53 +0200 (CEST) Message-Id: <4.3.2.7.2.20020925190601.038b4d38@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Sep 2002 19:10:27 +0200 To: "Bryan J. Smith" , chris@devidal.tv, Chris de Vidal From: Seth Mos Subject: Re: Upgrading from v1.0.x to 1.1.x Cc: linux-xfs@oss.sgi.com In-Reply-To: <1032969754.3d91de1a3a9f5@webmail.smithconcepts.com> References: <20020925143916.16309.qmail@web40502.mail.yahoo.com> <20020925143916.16309.qmail@web40502.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 579 X-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:02 25-9-2002 -0400, Bryan J. Smith wrote: >Quoting Chris de Vidal : >Unlike some JFS' out there, XFS' structure remains relatively unchanged. I >thank God almost everyday that SGI ported XFS from Irix -- damn sweet >design in >the first place. > > From my understanding, changes of the on-disc structure have beene few > and far >between in the Linux port itself. MIPS->Intel default blocksize and only >a few That is more of architecture issue. Even the Irix boxen default to 4k just like Intel. The PPC folks have 4k as well. It was only some of the ia64 people that got bitten by having a machine with 8k pagesize per default. It was more a limitation that the fs blocksize == pagesize. The current CVS can mount even 512byte blocksize filesystem like they can be created on Irix. And it has nothing to do with the actual layout. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Sep 25 12:35:19 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 12:35:26 -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 g8PJZItG006928 for ; Wed, 25 Sep 2002 12:35:18 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 6F9991E127D; Wed, 25 Sep 2002 12:35:18 -0700 (PDT) Date: Wed, 25 Sep 2002 12:35:18 -0700 From: Chris Wedgwood To: linux-xfs@oss.sgi.com Subject: 2.4.19-rmap14b oopsen Message-ID: <20020925193518.GA31680@tapu.f00f.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="gKMricLos+KVdGMg" Content-Disposition: inline User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 580 X-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 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline I have a filesystem here with a corrupt journal it seems. If I try to mount he filesystem (booting via nfs-root as the fs is supposed to be mounted as /) I get the following assertion (previous an oops until I rebuilt with debugging). Attached is a dump of the log (xfs_logprint -t). --cw ksymoops 2.4.6 on i686 2.4.19-xfs-rmap14b. Options used -V (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.19-xfs-rmap14b/ (default) -m /boot/System.map-2.4.19-xfs-rmap14b (default) cpu: 0, clocks: 994878, slice: 497439 SGI XFS CVS-09/25/02:05 with ACLs, debug enabled kernel BUG at debug.c:47! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 00000059 ebx: 00000034 ecx: cde98000 edx: 00000001 esi: cf6a8ce0 edi: cf19fbc0 ebp: cdb7bb6c esp: cdb7bb5c ds: 0018 es: 0018 ss: 0018 Process mount (pid: 190, stackpage=cdb7b000) Stack: c02bcc00 c02b792b c02b7384 0000051d cdb7bb98 c01c0c3f c02b792b c02b7384 0000051d cf6a8ce0 c1a551d4 00000005 0000000d 0000000d cf6a8d20 cdb7bbc8 c01c25ea cf6a8ce0 cdb40034 00000034 00000000 000005c4 c1aa5e60 cdb40034 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 2f 00 2e cc 2b c0 89 ec 5d c3 8d 76 00 55 8b 0d 88 71 >>EIP; c01e66c9 <===== Trace; c01c0c3f Trace; c01c25ea Trace; c01c32d5 Trace; c01c393b Trace; c01c39de Trace; c01c3bf6 Trace; c01bb79b Trace; c01c84dd Trace; c01d190d Trace; c01d1ba6 Trace; c01d1c79 Trace; c01e54d2 Trace; c0137fc9 Trace; c01467b5 Trace; c0138182 Trace; c01476c6 Trace; c014798d Trace; c01477f4 Trace; c0147cf0 Trace; c01087ff Code; c01e66c9 00000000 <_EIP>: Code; c01e66c9 <===== 0: 0f 0b ud2a <===== Code; c01e66cb 2: 2f das Code; c01e66cc 3: 00 2e add %ch,(%esi) Code; c01e66ce 5: cc int3 Code; c01e66cf 6: 2b c0 sub %eax,%eax Code; c01e66d1 8: 89 ec mov %ebp,%esp Code; c01e66d3 a: 5d pop %ebp Code; c01e66d4 b: c3 ret Code; c01e66d5 c: 8d 76 00 lea 0x0(%esi),%esi Code; c01e66d8 f: 55 push %ebp Code; c01e66d9 10: 8b 0d 88 71 00 00 mov 0x7188,%ecx --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="md2-log.txt" xfs_logprint: data device: 0x902 log device: 0x902 daddr: 2939136 length: 9728 log tail: 7117 head: 7133 state: LOG REC AT LSN cycle 34 block 7117 (0x22, 0x1bcd) ============================================================================ TRANS: tid:0xc1a551d4 type:STRAT_WRITE #items:5 trans:0x0 q:0x80882a0 INO: cnt:3 total:3 a:0x80882c0 len:52 a:0x8088318 len:96 a:0x8088380 len:16 INODE: #regs:3 ino:0xe1f flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x8088398 len:24 a:0x80883f0 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x8088478 len:28 a:0x80884d0 len:640 BUF: #regs:2 start blkno:0x6d00 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x8088758 len:28 a:0x80887b0 len:128 BUF: #regs:2 start blkno:0x42a8 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x8088838 len:24 a:0x8088890 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: LOG REC AT LSN cycle 34 block 7121 (0x22, 0x1bd1) ============================================================================ TRANS: tid:0xc1a551f8 type:CREATE #items:5 trans:0x0 q:0x80882b8 BUF: cnt:2 total:2 a:0x80882d8 len:24 a:0x8088310 len:128 BUF: #regs:2 start blkno:0x2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x8088398 len:28 a:0x80883f0 len:128 BUF: #regs:2 start blkno:0xd80 len:8 bmap size:2 BUF DATA INO: cnt:2 total:2 a:0x8088478 len:52 a:0x80884e8 len:96 INODE: #regs:2 ino:0x5812 flags:0x1 dsize:16 CORE inode: INO: cnt:3 total:3 a:0x8088550 len:52 a:0x80885c8 len:96 a:0x8088630 len:56 INODE: #regs:3 ino:0xe25 flags:0x3 dsize:56 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x8088670 len:24 a:0x80886c8 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xc1a5521c type:INACTIVE #items:1 trans:0x0 q:0x80882d0 INO: cnt:2 total:2 a:0x80882f0 len:52 a:0x8088340 len:96 INODE: #regs:2 ino:0x5812 flags:0x1 dsize:16 CORE inode: ============================================================================ TRANS: tid:0xc1a55240 type:REMOVE #items:3 trans:0x0 q:0x80882e8 INO: cnt:3 total:3 a:0x8088308 len:52 a:0x8088360 len:96 a:0x80883c8 len:40 INODE: #regs:3 ino:0xe25 flags:0x3 dsize:40 CORE inode: DATA FORK LOCAL inode data: INO: cnt:3 total:3 a:0x80883f8 len:52 a:0x8088470 len:96 a:0x80884d8 len:16 INODE: #regs:3 ino:0xe1f flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80884f0 len:24 a:0x8088548 len:256 BUF: #regs:2 start blkno:0x2 len:1 bmap size:1 AGI Buffer: (XAGI) ============================================================================ TRANS: tid:0xc1a55264 type:INACTIVE #items:2 trans:0x0 q:0x8088300 INO: cnt:2 total:2 a:0x8088320 len:52 a:0x8088370 len:96 INODE: #regs:2 ino:0xe1f flags:0x1 dsize:16 CORE inode: EFI: cnt:1 total:1 a:0x80883d8 len:28 EFI: #regs:1 num_extents:1 id:0xffffffffc2cd01a4 (s: 0xa38, l: 1) ============================================================================ TRANS: tid:0xc1a55264 type:INACTIVE #items:6 trans:0x0 q:0x8088318 EFD: cnt:1 total:1 a:0x8088338 len:28 EFD: #regs: 1 num_extents: 1 id: 0xffffffffc2cd01a4 (s: 0xa38, l: 1) BUF: cnt:2 total:2 a:0x8088368 len:24 a:0x80883c0 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x8088448 len:28 a:0x80884a0 len:128 BUF: #regs:2 start blkno:0x42a8 len:8 bmap size:2 BUF DATA BUF: cnt:2 total:2 a:0x8088528 len:28 a:0x8088580 len:640 BUF: #regs:2 start blkno:0x6d00 len:8 bmap size:2 BUF DATA INO: cnt:2 total:2 a:0x8088808 len:52 a:0x8088878 len:96 INODE: #regs:2 ino:0xe1f flags:0x1 dsize:16 CORE inode: BUF: cnt:2 total:2 a:0x80888e0 len:24 a:0x8088938 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xc1a55264 type:INACTIVE #items:4 trans:0x0 q:0x8088330 INO: cnt:2 total:2 a:0x8088350 len:52 a:0x80883a0 len:96 INODE: #regs:2 ino:0xe1f flags:0x1 dsize:16 CORE inode: BUF: cnt:2 total:2 a:0x8088408 len:24 a:0x8088460 len:256 BUF: #regs:2 start blkno:0x2 len:1 bmap size:1 AGI Buffer: (XAGI) BUF: cnt:3 total:3 a:0x8088568 len:28 a:0x80885c8 len:128 a:0x8088650 len:128 BUF: #regs:3 start blkno:0xd80 len:8 bmap size:2 BUF DATA BUF DATA BUF: cnt:2 total:2 a:0x80886d8 len:24 a:0x8088730 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 SUPER Block Buffer: ============================================================================ TRANS: tid:0xc1a55288 type:SETATTR #items:1 trans:0x0 q:0x8088348 INO: cnt:2 total:2 a:0x8088368 len:52 a:0x80883b8 len:96 INODE: #regs:2 ino:0x5812 flags:0x1 dsize:16 CORE inode: ============================================================================ TRANS: tid:0xc1a552ac type:RENAME #items:1 trans:0x0 q:0x8088360 INO: cnt:3 total:3 a:0x8088380 len:52 a:0x80883d8 len:96 a:0x8088440 len:40 INODE: #regs:3 ino:0xe25 flags:0x3 dsize:40 CORE inode: DATA FORK LOCAL inode data: --gKMricLos+KVdGMg-- From owner-linux-xfs@oss.sgi.com Wed Sep 25 13:10:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 13:10:30 -0700 (PDT) Received: from mail.cs.tu-berlin.de (root@mail.cs.tu-berlin.de [130.149.17.13]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PKAOtG008665 for ; Wed, 25 Sep 2002 13:10:25 -0700 Received: from bolero.cs.tu-berlin.de (daemon@bolero.cs.tu-berlin.de [130.149.19.1]) by mail.cs.tu-berlin.de (8.9.3/8.9.3) with ESMTP id WAA12314; Wed, 25 Sep 2002 22:07:32 +0200 (MET DST) Received: (from doko@localhost) by bolero.cs.tu-berlin.de (8.11.6+Sun/8.9.3) id g8PK7WG16852; Wed, 25 Sep 2002 22:07:32 +0200 (MEST) From: Matthias Klose MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15762.6020.364002.585622@gargle.gargle.HOWL> Date: Wed, 25 Sep 2002 22:07:32 +0200 To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com, Harald Wagener Subject: Re: XFS "freezes" on AMD systems In-Reply-To: <20020925075844.GA26750@tapu.f00f.org> References: <15761.27018.659158.237109@gargle.gargle.HOWL> <20020925075844.GA26750@tapu.f00f.org> X-Mailer: VM 7.03 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid X-archive-position: 581 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: doko@cs.tu-berlin.de Precedence: bulk X-list: linux-xfs Chris Wedgwood writes: > On Wed, Sep 25, 2002 at 09:45:14AM +0200, Matthias Klose wrote: > > > When unpacking large tarballs or copying data bigger than 20MB on a > > XFS file system, the system seems to freeze for about three to five > > seconds > > [...] > > > but only on Athlon/Duron based systems, both using IDE drives. I > > don't see this type of freeze on a Celeron based system. > > At a guess... > > What IDE chipset? I would guess the chipset used on the Duran/Athlon > systems isn't using DMA for IDE transfer but rather PIO. > > hdparm(8) may help here, or you may beed to recompile the kernel with > different IDE chipset support[1]. Thanks for the pointer! That fixed my setup. From owner-linux-xfs@oss.sgi.com Wed Sep 25 13:44:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 13:44:28 -0700 (PDT) Received: from mtiwmhc21.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PKiNtG009577 for ; Wed, 25 Sep 2002 13:44:23 -0700 Received: from mtiwebc19 ([204.127.135.58]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020925204418.XEXP27953.mtiwmhc21.worldnet.att.net@mtiwebc19> for ; Wed, 25 Sep 2002 20:44:18 +0000 Received: from [65.88.209.36] by mtiwebc19; Wed, 25 Sep 2002 20:44:17 +0000 From: gmrincon@att.net To: linux-xfs@oss.sgi.com Date: Wed, 25 Sep 2002 20:44:17 +0000 X-Mailer: AT&T Message Center Version 1 (Sep 18 2002) X-Authenticated-Sender: MjBiVilnVDlKYDIrXDMoOy9OOmM2VElOWFJIYSxJWCw= Message-Id: <20020925204418.XEXP27953.mtiwmhc21.worldnet.att.net@mtiwebc19> X-archive-position: 582 Subject: (no subject) X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gmrincon@att.net Precedence: bulk X-list: linux-xfs Hi guys, I was trying to use XFS with Native little-endian on-disk format to eliminate current big endian/little endian conversions. I did the following step: 1.- Modify ../fs/xfs/xfs_arch.h (line 274) /* do we need conversion? */ #define ARCH_NOCONVERT 1 #if __BYTE_ORDER == __LITTLE_ENDIAN - #define ARCH_CONVERT ARCH_:CONVERT + #define ARCH_CONVERT ARCH_NOCONVERT #else #define ARCH_CONVERT ARCH_NOCONVERT #endif 2.- Compile the new kernel 3.- Creat a new xfsprogs RPMS, the xfs_arch.h file was changed with the previous patch. 4.- Install the kernel. 5.- Install the xfsprogs (Version with changes) 6.- Creat a FileSystem (mkfs -t xfs /dev/sdb2). 7.- Mount a FileSystem (mount -txfs /dev/sdb2 /disk0). The Hardware used was a Pentium III at 1Mhz, 1 Gbyte of RAM (Dell 1550 Server) Result. creat filesystem was okay. Mount filesystem was okay. df -h command shows the right information. mkdir command works. cd command works (Change directory). cp files to the filesystem works. vi on a file works (read operation). ls does not show entries. (like filesystem empty, directory . and .. was not showed) Do i missing something? Or this is not the way to do it, I'm not a kernel expert, i just doing it for fun. Is any other way to achive this with XFS? Thank you Gustavo Rincon From owner-linux-xfs@oss.sgi.com Wed Sep 25 13:51:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 13:52:00 -0700 (PDT) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PKpwtG010099 for ; Wed, 25 Sep 2002 13:51:58 -0700 Received: from mtiwebc19 ([204.127.135.58]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20020925205152.MZWD29048.mtiwmhc11.worldnet.att.net@mtiwebc19> for ; Wed, 25 Sep 2002 20:51:52 +0000 Received: from [65.88.209.36] by mtiwebc19; Wed, 25 Sep 2002 20:51:51 +0000 From: gmrincon@att.net To: linux-xfs@oss.sgi.com Cc: grincon@att.net Subject: Question about litte and Big Endian? Date: Wed, 25 Sep 2002 20:51:51 +0000 X-Mailer: AT&T Message Center Version 1 (Sep 18 2002) X-Authenticated-Sender: MmFOV09OPi89PVNhNFtCPTtbSlJPMDU8TDY1LkQ1XWA= Message-Id: <20020925205152.MZWD29048.mtiwmhc11.worldnet.att.net@mtiwebc19> X-archive-position: 583 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gmrincon@att.net Precedence: bulk X-list: linux-xfs Hi guys, I was trying to use XFS with Native little-endian on-disk format to eliminate current big endian/little endian conversions. I did the following step: 1.- Modify ../fs/xfs/xfs_arch.h (line 274) /* do we need conversion? */ #define ARCH_NOCONVERT 1 #if __BYTE_ORDER == __LITTLE_ENDIAN - #define ARCH_CONVERT ARCH_:CONVERT + #define ARCH_CONVERT ARCH_NOCONVERT #else #define ARCH_CONVERT ARCH_NOCONVERT #endif 2.- Compile the new kernel 3.- Creat a new xfsprogs RPMS, the xfs_arch.h file was changed with the previous patch. 4.- Install the kernel. 5.- Install the xfsprogs (Version with changes) 6.- Creat a FileSystem (mkfs -t xfs /dev/sdb2). 7.- Mount a FileSystem (mount -txfs /dev/sdb2 /disk0). The Hardware used was a Pentium III at 1Mhz, 1 Gbyte of RAM (Dell 1550 Server) Result. creat filesystem was okay. Mount filesystem was okay. df -h command shows the right information. mkdir command works. cd command works (Change directory). cp files to the filesystem works. vi on a file works (read operation). ls does not show entries. (like filesystem empty, directory . and .. was not showed) Do i missing something? Or this is not the way to do it, I'm not a kernel expert, i just doing it for fun. Is any other way to achive this with XFS? Thank you Gustavo Rincon From owner-linux-xfs@oss.sgi.com Wed Sep 25 14:27:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 14:27:54 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PLRqtG011039 for ; Wed, 25 Sep 2002 14:27:52 -0700 Received: (qmail 3570 invoked by uid 500); 25 Sep 2002 21:27:37 -0000 Subject: using xfs_dump to backup an Oracle DB in hot backup mode. From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1032989256.1324.354.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 25 Sep 2002 16:27:37 -0500 X-archive-position: 584 X-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 Anyone have an order of operation for something like this? I was thinking, that while oracle is in hot_backup mode, I would just be able to do xfs_dump /dev/sdb /dev/sdaa or some such thing, until all volumes are done. If I don't use xfs_freeze though, is that a good copy? I'm a bit confused at this point, and wanted to ask the community. TIA -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Wed Sep 25 14:51:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 14:51: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 g8PLpFtG011718 for ; Wed, 25 Sep 2002 14:51: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 QAA62121; Wed, 25 Sep 2002 16:51:09 -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 QAA91460; Wed, 25 Sep 2002 16:51:09 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8PLkDp03407; Wed, 25 Sep 2002 16:46:13 -0500 Subject: Re: using xfs_dump to backup an Oracle DB in hot backup mode. From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1032989256.1324.354.camel@UberGeek.coremetrics.com> References: <1032989256.1324.354.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Sep 2002 16:46:13 -0500 Message-Id: <1032990373.21812.540.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 585 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-25 at 16:27, Austin Gonyou wrote: > Anyone have an order of operation for something like this? > > I was thinking, that while oracle is in hot_backup mode, I would just be > able to do xfs_dump /dev/sdb /dev/sdaa or some such thing, until all > volumes are done. > > If I don't use xfs_freeze though, is that a good copy? > > I'm a bit confused at this point, and wanted to ask the community. TIA > freeze and xfsdump are totally different beasts. freeze gives you a stable image on disk, including all data and metadata from the buffer cache at the time. Once frozen you need some other mechanism to take a copy of the disk image. xfsdump is going to do a file based backup. I cannot speak for the best point in time to do this to an oracle setup. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 25 14:57:09 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 14:57:10 -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 g8PLv8tG012303 for ; Wed, 25 Sep 2002 14:57:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA57349; Wed, 25 Sep 2002 16:57:02 -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 QAA79279; Wed, 25 Sep 2002 16:57:02 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8PLq6m03432; Wed, 25 Sep 2002 16:52:06 -0500 Subject: Re: Question about litte and Big Endian? From: Steve Lord To: gmrincon@att.net Cc: linux-xfs@oss.sgi.com, grincon@att.net In-Reply-To: <20020925205152.MZWD29048.mtiwmhc11.worldnet.att.net@mtiwebc19> References: <20020925205152.MZWD29048.mtiwmhc11.worldnet.att.net@mtiwebc19> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 25 Sep 2002 16:52:06 -0500 Message-Id: <1032990726.23748.555.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 586 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@sgi.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-25 at 15:51, gmrincon@att.net wrote: > Hi guys, I was trying to use XFS with Native little-endian on-disk format to > eliminate current big endian/little endian conversions. I did the > following > step: > > 1.- Modify ../fs/xfs/xfs_arch.h (line 274) > /* do we need conversion? */ > > #define ARCH_NOCONVERT 1 > #if __BYTE_ORDER == __LITTLE_ENDIAN > - #define ARCH_CONVERT ARCH_:CONVERT > + #define ARCH_CONVERT ARCH_NOCONVERT > #else > #define ARCH_CONVERT ARCH_NOCONVERT > #endif > > 2.- Compile the new kernel > 3.- Creat a new xfsprogs RPMS, the xfs_arch.h file was changed with the > > previous patch. > 4.- Install the kernel. > 5.- Install the xfsprogs (Version with changes) > 6.- Creat a FileSystem (mkfs -t xfs /dev/sdb2). > 7.- Mount a FileSystem (mount -txfs /dev/sdb2 /disk0). > > The Hardware used was a Pentium III at 1Mhz, 1 Gbyte of RAM (Dell 1550 > Server) > > Result. > creat filesystem was okay. > Mount filesystem was okay. > df -h command shows the right information. > mkdir command works. > cd command works (Change directory). > cp files to the filesystem works. > vi on a file works (read operation). > ls does not show entries. (like filesystem empty, directory . > and .. > was not showed) > > > Do i missing something? Or this is not the way to do it, I'm not a > kernel > expert, i just > doing it for fun. Is any other way to achive this with XFS? > This is not something we have tried, it is possible that there is some endian code somewhere which is not paying attention to the architecture flags, but that would probably mean a breakage on big endian hardware. Look in fs/xfs/xfs_log_priv.h for this code: /* our fmt */ #if __BYTE_ORDER == __LITTLE_ENDIAN #define XLOG_FMT XLOG_FMT_LINUX_LE #else #if __BYTE_ORDER == __BIG_ENDIAN #define XLOG_FMT XLOG_FMT_LINUX_BE #else #error unknown byte order #endif #endif you probably need to tweak that. There are a number of other places in the xfs code which depend on the value of __BYTE_ORDER, you might try changing that instead of doing what you did. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:02:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:03:01 -0700 (PDT) Received: from mail (12-248-255-165.client.attbi.com [12.248.255.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PM2utG012823 for ; Wed, 25 Sep 2002 15:02:57 -0700 Received: (qmail 6203 invoked by uid 1000); 25 Sep 2002 22:02:46 -0000 Date: Wed, 25 Sep 2002 17:02:46 -0500 From: "Corey G." To: linux-xfs@oss.sgi.com Subject: slow performance with 2.4.19 and debian Message-ID: <20020925220246.GA5963@attbi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 587 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctgaff@attbi.com Precedence: bulk X-list: linux-xfs I am currently running Debian, 3.0 (woody) and when I install, and patch kernel 2.4.19 I notice a very large degradation in performance. For instance, the Mozilla tarball takes 118s to untar (non-verbose) with kernel 2.4.18. When I install 2.4.19 it takes around 240s to untar. I also notice the box is having problems relinquishing resouces during heavy IO operations. The mouse jumps and the screen is quite slow with refresh problems during decompression of files and opening of tarballs. As soon as I reboot back to 2.4.18 everything is okay. Could I have run into a compatibility issue with Debian or have forgotten a key component in the kernel config file? please reply to: ctgaff@attbi.com # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set CONFIG_MK7=y # CONFIG_MELAN is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_MCE=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # # General setup # CONFIG_NET=y CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set # CONFIG_HOTPLUG is not set # CONFIG_PCMCIA is not set # CONFIG_HOTPLUG_PCI is not set CONFIG_SYSVIPC=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_SUNBPP is not set # CONFIG_PARPORT_OTHER is not set # CONFIG_PARPORT_1284 is not set # # Plug and Play configuration # CONFIG_PNP=m # CONFIG_ISAPNP is not set # # Block devices # CONFIG_BLK_DEV_FD=m # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # # Multi-device support (RAID and LVM) # # CONFIG_MD is not set # # Networking options # CONFIG_PACKET=m # CONFIG_PACKET_MMAP is not set # CONFIG_NETLINK_DEV is not set # CONFIG_NETFILTER is not set # CONFIG_FILTER is not set CONFIG_UNIX=y CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVANCED_ROUTER is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set # CONFIG_SYN_COOKIES is not set # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is not set # CONFIG_VLAN_8021Q is not set # # # # CONFIG_IPX is not set # CONFIG_ATALK is not set # # Appletalk devices # # CONFIG_DECNET is not set # CONFIG_BRIDGE is not set # CONFIG_X25 is not set # CONFIG_LAPB is not set # CONFIG_LLC is not set # CONFIG_NET_DIVERT is not set # CONFIG_ECONET is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # # CONFIG_NET_SCHED is not set # # Network testing # # CONFIG_NET_PKTGEN is not set # # Telephony Support # # CONFIG_PHONE is not set # # ATA/IDE/MFM/RLL support # CONFIG_IDE=y # # IDE, ATA and ATAPI Block devices # CONFIG_BLK_DEV_IDE=y # # Please see Documentation/ide.txt for help/info on IDE drives # # CONFIG_BLK_DEV_HD_IDE is not set # CONFIG_BLK_DEV_HD is not set CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_IDEDISK_STROKE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_COMMERIAL is not set CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=m CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # # IDE chipset support/bugfixes # CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y # CONFIG_IDEPCI_SHARE_IRQ is not set CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_BLK_DEV_HPT366 is not set # CONFIG_BLK_DEV_PIIX is not set # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_BLK_DEV_SVWKS is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y # CONFIG_IDEDMA_IVB is not set # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y # CONFIG_BLK_DEV_ATARAID is not set # # SCSI support # CONFIG_SCSI=m # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_SD_EXTRA_DEVS=40 CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_SR_EXTRA_DEVS=2 CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_DEBUG_QUEUES=y CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y # CONFIG_SCSI_LOGGING is not set # # SCSI low-level drivers # CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_7000FASST=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m CONFIG_SCSI_AHA1740=m # CONFIG_SCSI_AACRAID is not set CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=253 CONFIG_AIC7XXX_RESET_DELAY_MS=15000 # CONFIG_AIC7XXX_PROBE_EISA_VL is not set # CONFIG_AIC7XXX_BUILD_FIRMWARE is not set # CONFIG_SCSI_AIC7XXX_OLD is not set CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_IN2000=m CONFIG_SCSI_AM53C974=m CONFIG_SCSI_MEGARAID=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_OMIT_FLASHPOINT is not set CONFIG_SCSI_CPQFCTS=m CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_DTC3280=m CONFIG_SCSI_EATA=m # CONFIG_SCSI_EATA_TAGGED_QUEUE is not set # CONFIG_SCSI_EATA_LINKED_COMMANDS is not set CONFIG_SCSI_EATA_MAX_TAGS=16 # CONFIG_SCSI_EATA_DMA is not set # CONFIG_SCSI_EATA_PIO is not set # CONFIG_SCSI_FUTURE_DOMAIN is not set # CONFIG_SCSI_GDTH is not set CONFIG_SCSI_GENERIC_NCR5380=m # CONFIG_SCSI_GENERIC_NCR53C400 is not set CONFIG_SCSI_G_NCR5380_PORT=y # CONFIG_SCSI_G_NCR5380_MEM is not set # CONFIG_SCSI_IPS is not set # CONFIG_SCSI_INITIO is not set # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set CONFIG_SCSI_NCR53C406A=m CONFIG_SCSI_NCR53C7xx=m # CONFIG_SCSI_NCR53C7xx_sync is not set # CONFIG_SCSI_NCR53C7xx_FAST is not set # CONFIG_SCSI_NCR53C7xx_DISCONNECT is not set # CONFIG_SCSI_SYM53C8XX_2 is not set # CONFIG_SCSI_NCR53C8XX is not set CONFIG_SCSI_SYM53C8XX=m CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4 CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32 CONFIG_SCSI_NCR53C8XX_SYNC=20 # CONFIG_SCSI_NCR53C8XX_PROFILE is not set # CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set # CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set # CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set # CONFIG_SCSI_PAS16 is not set # CONFIG_SCSI_PCI2000 is not set # CONFIG_SCSI_PCI2220I is not set # CONFIG_SCSI_PSI240I is not set # CONFIG_SCSI_QLOGIC_FAS is not set # CONFIG_SCSI_QLOGIC_ISP is not set # CONFIG_SCSI_QLOGIC_FC is not set # CONFIG_SCSI_QLOGIC_1280 is not set # CONFIG_SCSI_SEAGATE is not set # CONFIG_SCSI_SIM710 is not set CONFIG_SCSI_SYM53C416=m CONFIG_SCSI_DC390T=m # CONFIG_SCSI_DC390T_NOGENSUPP is not set # CONFIG_SCSI_T128 is not set # CONFIG_SCSI_U14_34F is not set CONFIG_SCSI_ULTRASTOR=m # CONFIG_SCSI_DEBUG is not set # # Fusion MPT device support # # CONFIG_FUSION is not set # CONFIG_FUSION_BOOT is not set # CONFIG_FUSION_ISENSE is not set # CONFIG_FUSION_CTL is not set # CONFIG_FUSION_LAN is not set # # IEEE 1394 (FireWire) support (EXPERIMENTAL) # # CONFIG_IEEE1394 is not set # # I2O device support # # CONFIG_I2O is not set # # Network device support # CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set # CONFIG_TUN is not set # CONFIG_ETHERTAP is not set # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y # CONFIG_HAPPYMEAL is not set # CONFIG_SUNGEM is not set CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m # CONFIG_EL16 is not set CONFIG_EL3=m CONFIG_3C515=m CONFIG_VORTEX=m CONFIG_LANCE=m # CONFIG_NET_VENDOR_SMC is not set # CONFIG_NET_VENDOR_RACAL is not set # CONFIG_AT1700 is not set # CONFIG_DEPCA is not set # CONFIG_HP100 is not set # CONFIG_NET_ISA is not set CONFIG_NET_PCI=y # CONFIG_PCNET32 is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_AC3200 is not set # CONFIG_APRICOT is not set # CONFIG_CS89x0 is not set # CONFIG_TULIP is not set # CONFIG_TC35815 is not set # CONFIG_DE4X5 is not set # CONFIG_DGRS is not set # CONFIG_DM9102 is not set CONFIG_EEPRO100=m CONFIG_FEALNX=m # CONFIG_NATSEMI is not set # CONFIG_NE2K_PCI is not set # CONFIG_8139CP is not set # CONFIG_8139TOO is not set # CONFIG_SIS900 is not set # CONFIG_EPIC100 is not set # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set # CONFIG_VIA_RHINE is not set # CONFIG_WINBOND_840 is not set # CONFIG_NET_POCKET is not set # # Ethernet (1000 Mbit) # # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set # CONFIG_SK98LIN is not set # CONFIG_TIGON3 is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set # CONFIG_PLIP is not set CONFIG_PPP=m # CONFIG_PPP_MULTILINK is not set # CONFIG_PPP_ASYNC is not set # CONFIG_PPP_SYNC_TTY is not set # CONFIG_PPP_DEFLATE is not set # CONFIG_PPP_BSDCOMP is not set # CONFIG_PPPOE is not set # CONFIG_SLIP is not set # # Wireless LAN (non-hamradio) # # CONFIG_NET_RADIO is not set # # Token Ring devices # # CONFIG_TR is not set # CONFIG_NET_FC is not set # CONFIG_RCPCI is not set # CONFIG_SHAPER is not set # # Wan interfaces # # CONFIG_WAN is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # ISDN subsystem # # CONFIG_ISDN is not set # # Old CD-ROM drivers (not SCSI, not IDE) # # CONFIG_CD_NO_IDESCSI is not set # # Input core support # # CONFIG_INPUT is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y # CONFIG_SERIAL_CONSOLE is not set # CONFIG_SERIAL_EXTENDED is not set # CONFIG_SERIAL_NONSTANDARD is not set CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=256 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set # CONFIG_PPDEV is not set # # I2C support # # CONFIG_I2C is not set # # Mice # # CONFIG_BUSMOUSE is not set CONFIG_MOUSE=m CONFIG_PSMOUSE=y # CONFIG_82C710_MOUSE is not set # CONFIG_PC110_PAD is not set # CONFIG_MK712_MOUSE is not set # # Joysticks # # CONFIG_INPUT_GAMEPORT is not set # # Input core support is needed for gameports # # # Input core support is needed for joysticks # # CONFIG_QIC02_TAPE is not set # # Watchdog Cards # # CONFIG_WATCHDOG is not set # CONFIG_AMD_RNG is not set # CONFIG_INTEL_RNG is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_DTLK is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # CONFIG_SONYPI is not set # # Ftape, the floppy tape device driver # # CONFIG_FTAPE is not set CONFIG_AGP=y CONFIG_AGP_INTEL=y CONFIG_AGP_I810=y CONFIG_AGP_VIA=y CONFIG_AGP_AMD=y CONFIG_AGP_SIS=y CONFIG_AGP_ALI=y # CONFIG_AGP_SWORKS is not set CONFIG_DRM=y # CONFIG_DRM_OLD is not set # # DRM 4.1 drivers # CONFIG_DRM_NEW=y CONFIG_DRM_TDFX=y CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m # CONFIG_DRM_I810 is not set # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_MWAVE is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # File systems # # CONFIG_FS_POSIX_ACL is not set # CONFIG_QUOTA is not set CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # CONFIG_REISERFS_FS is not set # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set # CONFIG_HFS_FS is not set # CONFIG_BFS_FS is not set # CONFIG_EXT3_FS is not set # CONFIG_JBD is not set # CONFIG_FAT_FS is not set # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set # CONFIG_MINIX_FS is not set # CONFIG_VXFS_FS is not set # CONFIG_NTFS_FS is not set # CONFIG_HPFS_FS is not set CONFIG_PROC_FS=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set CONFIG_EXT2_FS=y # CONFIG_SYSV_FS is not set # CONFIG_UDF_FS is not set # CONFIG_UFS_FS is not set CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set CONFIG_XFS_QUOTA=y # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_DEBUG is not set # CONFIG_PAGEBUF_DEBUG is not set # # Network File Systems # # CONFIG_CODA_FS is not set # CONFIG_INTERMEZZO_FS is not set CONFIG_NFS_FS=m # CONFIG_NFS_V3 is not set CONFIG_NFSD=m # CONFIG_NFSD_V3 is not set CONFIG_SUNRPC=m CONFIG_LOCKD=m # CONFIG_SMB_FS is not set # CONFIG_NCP_FS is not set # CONFIG_ZISOFS_FS is not set # CONFIG_ZLIB_FS_INFLATE is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y # CONFIG_SMB_NLS is not set CONFIG_NLS=y # # Native Language Support # CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set # CONFIG_NLS_ISO8859_1 is not set # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set # CONFIG_NLS_ISO8859_15 is not set # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set # CONFIG_NLS_UTF8 is not set # # Console drivers # CONFIG_VGA_CONSOLE=y # CONFIG_VIDEO_SELECT is not set # CONFIG_MDA_CONSOLE is not set # # Frame-buffer support # # CONFIG_FB is not set # # Sound # CONFIG_SOUND=y # CONFIG_SOUND_BT878 is not set # CONFIG_SOUND_CMPCI is not set CONFIG_SOUND_EMU10K1=m # CONFIG_MIDI_EMU10K1 is not set # CONFIG_SOUND_FUSION is not set # CONFIG_SOUND_CS4281 is not set # CONFIG_SOUND_ES1370 is not set # CONFIG_SOUND_ES1371 is not set # CONFIG_SOUND_ESSSOLO1 is not set # CONFIG_SOUND_MAESTRO is not set # CONFIG_SOUND_MAESTRO3 is not set # CONFIG_SOUND_ICH is not set # CONFIG_SOUND_RME96XX is not set # CONFIG_SOUND_SONICVIBES is not set # CONFIG_SOUND_TRIDENT is not set # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set # CONFIG_SOUND_VIA82CXXX is not set # CONFIG_SOUND_OSS is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # # CONFIG_USB_DEVICEFS is not set # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_LONG_TIMEOUT is not set # # USB Host Controller Drivers # # CONFIG_USB_EHCI_HCD is not set CONFIG_USB_UHCI=m CONFIG_USB_UHCI_ALT=m # CONFIG_USB_OHCI is not set # # USB Device Class drivers # # CONFIG_USB_AUDIO is not set # CONFIG_USB_BLUETOOTH is not set CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_HP8200e is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_ACM is not set # CONFIG_USB_PRINTER is not set # # USB Human Interface Devices (HID) # # CONFIG_USB_HID is not set # # Input core support is needed for USB HID input layer or HIDBP support # # # USB Imaging devices # # CONFIG_USB_DC2XX is not set # CONFIG_USB_MDC800 is not set # CONFIG_USB_SCANNER is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_HPUSBSCSI is not set # # USB Multimedia devices # # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # # CONFIG_USB_PEGASUS is not set # CONFIG_USB_RTL8150 is not set # CONFIG_USB_KAWETH is not set # CONFIG_USB_CATC is not set # CONFIG_USB_CDCETHER is not set # CONFIG_USB_USBNET is not set # # USB port drivers # # CONFIG_USB_USS720 is not set # # USB Serial Converter support # # CONFIG_USB_SERIAL is not set # # USB Miscellaneous drivers # # CONFIG_USB_RIO500 is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_BRLVGER is not set # # Bluetooth support # # CONFIG_BLUEZ is not set # # Kernel hacking # # CONFIG_DEBUG_KERNEL is not set -- Best Regards, Corey From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:03:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:03:32 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PM3UtG012988 for ; Wed, 25 Sep 2002 15:03:30 -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 RAA10384; Wed, 25 Sep 2002 17:03:25 -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 RAA92605; Wed, 25 Sep 2002 17:03:24 -0500 (CDT) Subject: Re: Question about litte and Big Endian? From: Eric Sandeen To: Steve Lord Cc: gmrincon@att.net, linux-xfs@oss.sgi.com, grincon@att.net In-Reply-To: <1032990726.23748.555.camel@jen.americas.sgi.com> References: <20020925205152.MZWD29048.mtiwmhc11.worldnet.att.net@mtiwebc19> <1032990726.23748.555.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 25 Sep 2002 17:03:13 -0500 Message-Id: <1032991393.31876.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 588 X-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 And if this all works, send in some benchmarks, to see if it's all worthwhile. :) -Eric On Wed, 2002-09-25 at 16:52, Steve Lord wrote: > you probably need to tweak that. There are a number of other places in > the xfs code which depend on the value of __BYTE_ORDER, you might try > changing that instead of doing what you did. > > Steve -- 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 25 15:07:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:07:35 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PM7XtG013771 for ; Wed, 25 Sep 2002 15:07:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA64366; Wed, 25 Sep 2002 17:07:28 -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 RAA55613; Wed, 25 Sep 2002 17:07:27 -0500 (CDT) Subject: Re: slow performance with 2.4.19 and debian From: Eric Sandeen To: "Corey G." Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020925220246.GA5963@attbi.com> References: <20020925220246.GA5963@attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 25 Sep 2002 17:07:16 -0500 Message-Id: <1032991636.31813.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 589 X-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 Where did your 2.4.18 xfs patch come from? From debian, or from xfs-1.1, or...? Just trying to see where you started. -Eric On Wed, 2002-09-25 at 17:02, Corey G. wrote: > I am currently running Debian, 3.0 (woody) and when I install, and patch > kernel 2.4.19 I notice a very large degradation in performance. For > instance, the Mozilla tarball takes 118s to untar (non-verbose) with > kernel 2.4.18. When I install 2.4.19 it takes around 240s to untar. I > also notice the box is having problems relinquishing resouces during > heavy IO operations. The mouse jumps and the screen is quite slow with > refresh problems during decompression of files and opening of tarballs. > As soon as I reboot back to 2.4.18 everything is okay. Could I have > run into a compatibility issue with Debian or have forgotten > a key component in the kernel config file? > > > please reply to: ctgaff@attbi.com -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:20:01 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:20:03 -0700 (PDT) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PMK0tG014408 for ; Wed, 25 Sep 2002 15:20:00 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id SAA07115 for ; Wed, 25 Sep 2002 18:19:55 -0400 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA06896 for ; Wed, 25 Sep 2002 18:19:54 -0400 Subject: Re: using xfs_dump to backup an Oracle DB in hot backup mode. From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <1032989256.1324.354.camel@UberGeek.coremetrics.com> References: <1032989256.1324.354.camel@UberGeek.coremetrics.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 25 Sep 2002 18:19:54 -0400 Message-Id: <1032992394.1048.69.camel@two.nks.net> Mime-Version: 1.0 X-archive-position: 590 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs On Wed, 2002-09-25 at 17:27, Austin Gonyou wrote: > Anyone have an order of operation for something like this? > > I was thinking, that while oracle is in hot_backup mode, I would just be > able to do xfs_dump /dev/sdb /dev/sdaa or some such thing, until all > volumes are done. > > If I don't use xfs_freeze though, is that a good copy? > > I'm a bit confused at this point, and wanted to ask the community. TIA [grrr... stupid broken "reply" on email client. ALSO sending reply to list for anyone else who may like to know] I think as long as your Oracle is in the proper state, the filesystem is kind of irrelevant. xfsdump, I assume, sees what the OS sees as the current state of the file, so you just have whatever race conditions the application may place on any file you're backing up and not worry about whether the file on the filesystem is "consistent" because from the perspective of the VFS it is. Oracle specifically handles hot-backups to prevent any race conditions during backup, so there's no trouble there either. You will need to have your Oracle in ARCHIVELOG mode so full redo logs get archived rather than recycled. (Oracle won't let you put it into a hot backup mode without being in ARCHIVELOG mode anyway.) ALTER each TABLESPACE you wish to back up as BEGIN BACKUP, which causes Oracle to stop flushing transactions to the datafiles and just store/archive them in the transaction log files thereby leaving your datafiles in a consistent state by not performing any writes to them during the backup. Backup your Oracle datafiles. ALTER each TABLESPACE END BACKUP to make Oracle flush pending transactions back to the datafiles which starts writing to the datafiles again. Then backup your redo logfiles and archived redo logs. Hopefully your redo logs, archived redo logs and datafiles are on different partitions so xfsdump can archive them separately. (Generally they're at least on different spindles for performance reasons.) The only place you may run into problems is with the redo logs since there is no point at which Oracle may not be writing to those files or have outstanding writes to those files that have not been written by the application. Once a transaction (redo) log has filled up, it is archived and recycled, and you can safely back up the archived logfiles without fear of writes to the file while being backed up. Does that help at all? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:34:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:34:32 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e188.dsl.mediaWays.net [213.20.225.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PMYTtG015174 for ; Wed, 25 Sep 2002 15:34:30 -0700 Received: from indigo-3.berdmann.de ([192.168.5.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17uKiw-0001li-00 for linux-xfs@oss.sgi.com; Thu, 26 Sep 2002 00:33:38 +0200 Message-ID: <3D9239C1.2070704@berdmann.de> Date: Thu, 26 Sep 2002 00:33:37 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS "freezes" on AMD systems References: <15761.27018.659158.237109@gargle.gargle.HOWL> <20020925075844.GA26750@tapu.f00f.org> <15762.6020.364002.585622@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 591 X-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 Matthias Klose wrote: [...] >>>When unpacking large tarballs or copying data bigger than 20MB on a >>>XFS file system, the system seems to freeze for about three to five >>>seconds [...] >>hdparm(8) may help here, or you may beed to recompile the kernel with >>different IDE chipset support[1]. [...] > Thanks for the pointer! That fixed my setup. Use SCSI. Use SCSI. Use SCSI. Use... From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:50:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:50:45 -0700 (PDT) Received: from stumpy.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PModtG017709 for ; Wed, 25 Sep 2002 15:50:39 -0700 Received: from stumpy.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by stumpy.chowhouse.com (8.12.6/8.12.6) with ESMTP id g8PMp7wk019603 for ; Wed, 25 Sep 2002 16:51:07 -0600 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id g8PMp7jC019600 for ; Wed, 25 Sep 2002 16:51:07 -0600 Date: Wed, 25 Sep 2002 16:51:07 -0600 (MDT) From: James Rich To: XFS mailing list Subject: restoring after running xfs_repair Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 592 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs For some reason my partition (on a brand new machine) containing / got corrupted. I ran xfs_repair on it and now everything is in lost+found. How do I put it all back? If I can't put it back it wouldn't be too bad since this is a brand new install and nothing really significant has been done on it yet - so no real data loss. Should I have done something before running xfs_repair? James Rich From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:52:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:52:01 -0700 (PDT) Received: from ente.berdmann.de (frnk-d514e188.dsl.mediaWays.net [213.20.225.136]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PMpxtG018034 for ; Wed, 25 Sep 2002 15:51:59 -0700 Received: from indigo-3.berdmann.de ([192.168.5.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.35 #1) id 17uKx1-0001nG-00; Thu, 26 Sep 2002 00:48:11 +0200 Message-ID: <3D923D2B.7050902@berdmann.de> Date: Thu, 26 Sep 2002 00:48:11 +0200 From: Bernhard Erdmann User-Agent: Mozilla/5.0 (X11; U; IRIX64 IP28; en-US; rv:1.1b) Gecko/20020723 X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Seth Mos CC: "N.C. Sunil" , linux-xfs@oss.sgi.com Subject: Re: Clarification References: <4.3.2.7.2.20020920134142.02df57e8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 593 X-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 Seth Mos wrote: [...] > Run the xfs_fsr utility to defragment your harddrive. Some people run > this overnight in cron every day or week. Defragmentation is done on my SGI boxes as part of root's crontab: # Reorganize file systems # 0 3 * * 0 if test -x /usr/etc/fsr; then (cd /usr/tmp; /usr/etc/fsr) fi From owner-linux-xfs@oss.sgi.com Wed Sep 25 15:52:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 15:52:48 -0700 (PDT) Received: from absinthe.carnagecopia.com (qmailr@absinthe.carnagecopia.com [216.187.87.246]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PMqktG018617 for ; Wed, 25 Sep 2002 15:52:46 -0700 Received: (qmail 39739 invoked by uid 85); 25 Sep 2002 22:52:46 -0000 Received: from random@goblinstudios.com by absinthe.carnagecopia.com with qmail-scanner-1.03 (uvscan: v4.0.50/v4224. . Clean. Processed in 0.15639 secs); 25 Sep 2002 22:52:46 -0000 Received: from firewall-vancouver.goblinstudios.com (HELO workstation-22.internal.carnagecopia.com) (204.244.192.2) by absinthe.carnagecopia.com with SMTP; 25 Sep 2002 22:52:45 -0000 Date: Wed, 25 Sep 2002 18:52:58 -0400 From: Vincent Janelle To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: XFS "freezes" on AMD systems Message-Id: <20020925185258.664fece3.random@goblinstudios.com> In-Reply-To: <3D9239C1.2070704@berdmann.de> References: <15761.27018.659158.237109@gargle.gargle.HOWL> <20020925075844.GA26750@tapu.f00f.org> <15762.6020.364002.585622@gargle.gargle.HOWL> <3D9239C1.2070704@berdmann.de> Organization: http://www.goblinstudios.com/ X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 594 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: random@goblinstudios.com Precedence: bulk X-list: linux-xfs irrelevant and flamebait. Proper tuning of DMA settings will help, as well as making sure that using the correct IDE driver is selected. hdparm -c1 -d1 -u1 /dev/hd[a,b,c,etc] will turn on 32bit write support, dma, and unmasked irq's. man hdparm of course before doing any of this, YMMV. On Thu, 26 Sep 2002 00:33:37 +0200 Bernhard Erdmann wrote: > Matthias Klose wrote: > [...] > >>>When unpacking large tarballs or copying data bigger than 20MB on a > >>>XFS file system, the system seems to freeze for about three to five > >>>seconds > [...] > >>hdparm(8) may help here, or you may beed to recompile the kernel with > >>different IDE chipset support[1]. > [...] > > Thanks for the pointer! That fixed my setup. > > Use SCSI. Use SCSI. Use SCSI. Use... > > From owner-linux-xfs@oss.sgi.com Wed Sep 25 16:01:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 16:01:42 -0700 (PDT) Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PN1dtG019278 for ; Wed, 25 Sep 2002 16:01:39 -0700 Received: from TAZ2 ([12.87.82.182]) by mtiwmhc11.worldnet.att.net (InterMail vM.5.01.05.12 201-253-122-126-112-20020820) with SMTP id <20020925230129.QEMS29048.mtiwmhc11.worldnet.att.net@TAZ2>; Wed, 25 Sep 2002 23:01:29 +0000 Date: Wed, 25 Sep 2002 18:59:47 -0400 From: Greg Freemyer Subject: re: using xfs_dump to backup an Oracle DB in hot backup mode. To: Austin Gonyou , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020925230129.QEMS29048.mtiwmhc11.worldnet.att.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8PN1dtG019285 X-archive-position: 595 X-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 >> Anyone have an order of operation for something like this? >> I was thinking, that while oracle is in hot_backup mode, I would just be >> able to do xfs_dump /dev/sdb /dev/sdaa or some such thing, until all >> volumes are done. >> If I don't use xfs_freeze though, is that a good copy? >> I'm a bit confused at this point, and wanted to ask the community. TIA I thought Oracle's hot_backup was specifically designed to work with snapshots. I.e. freeze Oracle --> xfs_freeze --> create snapshot --> unfreeze xfs --> unfreeze Oracle If you are going to have it in that mode for the entire duration of your backup, you may have problems. In particular, I don't think the write buffers are all that huge. Even worse, if you go into hot_backup for an hour or so, and you have a machine crash during this time, your new data is lost!!!! If you do want to try to go disk to disk extremely rapidly, you will need to either not use xfs_freeze, on mount your drive with -noatime. 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 25 16:51:57 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 16:52:03 -0700 (PDT) Received: from MSUMAIL2.Campus.mnsu.edu (msuex2.campus.mnsu.edu [134.29.52.40]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8PNputG019978 for ; Wed, 25 Sep 2002 16:51:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: XFS "freezes" on AMD systems Date: Wed, 25 Sep 2002 18:51:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS "freezes" on AMD systems Thread-Index: AcJk5lDZAU+iZ+ngRmu4dKL2GqyK6wAB4DWH From: "Hundstad, Jeffrey E." To: "Vincent Janelle" , "Bernhard Erdmann" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8PNpvtG019979 X-archive-position: 596 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jeffrey.hundstad@mnsu.edu Precedence: bulk X-list: linux-xfs Also with hdparm you'll want to set the "multiple sector count" and turn off write caching. Here's the steps: hdparm -i /dev/hd? Look for the MaxMultSect number. hdparm -W0 -c1 -d1 -u1 -m XX /dev/hda? # where XX is the MaxMultSect number -----Original Message----- From: Vincent Janelle [mailto:random@goblinstudios.com] Sent: Wed 9/25/2002 5:52 PM To: Bernhard Erdmann Cc: linux-xfs@oss.sgi.com Subject: Re: XFS "freezes" on AMD systems irrelevant and flamebait. Proper tuning of DMA settings will help, as well as making sure that using the correct IDE driver is selected. hdparm -c1 -d1 -u1 /dev/hd[a,b,c,etc] will turn on 32bit write support, dma, and unmasked irq's. man hdparm of course before doing any of this, YMMV. On Thu, 26 Sep 2002 00:33:37 +0200 Bernhard Erdmann wrote: > Matthias Klose wrote: > [...] > >>>When unpacking large tarballs or copying data bigger than 20MB on a > >>>XFS file system, the system seems to freeze for about three to five > >>>seconds > [...] > >>hdparm(8) may help here, or you may beed to recompile the kernel with > >>different IDE chipset support[1]. > [...] > > Thanks for the pointer! That fixed my setup. > > Use SCSI. Use SCSI. Use SCSI. Use... > > From owner-linux-xfs@oss.sgi.com Wed Sep 25 17:10:30 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 17:10:32 -0700 (PDT) Received: from mail (12-248-255-165.client.attbi.com [12.248.255.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8Q0ATtG021347 for ; Wed, 25 Sep 2002 17:10:29 -0700 Received: (qmail 7055 invoked by uid 1000); 26 Sep 2002 00:10:16 -0000 Date: Wed, 25 Sep 2002 19:10:16 -0500 From: "Corey G." To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: slow performance with 2.4.19 and debian Message-ID: <20020926001016.GA7003@attbi.com> References: <20020925220246.GA5963@attbi.com> <1032991636.31813.24.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1032991636.31813.24.camel@stout.americas.sgi.com> User-Agent: Mutt/1.3.28i X-archive-position: 597 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctgaff@attbi.com Precedence: bulk X-list: linux-xfs The patch came from xfs.org site for 2.4.19: xfs-2.4.19-all-i386.bz2 The 2.4.18 kernel is the default from Debian. I am not sure how this kernel was patched but I am investigating. -Corey On Wed, Sep 25, 2002 at 05:07:16PM -0500, Eric Sandeen wrote: > Where did your 2.4.18 xfs patch come from? From debian, or from > xfs-1.1, or...? Just trying to see where you started. > > -Eric > > On Wed, 2002-09-25 at 17:02, Corey G. wrote: > > I am currently running Debian, 3.0 (woody) and when I install, and patch > > kernel 2.4.19 I notice a very large degradation in performance. For > > instance, the Mozilla tarball takes 118s to untar (non-verbose) with > > kernel 2.4.18. When I install 2.4.19 it takes around 240s to untar. I > > also notice the box is having problems relinquishing resouces during > > heavy IO operations. The mouse jumps and the screen is quite slow with > > refresh problems during decompression of files and opening of tarballs. > > As soon as I reboot back to 2.4.18 everything is okay. Could I have > > run into a compatibility issue with Debian or have forgotten > > a key component in the kernel config file? > > > > > > please reply to: ctgaff@attbi.com > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > ---end quoted text--- -- Best Regards, Corey From owner-linux-xfs@oss.sgi.com Wed Sep 25 18:17:40 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 18:17:47 -0700 (PDT) Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8Q1HetG025241 for ; Wed, 25 Sep 2002 18:17:40 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) 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 SAA00790 for ; Wed, 25 Sep 2002 18:17:38 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA70892; Thu, 26 Sep 2002 11:16:19 +1000 (AEST) Date: Thu, 26 Sep 2002 11:16:19 +1000 From: Tim Shimmin To: Eric Sandeen Cc: Steve Lord , gmrincon@att.net, linux-xfs@oss.sgi.com, grincon@att.net Subject: Re: Question about litte and Big Endian? Message-ID: <20020926111619.O92301@boing.melbourne.sgi.com> References: <20020925205152.MZWD29048.mtiwmhc11.worldnet.att.net@mtiwebc19> <1032990726.23748.555.camel@jen.americas.sgi.com> <1032991393.31876.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <1032991393.31876.17.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Sep 25, 2002 at 05:03:13PM -0500 X-archive-position: 598 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs FYI, In May 2000, when there was debate over whether to do on-the-fly endian conversion, some tests were done with existing linux-xfs code (without any conversion macros) and new linux-xfs code with the endian macros. We deemed there was no _significant_ difference and thus endian conversion was implemented. Some of the results (which I can still find) are below. The code, however, would have changed a lot since then. --Tim On Wed, Sep 25, 2002 at 05:03:13PM -0500, Eric Sandeen wrote: > And if this all works, send in some benchmarks, to see if it's all > worthwhile. :) > > -Eric > > On Wed, 2002-09-25 at 16:52, Steve Lord wrote: > > you probably need to tweak that. There are a number of other places in > > the xfs code which depend on the value of __BYTE_ORDER, you might try > > changing that instead of doing what you did. > > > > Steve > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > > Test: AIM Units: ops/second ======================================================================== ======================================================================== Host: sagan, dual processor 299MHz pentium II, 128Mb RAM, SCSI Date: 8/May kernel: slinx-xfs, all as modules, meta off, NOT using delayed alloc id: sagan-036 Native ------ OPERATION MEAN ST.DEV. % ST.DEV creat-clo 33377.80 203.88 0.61 disk_cp 20986.79 25.74 0.12 disk_rd 105754.43 459.00 0.43 disk_rr 21015.58 25.09 0.12 disk_rw 16985.52 14.18 0.08 disk_src 1220.75 10.23 0.84 disk_wrt 28785.20 66.26 0.23 link_test 552.66 1.15 0.21 sync_disk_cp 445.78 1.63 0.37 sync_disk_rw 17278.53 88.78 0.51 sync_disk_wrt 446.47 0.42 0.09 id = sagan-038 Mips ---- OPERATION MEAN ST.DEV. % ST.DEV creat-clo 34532.53 126.11 0.37 disk_cp 21006.29 10.62 0.05 disk_rd 107176.06 505.56 0.47 disk_rr 20967.31 40.76 0.19 disk_rw 17302.52 81.75 0.47 disk_src 1222.81 1.73 0.14 disk_wrt 28100.33 289.75 1.03 link_test 552.65 3.74 0.68 sync_disk_cp 446.55 1.33 0.30 sync_disk_rw 17319.97 72.18 0.42 sync_disk_wrt 446.08 1.00 0.23 ---------------------- Comparison Mips/Native ---------------------- OPERATION NATIVE MIPS REL. creat-clo 33377.80 34532.53 1.03 disk_cp 20986.79 21006.29 1.00 disk_rd 105754.43 107176.06 1.01 disk_rr 21015.58 20967.31 1.00 disk_rw 16985.52 17302.52 1.02 disk_src 1220.75 1222.81 1.00 disk_wrt 28785.20 28100.33 0.98 link_test 552.66 552.65 1.00 sync_disk_cp 445.78 446.55 1.00 sync_disk_rw 17278.53 17319.97 1.00 sync_disk_wrt 446.47 446.08 1.00 ======================================================================== ======================================================================== Host: bruce, dual processor 550Mhz Pentium III, 896Mb RAM, SCSI Date: 13/May kernel: slinx-xfs, all as modules, meta off, delayed alloc on id: bruce-004 Native ------ OPERATION MEAN ST.DEV. % ST.DEV creat-clo 63888.89 126.20 0.20 disk_cp 52431.37 180.65 0.34 disk_rd 152656.27 1634.58 1.07 disk_rr 52364.28 68.64 0.13 disk_rw 48664.27 396.99 0.82 disk_src 2270.15 6.02 0.27 disk_wrt 89112.84 412.34 0.46 link_test 1356.25 8.57 0.63 sync_disk_cp 460.85 0.97 0.21 sync_disk_rw 38283.58 27.28 0.07 sync_disk_wrt 460.66 1.02 0.22 id: bruce-006 Mips ------ OPERATION MEAN ST.DEV. % ST.DEV creat-clo 58788.89 267.36 0.45 disk_cp 51359.05 42.72 0.08 disk_rd 152116.36 173.05 0.11 disk_rr 51688.50 93.90 0.18 disk_rw 47273.75 70.63 0.15 disk_src 2263.99 2.65 0.12 disk_wrt 88024.91 183.61 0.21 link_test 1331.10 3.92 0.29 sync_disk_cp 459.79 1.88 0.41 sync_disk_rw 38219.55 25.00 0.07 sync_disk_wrt 460.81 1.88 0.41 ---------------------- Comparison Mips/Native ---------------------- OPERATION NATIVE MIPS REL. creat-clo 63888.89 58788.89 0.92 disk_cp 52431.37 51359.05 0.98 disk_rd 152656.27 152116.36 1.00 disk_rr 52364.28 51688.50 0.99 disk_rw 48664.27 47273.75 0.97 disk_src 2270.15 2263.99 1.00 disk_wrt 89112.84 88024.91 0.99 link_test 1356.25 1331.10 0.98 sync_disk_cp 460.85 459.79 1.00 sync_disk_rw 38283.58 38219.55 1.00 sync_disk_wrt 460.66 460.81 1.00 **************************************************************************** Test: dbench Units: Throughput Mb/second ======================================================================== ======================================================================== Host: sagan, dual processor 299MHz pentium II, 128Mb RAM, SCSI Date: 8/May kernel: slinx-xfs, all as modules, meta off, NOT using delayed alloc Using nclients = 3 050 cpu & i/o kernel.percpu.cpu.sys ["cpu0"] 0.147 kernel.percpu.cpu.sys ["cpu1"] 0.140 kernel.percpu.cpu.idle ["cpu0"] 0.813 kernel.percpu.cpu.idle ["cpu1"] 0.816 disk.partitions.write_bytes ["sda7"] 1426.386 Kbyte / sec => run is i/o bound and not cpu bound id: sagan-050 Native ------ OPERATION MEAN ST.DEV. % ST.DEV Throughput 6.57 1.33 20.32 id: sagan-052 Mips ---- OPERATION MEAN ST.DEV. % ST.DEV Throughput 5.85 1.13 19.32 ---------------------- Comparison Mips/Native ---------------------- OPERATION NATIVE MIPS REL. Throughput 6.57 5.85 0.89 ======================================================================== ======================================================================== Host: bruce, dual processor 550Mhz Pentium III, 896Mb RAM, SCSI Date: 13/May kernel: slinx-xfs, all as modules, meta off, delayed alloc on Using nclients = 4 011 cpu & i/o kernel.percpu.cpu.sys ["cpu0"] 0.447 none kernel.percpu.cpu.sys ["cpu1"] 0.449 none kernel.percpu.cpu.idle ["cpu0"] 0.397 none kernel.percpu.cpu.idle ["cpu1"] 0.398 none disk.partitions.write_bytes ["sda8"] 1530.929 Kbyte / sec => run is using more of the cpu and is less i/o bound id: bruce-011 Native ------ OPERATION MEAN ST.DEV. % ST.DEV Throughput 55.60 2.70 4.86 id: bruce-012 Mips ------ OPERATION MEAN ST.DEV. % ST.DEV Throughput 49.87 3.31 6.63 ---------------------- Comparison Mips/Native ---------------------- OPERATION NATIVE MIPS REL. Throughput 55.60 49.87 0.90 ======================================================================== ======================================================================== Host: bruce, dual processor 550Mhz Pentium III, 896Mb RAM, SCSI Date: 13/May kernel: slinx-xfs, all as modules, meta off, delayed alloc on Using nclients = 8 013 cpu & i/o kernel.percpu.cpu.sys ["cpu0"] 0.157 none kernel.percpu.cpu.sys ["cpu1"] 0.154 none kernel.percpu.cpu.idle ["cpu0"] 0.797 none kernel.percpu.cpu.idle ["cpu1"] 0.799 none disk.partitions.write_bytes ["sda8"] 2835.668 Kbyte / sec system is i/o bound and not using as much cpu. id: bruce-013 Native ------ OPERATION MEAN ST.DEV. % ST.DEV Throughput 14.26 2.10 14.70 id: bruce-014 Mips ------ OPERATION MEAN ST.DEV. % ST.DEV Throughput 11.89 0.78 6.58 ---------------------- Comparison Mips/Native ---------------------- OPERATION NATIVE MIPS REL. Throughput 14.26 11.89 0.83 From owner-linux-xfs@oss.sgi.com Wed Sep 25 19:14:10 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 19:14:14 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8Q2E9tG026047 for ; Wed, 25 Sep 2002 19:14:10 -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 VAA68289; Wed, 25 Sep 2002 21:14:04 -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 VAA21656; Wed, 25 Sep 2002 21:14:03 -0500 (CDT) Date: Wed, 25 Sep 2002 21:13:50 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: James Rich cc: XFS mailing list Subject: Re: restoring after running xfs_repair In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 599 X-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 What prompted you to run xfs_repair in the first place? Do you still have the specific error? If everything wound up in lost+found, it's because directory information was lost, so I'm afraid there is no easy way to "put it all back." The original error would be most helpful, along with anything you can think of that could have contributed to the problem... (Any odd configuration, patches, hardware, etc?) -Eric On Wed, 25 Sep 2002, James Rich wrote: > For some reason my partition (on a brand new machine) containing / got > corrupted. I ran xfs_repair on it and now everything is in lost+found. > How do I put it all back? If I can't put it back it wouldn't be too bad > since this is a brand new install and nothing really significant has been > done on it yet - so no real data loss. > > Should I have done something before running xfs_repair? > > James Rich > > From owner-linux-xfs@oss.sgi.com Wed Sep 25 19:18:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Sep 2002 19:18: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 g8Q2IKtG026525 for ; Wed, 25 Sep 2002 19:18:20 -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 VAA59803; Wed, 25 Sep 2002 21:18:14 -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 VAA68428; Wed, 25 Sep 2002 21:18:14 -0500 (CDT) Date: Wed, 25 Sep 2002 21:18:01 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Corey G." cc: linux-xfs@oss.sgi.com Subject: Re: slow performance with 2.4.19 and debian In-Reply-To: <20020926001016.GA7003@attbi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 600 X-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 Corey - Just off the top of my head, you could try the snapshot patch from: ftp://oss.sgi.com/projects/xfs/download/patches/weekly-snapshot-patch/ and see if this is any better (it's more recent). Maybe we'll get lucky... -Eric On Wed, 25 Sep 2002, Corey G. wrote: > The patch came from xfs.org site for 2.4.19: > > xfs-2.4.19-all-i386.bz2 > From owner-linux-xfs@oss.sgi.com Thu Sep 26 07:56:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 07:56:30 -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 g8QEuOtG006227 for ; Thu, 26 Sep 2002 07:56:25 -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 JAA68133 for ; Thu, 26 Sep 2002 09:56:19 -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 JAA83737 for ; Thu, 26 Sep 2002 09:56:19 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8QEpGD05876; Thu, 26 Sep 2002 09:51:16 -0500 Message-Id: <200209261451.g8QEpGD05876@jen.americas.sgi.com> Date: Thu, 26 Sep 2002 09:51:16 -0500 Subject: TAKE - Avoid writing data out to disk twice in 2.5 To: linux-xfs@oss.sgi.com X-archive-position: 601 X-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 A hole in our logic meant we were not cleaning dirty state on some pages, end result was we wrote them twice - xfs was half the speed of ext2 on streaming writes. With this change we are disk bound again and back to ext2 speed. This is a 2.5 only change. Date: Thu Sep 26 07:54:36 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:128467a linux/fs/xfs/linux/xfs_aops.c - 1.9 - When we start I/O on a page, clean it, we need to do this ourselves since we have a writepage call which writes more than one page out. Also skip pages which are already being writeback processed somewhere. From owner-linux-xfs@oss.sgi.com Thu Sep 26 09:08:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 09:08:34 -0700 (PDT) Received: from stumpy.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QG8StG011039 for ; Thu, 26 Sep 2002 09:08:29 -0700 Received: from stumpy.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by stumpy.chowhouse.com (8.12.6/8.12.6) with ESMTP id g8QG8wwk002231; Thu, 26 Sep 2002 10:08:58 -0600 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id g8QG8w4R002228; Thu, 26 Sep 2002 10:08:58 -0600 Date: Thu, 26 Sep 2002 10:08:58 -0600 (MDT) From: James Rich To: Eric Sandeen cc: XFS mailing list Subject: Re: restoring after running xfs_repair In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 602 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs On Wed, 25 Sep 2002, Eric Sandeen wrote: > What prompted you to run xfs_repair in the first place? Do you still > have the specific error? After a normal shutdown the machine would panic on startup right after trying to mount /. Note that this happened after a *normal* shutdown. Kernel was 2.4 from CVS a couple of days ago. The machine is a Supermicro SuperServer 5011E. My testing reveals that having ACPI and APM enabled causes the problem. By disabling these (both in the BIOS and the kernel) the problem went away. > If everything wound up in lost+found, it's because directory information > was lost, so I'm afraid there is no easy way to "put it all back." I looked at what was created in lost+found and was easily able to put things back in the right places. Just the highest level directory structure had been lost (i.e. the connections to /) so it was easy to just mv 3145688 /etc. > The original error would be most helpful, along with anything you can think > of that could have contributed to the problem... (Any odd configuration, > patches, hardware, etc?) No oops or anything. A complete description of the hardware is at www.supermicro.com. I did a shutdown -h now and on restarting it the machine paniced right after mounting /. The kernel is checked out from CVS as of a few days ago. James Rich From owner-linux-xfs@oss.sgi.com Thu Sep 26 09:17:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 09:17:24 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QGHMtG011548 for ; Thu, 26 Sep 2002 09:17:22 -0700 Received: (qmail 5194 invoked by uid 500); 26 Sep 2002 16:17:06 -0000 Subject: re: using xfs_dump to backup an Oracle DB in hot backup mode. From: Austin Gonyou To: Greg Freemyer Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020925230129.QEMS29048.mtiwmhc11.worldnet.att.net@TAZ2> References: <20020925230129.QEMS29048.mtiwmhc11.worldnet.att.net@TAZ2> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Coremetrics, Inc. Message-Id: <1033057025.4938.17.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 26 Sep 2002 11:17:05 -0500 X-archive-position: 603 X-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-25 at 17:59, Greg Freemyer wrote: > >> Anyone have an order of operation for something like this? > > >> I was thinking, that while oracle is in hot_backup mode, I would > just be > >> able to do xfs_dump /dev/sdb /dev/sdaa or some such thing, until > all > >> volumes are done. > > >> If I don't use xfs_freeze though, is that a good copy? > > >> I'm a bit confused at this point, and wanted to ask the > community. TIA > > I thought Oracle's hot_backup was specifically designed to work with > snapshots. > > I.e. freeze Oracle --> xfs_freeze --> create snapshot --> unfreeze > xfs --> unfreeze Oracle > > If you are going to have it in that mode for the entire duration of > your backup, you may have problems. In particular, I don't think the > write buffers are all that huge. So the operation described above can be done in a relatively short period of time yes? If so, then xfs_freeze won't have to be on long as the snapshot would appear as though it were still frozen. > Even worse, if you go into hot_backup for an hour or so, and you have > a machine crash during this time, your new data is lost!!!! I assume you're speaking to the snapshot? I think this is the part that confuses me the most. > If you do want to try to go disk to disk extremely rapidly, you will > need to either not use xfs_freeze, on mount your drive with -noatime. We already mount with noatime, IOzone tests show it's much faster and more consistent to do so. Disk-Disk backup would be ideal in our situation, then it preserves the BCV like operation, which is really what I'm trying to find out how to do, if I can, with XFS utilities. > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 v4, v5 > Compaq Master ASE - SAN Architect > The Norcross Group www.NorcrossGroup.com -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Thu Sep 26 10:00:34 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 10:00: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 g8QH0XtG012741 for ; Thu, 26 Sep 2002 10:00:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA71030; Thu, 26 Sep 2002 12:00:27 -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 MAA47183; Thu, 26 Sep 2002 12:00:27 -0500 (CDT) Subject: Re: restoring after running xfs_repair From: Eric Sandeen To: James Rich Cc: XFS mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 26 Sep 2002 12:00:08 -0500 Message-Id: <1033059609.7333.41.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 604 X-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 Thu, 2002-09-26 at 11:08, James Rich wrote: > I looked at what was created in lost+found and was easily able to put > things back in the right places. Just the highest level directory > structure had been lost (i.e. the connections to /) so it was easy to just > mv 3145688 /etc. Ok, good to know. > > The original error would be most helpful, along with anything you can think > > of that could have contributed to the problem... (Any odd configuration, > > patches, hardware, etc?) > > No oops or anything. A complete description of the hardware is at > www.supermicro.com. I did a shutdown -h now and on restarting it the > machine paniced right after mounting /. The kernel is checked out from > CVS as of a few days ago. So it happened to you -again-? -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 Thu Sep 26 12:24:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 12:24:57 -0700 (PDT) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QJOotG028720 for ; Thu, 26 Sep 2002 12:24:51 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWHQ1B2Q; Thu, 26 Sep 2002 15:22:07 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g8QJOnw03938; Thu, 26 Sep 2002 15:24:49 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3D935F01.9040508@wgate.com> Date: Thu, 26 Sep 2002 15:24:49 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1b) Gecko/20020813 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: James Rich , XFS mailing list Subject: Re: restoring after running xfs_repair References: <1033059609.7333.41.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 605 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Eric Sandeen wrote: > On Thu, 2002-09-26 at 11:08, James Rich wrote: > > >>I looked at what was created in lost+found and was easily able to put >>things back in the right places. Just the highest level directory >>structure had been lost (i.e. the connections to /) so it was easy to just >>mv 3145688 /etc. > > > Ok, good to know. > > >>>The original error would be most helpful, along with anything you can think >>>of that could have contributed to the problem... (Any odd configuration, >>>patches, hardware, etc?) >> >>No oops or anything. A complete description of the hardware is at >>www.supermicro.com. I did a shutdown -h now and on restarting it the >>machine paniced right after mounting /. The kernel is checked out from >>CVS as of a few days ago. This sounds like the IDE-write cache does not flush before power off problem. There is a "fix" to this in some systems that has the shutdown process, after syncing/unmounting stuff do a powerdown of the IDE drives to force them to write their caches before doing a shutdown of the ATX power supply via APM/APCI. You may wish to look into changing the write cache settings in the drives (albeit they don't always listen to what you ask) or, even better, to get your shutdown process to do the drive poweroff (hdparm is your friend) I think there is work going into the kernel to help with this but most of shutdown is actually handled/managed from userland. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:17:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:17:26 -0700 (PDT) Received: from webcube2.volstate.net (webcube2.volstate.net [66.129.16.201]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QKHLtG029598 for ; Thu, 26 Sep 2002 13:17:21 -0700 Received: from there (host217-32-153-216.net-serv.com [216.153.32.217] (may be forged)) by webcube2.volstate.net (8.9.3/8.9.3) with SMTP id QAA08115 for ; Thu, 26 Sep 2002 16:17:19 -0400 Message-Id: <200209262017.QAA08115@webcube2.volstate.net> Content-Type: text/plain; charset="iso-8859-15" From: Joe Bacom Reply-To: joebacom@volstate.net To: linux-xfs@oss.sgi.com Subject: Journal Free Space Date: Thu, 26 Sep 2002 15:15:32 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-archive-position: 606 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joebacom@volstate.net Precedence: bulk X-list: linux-xfs Hi Folks; Hopefully this is an easy question. I would like to know how to determine the amount of usage / free space that is left in the journal. I have several filesytems that make heavy use of extended attributes, so I would like to monitor the journal space to ensure that I don't try to overfill it. Thanks; Joe From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:28:39 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:28:40 -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 g8QKSctG030595 for ; Thu, 26 Sep 2002 13:28:39 -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 17ufFW-00030A-00 for linux-xfs@oss.sgi.com; Thu, 26 Sep 2002 14:28:38 -0600 Message-ID: <3D936DFA.5060900@emergence.com> Date: Thu, 26 Sep 2002 14:28:42 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS allows expansions, but no contraction? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 607 X-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 I know that XFS doesn't/didn't support filesystem resizing that involves making the filesystem smaller. What are the technical hurdles faced if such a program were to be written? Or would this be fairly obvious from reading the filesystem specification? Just working from assumptions (perhaps wrong) would be that you would have to find all files/inodes that are contained in the space that you need to want to truncate from your filesystem. Do some something similar to defragment/move those file into the non-truncated space. And then rewrite the XFS "superblock"? Is the biggest challenge then finding the files that are in this space? Telling the filesystem it is smaller? Moving/defragmenting the files? Due to limitations on how the code chooses where to write it's next blocks? Having to sort all the files on the filesystem? Just some random thoughts that came to me about resizing. This would be a good thing for LVM if I remember, and I was more or less curious why there isn't a tool (and then assumed that there wasn't one because it was hard to do due to a design decision). -Mike From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:33:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:33: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 g8QKXMtG031067 for ; Thu, 26 Sep 2002 13:33:22 -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 PAA56599; Thu, 26 Sep 2002 15:33:17 -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 PAA54107; Thu, 26 Sep 2002 15:33:16 -0500 (CDT) Subject: Re: XFS allows expansions, but no contraction? From: Eric Sandeen To: Michael Best Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D936DFA.5060900@emergence.com> References: <3D936DFA.5060900@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 26 Sep 2002 15:32:56 -0500 Message-Id: <1033072376.17558.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 608 X-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 has been discussed on the list before, and I -think- Steve detailed the technical difficulties. If you can't find it in the archives, I'll post a summary. -Eric On Thu, 2002-09-26 at 15:28, Michael Best wrote: > I know that XFS doesn't/didn't support filesystem resizing that involves > making the filesystem smaller. > > What are the technical hurdles faced if such a program were to be written? > > Or would this be fairly obvious from reading the filesystem specification? > > Just working from assumptions (perhaps wrong) would be that you would > have to find all files/inodes that are contained in the space that you > need to want to truncate from your filesystem. Do some something > similar to defragment/move those file into the non-truncated space. And > then rewrite the XFS "superblock"? > > Is the biggest challenge then finding the files that are in this space? > Telling the filesystem it is smaller? Moving/defragmenting the files? > Due to limitations on how the code chooses where to write it's next > blocks? Having to sort all the files on the filesystem? > > Just some random thoughts that came to me about resizing. This would be > a good thing for LVM if I remember, and I was more or less curious why > there isn't a tool (and then assumed that there wasn't one because it > was hard to do due to a design decision). > > -Mike > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:35:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:35:44 -0700 (PDT) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QKZgtG031517 for ; Thu, 26 Sep 2002 13:35:42 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 05FB32FAA7 for ; Thu, 26 Sep 2002 13:35:42 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 3D7FC2FAA7 for ; Thu, 26 Sep 2002 13:35:39 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id E07143438 for ; Thu, 26 Sep 2002 13:35:28 -0700 (PDT) Subject: Re: XFS "freezes" on AMD systems From: Florin Andrei To: linux-xfs In-Reply-To: <20020925185258.664fece3.random@goblinstudios.com> References: <15761.27018.659158.237109@gargle.gargle.HOWL> <20020925075844.GA26750@tapu.f00f.org> <15762.6020.364002.585622@gargle.gargle.HOWL> <3D9239C1.2070704@berdmann.de> <20020925185258.664fece3.random@goblinstudios.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Sep 2002 13:35:28 -0700 Message-Id: <1033072528.28775.54.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 609 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs He's right, but you're right too. :-) A properly tuned IDE works fine usually. However, all other things being equal, a disk connected via SCSI "feels" faster than the same HDD gear connected via IDE. The reason being the way SCSI talks with the rest of the system (lower CPU usage, etc). On Wed, 2002-09-25 at 15:52, Vincent Janelle wrote: > irrelevant and flamebait. > > Proper tuning of DMA settings will help, as well as making sure that using the correct IDE driver is selected. > > hdparm -c1 -d1 -u1 /dev/hd[a,b,c,etc] will turn on 32bit write support, dma, and unmasked irq's. > > man hdparm of course before doing any of this, YMMV. > > On Thu, 26 Sep 2002 00:33:37 +0200 > Bernhard Erdmann wrote: > > > Matthias Klose wrote: > > [...] > > >>>When unpacking large tarballs or copying data bigger than 20MB on a > > >>>XFS file system, the system seems to freeze for about three to five > > >>>seconds > > [...] > > >>hdparm(8) may help here, or you may beed to recompile the kernel with > > >>different IDE chipset support[1]. > > [...] > > > Thanks for the pointer! That fixed my setup. > > > > Use SCSI. Use SCSI. Use SCSI. Use... > > > > > > -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:39:11 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:39:12 -0700 (PDT) Received: from andrei.myip.org (12-234-116-173.client.attbi.com [12.234.116.173]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QKdBtG032004 for ; Thu, 26 Sep 2002 13:39:11 -0700 Received: from spampd.localdomain (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E6A0D2FAA7 for ; Thu, 26 Sep 2002 13:39:10 -0700 (PDT) Received: from stantz.corp.sgi.com (unknown [130.62.4.42]) by andrei.myip.org (Postfix) with ESMTP id 6184C2FAA7 for ; Thu, 26 Sep 2002 13:39:10 -0700 (PDT) Received: from localhost.localdomain (localhost [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 16BBE3438 for ; Thu, 26 Sep 2002 13:39:00 -0700 (PDT) Subject: Re: O(1) scheduler From: Florin Andrei To: linux-xfs In-Reply-To: <20020920214701.58788.qmail@web40603.mail.yahoo.com> References: <20020920214701.58788.qmail@web40603.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Sep 2002 13:38:59 -0700 Message-Id: <1033072740.29206.58.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-archive-position: 610 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: florin@sgi.com Precedence: bulk X-list: linux-xfs On Fri, 2002-09-20 at 14:47, Ravi Wijayaratne wrote: > > Are there any pitfalls in incorporating Ingo Molnars > O(1) scheduler to xfs-linux-2.4.18-r1.1 ? > The patches in the current xfs CVS does not seem to > be applicable. > Any insights or experiences ? I guess a resolution to this problem (either negative or positive) will be enforced as soon as people will start begging for a "XFS-enabled Red Hat 8.0 installer". ;-) (RH 8.0 is due to be launched on Monday, Sept 30th.) -- Florin Andrei "Security measures are characterized less by their manner of success than by their manner of failure." - Bruce Schneier From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:40:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:40:53 -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 g8QKeptG032461 for ; Thu, 26 Sep 2002 13:40: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 PAA58289; Thu, 26 Sep 2002 15:40:45 -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 PAA52148; Thu, 26 Sep 2002 15:40:45 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8QKZeQ06289; Thu, 26 Sep 2002 15:35:40 -0500 Subject: Re: XFS allows expansions, but no contraction? From: Steve Lord To: Eric Sandeen Cc: Michael Best , linux-xfs@oss.sgi.com In-Reply-To: <1033072376.17558.3.camel@stout.americas.sgi.com> References: <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Sep 2002 15:35:40 -0500 Message-Id: <1033072540.5423.17.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 611 X-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-26 at 15:32, Eric Sandeen wrote: > This has been discussed on the list before, and I -think- Steve detailed > the technical difficulties. If you can't find it in the archives, I'll > post a summary. There has recently been some internal push to make this happen too, but no decision about doing it, or how to resource doing it. Probably an extension of the xfs_fsr approach would be the way to go. One major issue is it is impossible to do this without changing inode numbers. Some applications rely on inode numbers remaining a constant. OK, I know that does not tell you anything, but I have just spent six hours talking to someone and my brain is fried! Steve > > -Eric > > On Thu, 2002-09-26 at 15:28, Michael Best wrote: > > I know that XFS doesn't/didn't support filesystem resizing that involves > > making the filesystem smaller. > > > > What are the technical hurdles faced if such a program were to be written? > > > > Or would this be fairly obvious from reading the filesystem specification? > > > > Just working from assumptions (perhaps wrong) would be that you would > > have to find all files/inodes that are contained in the space that you > > need to want to truncate from your filesystem. Do some something > > similar to defragment/move those file into the non-truncated space. And > > then rewrite the XFS "superblock"? > > > > Is the biggest challenge then finding the files that are in this space? > > Telling the filesystem it is smaller? Moving/defragmenting the files? > > Due to limitations on how the code chooses where to write it's next > > blocks? Having to sort all the files on the filesystem? > > > > Just some random thoughts that came to me about resizing. This would be > > a good thing for LVM if I remember, and I was more or less curious why > > there isn't a tool (and then assumed that there wasn't one because it > > was hard to do due to a design decision). > > > > -Mike > > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Sep 26 13:45:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 13:45:53 -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 g8QKjptG000507 for ; Thu, 26 Sep 2002 13:45:51 -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 PAA58253; Thu, 26 Sep 2002 15:45:46 -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 PAA24702; Thu, 26 Sep 2002 15:45:45 -0500 (CDT) Subject: Re: Journal Free Space From: Eric Sandeen To: joebacom@volstate.net Cc: linux-xfs@oss.sgi.com In-Reply-To: <200209262017.QAA08115@webcube2.volstate.net> References: <200209262017.QAA08115@webcube2.volstate.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 26 Sep 2002 15:45:25 -0500 Message-Id: <1033073126.17651.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 612 X-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'm not sure you're thinking about it quite right, you can't technically "overfill" your log. It's designed so that when it's full, metadata in memory is flushed to disk, so that you can use more log space. You can look at the log tail-pushing stats to see how much this happens, which might give you an idea of whether a larger log would help in your particular application. The xfs_stats script in cmd/xfsmisc in cvs will decipher the xfs stats in /proc. -Eric On Thu, 2002-09-26 at 15:15, Joe Bacom wrote: > Hi Folks; > > Hopefully this is an easy question. I would like to know how to determine > the amount of usage / free space that is left in the journal. I have several > filesytems that make heavy use of extended attributes, so I would like to > monitor the journal space to ensure that I don't try to overfill it. > > Thanks; > > Joe > -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. 651-683-3102 From owner-linux-xfs@oss.sgi.com Thu Sep 26 14:01:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 14:01:27 -0700 (PDT) Received: from absinthe.carnagecopia.com (qmailr@absinthe.carnagecopia.com [216.187.87.246]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8QL1PtG002253 for ; Thu, 26 Sep 2002 14:01:25 -0700 Received: (qmail 38728 invoked by uid 85); 26 Sep 2002 21:01:21 -0000 Received: from random@goblinstudios.com by absinthe.carnagecopia.com with qmail-scanner-1.03 (uvscan: v4.0.50/v4225. . Clean. Processed in 0.152349 secs); 26 Sep 2002 21:01:21 -0000 Received: from firewall-vancouver.goblinstudios.com (HELO workstation-22.internal.carnagecopia.com) (204.244.192.2) by absinthe.carnagecopia.com with SMTP; 26 Sep 2002 21:01:20 -0000 Date: Thu, 26 Sep 2002 17:01:46 -0400 From: Vincent Janelle To: Florin Andrei Cc: linux-xfs@oss.sgi.com Subject: Re: XFS "freezes" on AMD systems Message-Id: <20020926170146.5b73f97e.random@goblinstudios.com> In-Reply-To: <1033072528.28775.54.camel@stantz.corp.sgi.com> References: <15761.27018.659158.237109@gargle.gargle.HOWL> <20020925075844.GA26750@tapu.f00f.org> <15762.6020.364002.585622@gargle.gargle.HOWL> <3D9239C1.2070704@berdmann.de> <20020925185258.664fece3.random@goblinstudios.com> <1033072528.28775.54.camel@stantz.corp.sgi.com> Organization: http://www.goblinstudios.com/ X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 613 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: random@goblinstudios.com Precedence: bulk X-list: linux-xfs thats mostly due to command queing.. Unless you're using relatively new ultra-160 drives, and a good controller its still possible fill up the command queue relatively quickly with modern systems.. There are also 'modern' IDE controllers out there like 3ware cards that fix quite a few issues like this (although they're primarily raid cards). Only reason why I use scsi over IDE in my *servers* is that the warranty and MTBF are usually 3 years or more, whereas on IDE they're 1 year. On 26 Sep 2002 13:35:28 -0700 Florin Andrei wrote: > He's right, but you're right too. :-) > A properly tuned IDE works fine usually. > However, all other things being equal, a disk connected via SCSI "feels" > faster than the same HDD gear connected via IDE. The reason being the > way SCSI talks with the rest of the system (lower CPU usage, etc). > > On Wed, 2002-09-25 at 15:52, Vincent Janelle wrote: > > irrelevant and flamebait. > > > > Proper tuning of DMA settings will help, as well as making sure that using the correct IDE driver is selected. > > > > hdparm -c1 -d1 -u1 /dev/hd[a,b,c,etc] will turn on 32bit write support, dma, and unmasked irq's. > > > > man hdparm of course before doing any of this, YMMV. > > From owner-linux-xfs@oss.sgi.com Thu Sep 26 18:05:54 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 18:05:55 -0700 (PDT) Received: from stumpy.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8R15rtG027198 for ; Thu, 26 Sep 2002 18:05:54 -0700 Received: from stumpy.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by stumpy.chowhouse.com (8.12.6/8.12.6) with ESMTP id g8R16Rwk009907; Thu, 26 Sep 2002 19:06:27 -0600 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id g8R16QoJ009904; Thu, 26 Sep 2002 19:06:26 -0600 Date: Thu, 26 Sep 2002 19:06:26 -0600 (MDT) From: James Rich To: Michael Sinz cc: Eric Sandeen , XFS mailing list Subject: Re: restoring after running xfs_repair In-Reply-To: <3D935F01.9040508@wgate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 615 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs On Thu, 26 Sep 2002, Michael Sinz wrote: > This sounds like the IDE-write cache does not flush before power off > problem. There is a "fix" to this in some systems that has the shutdown > process, after syncing/unmounting stuff do a powerdown of the IDE > drives to force them to write their caches before doing a shutdown > of the ATX power supply via APM/APCI. Yes, this seems likely now. After disabling ACPI and APM I noticed a message indicating that the IDE drives are being flushed. I don't think this message was there before. Probably a problem with my dist. (I'm using Slackware - I'll report it there). James Rich From owner-linux-xfs@oss.sgi.com Thu Sep 26 18:03:33 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 18:03:35 -0700 (PDT) Received: from stumpy.chowhouse.com (IDENT:0@stumpy.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8R13WtG026958 for ; Thu, 26 Sep 2002 18:03:33 -0700 Received: from stumpy.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by stumpy.chowhouse.com (8.12.6/8.12.6) with ESMTP id g8R145wk009895; Thu, 26 Sep 2002 19:04:05 -0600 Received: from localhost (james@localhost) by stumpy.chowhouse.com (8.12.6/8.12.6/Submit) with ESMTP id g8R145C9009892; Thu, 26 Sep 2002 19:04:05 -0600 Date: Thu, 26 Sep 2002 19:04:05 -0600 (MDT) From: James Rich To: Eric Sandeen cc: XFS mailing list Subject: Re: restoring after running xfs_repair In-Reply-To: <1033059609.7333.41.camel@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 614 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james@chowhouse.com Precedence: bulk X-list: linux-xfs On 26 Sep 2002, Eric Sandeen wrote: > > No oops or anything. A complete description of the hardware is at > > www.supermicro.com. I did a shutdown -h now and on restarting it the > > machine paniced right after mounting /. The kernel is checked out from > > CVS as of a few days ago. > > So it happened to you -again-? No. I changed the ACPI and APM settings in the BIOS before fixing the filesystem and then built and booted a new kernel after fixing the filesystem. shutdown -h now works fine (though it doesn't turn the machine off - a small problem since it doesn't have a power off switch). It looks like ACPI or APM is the culprit. I can't test any further since I had to put this into production. I could test on different hardware I suppose. James Rich From owner-linux-xfs@oss.sgi.com Thu Sep 26 20:46:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 20:46:44 -0700 (PDT) Received: from area51.underboost.net (mail@dsl-65-188-232-225.telocity.com [65.188.232.225]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8R3kbtG030887 for ; Thu, 26 Sep 2002 20:46:38 -0700 Received: from [192.168.0.77] (helo=localhost.localdomain) by area51.underboost.net with esmtp (Exim 3.36 #1 (Debian)) id 17uPYO-0006GO-00 for ; Wed, 25 Sep 2002 23:43:04 -0400 Subject: scandir and xfs From: Ron Henry To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 26 Sep 2002 23:39:51 -0400 Message-Id: <1033097992.377.12.camel@illuminati> Mime-Version: 1.0 X-archive-position: 616 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dijital1@underboost.net Precedence: bulk X-list: linux-xfs does scandir work under xfs? here is a copy of the code that I'm trying to run that's not working... the printf where I'm printing out the value of j is showing up as 0 no matter what directory is passed to scandir. Am I doing something wrong or is this function deprecated? I've been searching through the kernel source for it, and I can't seem to find it defined anywhere... int main(int argc, char *argv[]) { int j,i; struct dirent **curdir; if(argc != 2){ fprintf(stderr,"guess what you did wrong\n"); exit(1); } if((j=scandir(argv[1], &curdir, 0, alphasort) < 0)) { perror("scandir"); exit(1); } printf("%d\n", j); for(i=0; id_name); free(curdir[i]); } free(curdir); return 0; } thanks... From owner-linux-xfs@oss.sgi.com Thu Sep 26 21:18:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 21:18: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 g8R4IUtG031640 for ; Thu, 26 Sep 2002 21:18:31 -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 XAA47360; Thu, 26 Sep 2002 23:18:25 -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 XAA67303; Thu, 26 Sep 2002 23:18:24 -0500 (CDT) Date: Thu, 26 Sep 2002 23:18:01 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ron Henry cc: linux-xfs@oss.sgi.com Subject: Re: scandir and xfs In-Reply-To: <1033097992.377.12.camel@illuminati> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 617 X-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 Just rearrange your parentheses a bit... --- scandir.c.orig Thu Sep 26 23:12:50 2002 +++ scandir.c Thu Sep 26 23:13:07 2002 @@ -11,7 +11,7 @@ exit(1); } - if((j=scandir(argv[1], &curdir, 0, alphasort) < 0)) { + if((j=scandir(argv[1], &curdir, 0, alphasort)) < 0) { perror("scandir"); exit(1); } I had this same silly bug in a test app this week. :) -Eric On 26 Sep 2002, Ron Henry wrote: > does scandir work under xfs? From owner-linux-xfs@oss.sgi.com Thu Sep 26 21:47:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Sep 2002 21:47:26 -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 g8R4lNtG032299 for ; Thu, 26 Sep 2002 21:47: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 VAA06070 for ; Thu, 26 Sep 2002 21:47:21 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA01672; Fri, 27 Sep 2002 14:46:05 +1000 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id B08693000B8; Fri, 27 Sep 2002 14:46:04 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 532D41093; Fri, 27 Sep 2002 14:46:04 +1000 (EST) X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@sgi.com Cc: linux-kernel@vger.kernel.org Subject: Announce: XFS split patches for 2.4.19 - respin In-Reply-To: Your message of "Tue, 13 Aug 2002 13:04:25 +1000." <10392.1029207865@kao2.melbourne.sgi.com> Date: Fri, 27 Sep 2002 14:45:58 +1000 Message-ID: <23406.1033101958@kao2.melbourne.sgi.com> X-archive-position: 618 X-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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-Type: text/plain; charset=us-ascii ftp://oss.sgi.com/projects/xfs/download/patches/2.4.19. The xfs patches for 2.4.19 have been respun as of 2002-09-27 04:22 UTC. This removes kbuild 2.5 support and includes several changes in the xfs/kernel interface. For some time the XFS group have been producing split patches for XFS, separating the core XFS changes from additional patches such as kdb, xattr, acl, dmapi. The split patches are released to the world with the hope that developers and distributors will find them useful. Read the README in each directory very carefully, the split patch format has changed over a few kernel releases. Any questions that are covered by the README will be ignored. There is even a 2.4.20/README for the terminally impatient :). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Exmh version 2.1.1 10/15/1999 iD8DBQE9k+KFi4UHNye0ZOoRAs+kAKDXP8nweVX+05BEMarcX71ZA2aT0wCeJmfZ +dhYwnuFjukOmuWVyyZBzMM= =HouQ -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Fri Sep 27 02:34:13 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 02:34:14 -0700 (PDT) Received: from bjapp1.163.net ([202.108.255.198]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8R9Y9tG013844 for ; Fri, 27 Sep 2002 02:34:11 -0700 Received: from localhost (localhost [127.0.0.1]) by bjapp1.163.net (Postfix) with SMTP id BDAC11D947F38 for ; Fri, 27 Sep 2002 17:33:59 +0800 (CST) Received: from super_win (unknown [61.177.58.51]) by bjapp1.163.net (Coremail) with SMTP id 6AEAAAQmlD3AJToz.1 for ; Fri, 27 Sep 2002 17:33:59 +0800 (CST) Date: Fri, 27 Sep 2002 17:36:49 +0800 From: =?GB2312?Q?=B9=CB=CE=C4=C7=EC?= Reply-To: guwenqing@163.net To: "linux-xfs@oss.sgi.com" Subject: mark the bad sectors X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Message-Id: <20020927093359.BDAC11D947F38@bjapp1.163.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g8R9YDtG013845 X-archive-position: 619 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: guwenqing@163.net Precedence: bulk X-list: linux-xfs linux-xfshello: Did you have a method to mark the bad sectors.Is there a command or a software? ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡guwenqing@163.net ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡2002-09-27 From owner-linux-xfs@oss.sgi.com Fri Sep 27 03:40:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 03:40:51 -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 g8RAeltG014772 for ; Fri, 27 Sep 2002 03:40:47 -0700 Received: from auto-nb1.xs4all.nl (coltex.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g8RAeMB2038519; Fri, 27 Sep 2002 12:40:28 +0200 (CEST) Message-Id: <4.3.2.7.2.20020927123855.02ce9b60@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Sep 2002 12:39:10 +0200 To: guwenqing@163.net, "linux-xfs@oss.sgi.com" From: Seth Mos Subject: Re: mark the bad sectors In-Reply-To: <20020927093359.BDAC11D947F38@bjapp1.163.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 620 X-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 17:36 27-9-2002 +0800, =?GB2312?Q?=B9=CB=CE=C4=C7=EC?= wrote: >linux-xfshello: > Did you have a method to mark the bad sectors.Is there a command > or a software? No. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Sep 27 08:21:14 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 08:21:16 -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 g8RFLDtG006431 for ; Fri, 27 Sep 2002 08:21:13 -0700 Received: from TAZ2 ([66.156.4.226]) by imf03bis.bellsouth.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with SMTP id <20020927152248.UQUV4688.imf03bis.bellsouth.net@TAZ2>; Fri, 27 Sep 2002 11:22:48 -0400 Date: Fri, 27 Sep 2002 11:19:24 -0400 From: Greg Freemyer Subject: re[2]: using xfs_dump to backup an Oracle DB in hot backup mode. To: Austin Gonyou cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020927152248.UQUV4688.imf03bis.bellsouth.net@TAZ2> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8RFLEtG006432 X-archive-position: 621 X-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 thought Oracle's hot_backup was specifically designed to work with >> > snapshots. >> > >> > I.e. freeze Oracle --> xfs_freeze --> create snapshot --> unfreeze >> > xfs --> unfreeze Oracle >> > >> So the operation described above can be done in a relatively short >> period of time yes? If so, then xfs_freeze won't have to be on long as >> the snapshot would appear as though it were still frozen. In my tests, it takes a minute or less. This is with pure Sept. 3 cvs code as I remember. In my opinion, xfs_freeze is broken with pre-Sept. 3 code. If you want to evaluate my test procedure, look at the xfs QA test 068. That may also be a good source of shell script pieces you can borrow. Note that it does not perform the actual backup, but it does mount the snapshot readonly, before it simply unmounts and goes thru the cycle again. In my tests, I was using, LVM 1.03 userland tools and whatever LVM kernel components that are standard in the 2.4.19 kernel. I have run over 2000 iterations of the 068 test with no glitches. I tested under the heaviest loads I knew how to generate. If you want to run your own tests, it should be relatively easy to modify it to use an Oracle based load, instead of the one I used. >> > Even worse, if you go into hot_backup for an hour or so, and you have >> > a machine crash during this time, your new data is lost!!!! >> I assume you're speaking to the snapshot? I think this is the part that >> confuses me the most. Reading the other response to your question, if you setup Oracle's transaction log on another FS, then the xfs_freeze of the data FS will not be as horrible as I described. I still think the snapshot mechanism is the way to go. >> > If you do want to try to go disk to disk extremely rapidly, you will >> > need to either not use xfs_freeze, on mount your drive with -noatime. >> We already mount with noatime, IOzone tests show it's much faster and >> more consistent to do so. Disk-Disk backup would be ideal in our >> situation, then it preserves the BCV like operation, which is really >> what I'm trying to find out how to do, if I can, with XFS utilities. BCV is not fundamentally a xfs feature. It does require xfs_freeze to be bug free. It is a LVM or EVMS feature, or it can be built into a hardware RAID controller. I have only used LVM with Linux. There are 2 basic ways to do BCVs: snapshots and clones. Unfortunately these terms are not consistently used, but I mean: clone - Create a 3-way mirror, freeze the FS, split off one of the mirrors, unfreeze orig FS, mount split off FS read-only, back it up, unmount it, re-sync the mirror into a 3-way mirror again. snapshot - Instead of using a 3-way mirror, Copy On Write (COW) technology is used, but the high level process is the same. Clones require RAID 1 or RAID 1 + 0. Snapshots can be anything (i.e. JBOD, RAID 0, RAID 1, RAID 1+0, RAID 5). FYI: WIth COW, the snapshot process at the LVM level, causes a LVM data structure to be created with a flag for each LVM block. Initially all flags are set to _original_. Then when a write to FS is performed, LVM checks the flag, if the block being written is still _original_, LVM copies out the block to an unused part of the VG and the flag is changed to mark the block _updated_. The main mount point uses the original set of FS blocks exclusively. The read-only snapshot uses the blocks still flagged _original_, and the copied out blocks for the blocks flagged _updated_. FYI: LVM 2.0 is going to support read/write snapshots. But I don't see a huge value in that for backups. They can be very useful if you want to try a complex DB action, and your not sure of what the results will be. i.e. Create a r/w snapshot, mount it, run DB tests on it, delete the snapshot. HTH 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 Fri Sep 27 08:22:47 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 08:22: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 g8RFMktG006550 for ; Fri, 27 Sep 2002 08:22: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 KAA70729 for ; Fri, 27 Sep 2002 10:22:41 -0500 (CDT) Received: from dhcp212.munich.sgi.com (dhcp212.munich.sgi.com [144.253.197.212]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA89410 for ; Fri, 27 Sep 2002 10:22:40 -0500 (CDT) Received: (from hch@localhost) by dhcp212.munich.sgi.com (8.11.6/8.11.6) id g8RMbRZ04403 for linux-xfs@oss.sgi.com; Fri, 27 Sep 2002 18:37:27 -0400 Resent-Message-Id: <200209272237.g8RMbRZ04403@dhcp212.munich.sgi.com> Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id KAA69593 for ; Fri, 27 Sep 2002 10:18:02 -0500 (CDT) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g8RFI0px24077832 for ; Fri, 27 Sep 2002 08:18:00 -0700 (PDT) Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8RFHK0m001031 for ; Fri, 27 Sep 2002 17:17:20 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g8RFHKfc001030 for hch@sgi.com; Fri, 27 Sep 2002 17:17:20 +0200 Date: Fri, 27 Sep 2002 17:17:20 +0200 Message-Id: <200209271517.g8RFHKfc001030@lab343.munich.sgi.com> Subject: TAKE - More mount cleanups To: undisclosed-recipients:; Resent-From: hch@sgi.com Resent-Date: Fri, 27 Sep 2002 18:37:27 -0400 Resent-To: linux-xfs@oss.sgi.com X-archive-position: 622 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs The mount code should finally be in a shape were I can leave it alone for a while.. Date: Fri Sep 27 08:16:21 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128571a linux/fs/xfs/xfs_vfsops.c - 1.385 - Merge xfs_mount and xfs_cmountfs, cleanup the new xfs_mount. linux/fs/xfs/xfs_mount.h - 1.158 linux/fs/xfs/xfs_mount.c - 1.302 - Add functions to resolve a path to a properly block device. Add functions to deal with buftargs. linux/fs/xfs/linux/xfs_super.h - 1.29 linux/fs/xfs/linux/xfs_super.c - 1.214 - Remove spectodev and spectodevs functions. linux/fs/xfs/pagebuf/page_buf_locking.c - 1.31 linux/fs/xfs/pagebuf/page_buf.h - 1.41 - Remove functions related to allocation, filling and freeing of butargs. From owner-linux-xfs@oss.sgi.com Fri Sep 27 08:43:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 08:43: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 g8RFhatG008182 for ; Fri, 27 Sep 2002 08:43:36 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) 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 IAA04514 for ; Fri, 27 Sep 2002 08:43:35 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8RFgq0m002069; Fri, 27 Sep 2002 17:42:52 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g8RFgq7N002068; Fri, 27 Sep 2002 17:42:52 +0200 Date: Fri, 27 Sep 2002 17:42:52 +0200 Message-Id: <200209271542.g8RFgq7N002068@lab343.munich.sgi.com> Subject: TAKE - I/O path cleanups To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 623 X-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@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Prepare implementing a writepages method in 2.5. There is still some work to do in this area.. Date: Fri Sep 27 08:42:03 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs-iopath The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128581a linux/fs/xfs/linux/xfs_aops.c - 1.6 - Move some more common code into delalloc_convert. Remove release_page/write_full_page wrappers. Merge map_page into convert_page. Small code tidyups. From owner-linux-xfs@oss.sgi.com Fri Sep 27 12:20:15 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 12:20:20 -0700 (PDT) Received: from dr.com (inetwork-161.187.rev.afripa.com [194.9.187.161] (may be forged)) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8RJK9tG018712 for ; Fri, 27 Sep 2002 12:20:12 -0700 Message-Id: <200209271920.g8RJK9tG018712@oss.sgi.com> From: "Dr. coker williams" To: Subject: Invest Assistance Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Date: Fri, 27 Sep 2002 20:11:13 +0100 Reply-To: "Dr. coker williams" X-archive-position: 624 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: williamscoker@dr.com Precedence: bulk X-list: linux-xfs ATTN : President/C.E.O Dear Sir, I am a financial consultant based in Cotonou Benin. I have a client (a widow) she has USDM25,000,000 with a private equity investment trust company for safe keeping only. She wishes to invest in a stable economy . Her interest is in companies with potentials for rapid growth in long terms. My client is interested in placing part of her fund in your company,if your country's bi-laws allows foreign investment. You can contact me for more details via my e-mail address with your reference. Yours faithfully, Dr.Williams Coker NB: The fund is free from drug and laundering related offences. From owner-linux-xfs@oss.sgi.com Fri Sep 27 14:50:46 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 14:50:52 -0700 (PDT) Received: from web40614.mail.yahoo.com (web40614.mail.yahoo.com [66.218.78.151]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8RLoktG020784 for ; Fri, 27 Sep 2002 14:50:46 -0700 Message-ID: <20020927215041.77738.qmail@web40614.mail.yahoo.com> Received: from [208.35.40.2] by web40614.mail.yahoo.com via HTTP; Fri, 27 Sep 2002 14:50:41 PDT Date: Fri, 27 Sep 2002 14:50:41 -0700 (PDT) From: Ravi Wijayaratne Subject: patch to give kmalloc a chance (RFC) To: linux-xfs@oss.sgi.com Cc: sandeen@sgi.com, lord@sgi.com, riel@connectiva.com.br.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 625 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ravi_wija@yahoo.com Precedence: bulk X-list: linux-xfs Hi all, As I indicated On a previous posting we hit a BUG() in fs/xfs/pagebuf/page_buf.c in the following lines. psync = (pagesync_t *) kmalloc(sizeof(pagesync_t), GFP_NOFS); /* Ugh - out of memory condition here */ if(psync == NULL){ BUG(); } in function _pagebuf_page_io(...). (linux-2.4.18 xfs-1.1) The situation occurred in one of our stress tests under heavy I/O load. We were pounding our server with Samba clients. I tried many times to recreate the situation but was unable to do so. May be that is good :), but there is a loop hole here. Kmlloc is called with GFP_NOFS here. Therefore I suggest that we give kmalloc a chance and retry the allocation several times. That way kswapd has some time to free more memory. The following patch does that. Since the failure path cannot be reproduced, I could not test the patch in a real life situation. Some insights are much appreciated. I am not sure whether xfs_support/kmem.c is the proper place for the patch. Thanx Ravi --------0x-------x0-------------- --- linux.orig/fs/xfs/pagebuf/page_buf.c Fri May 31 05:21:04 2002 +++ linux/fs/xfs/pagebuf/page_buf.c Sat Sep 28 23:21:00 2002 @@ -1449,11 +1449,18 @@ if (blk_length != 1) { psync = (pagesync_t *) kmalloc(sizeof(pagesync_t), GFP_NOFS); - /* Ugh - out of memory condition here */ - if (psync == NULL) - BUG(); - + printk(KERN_ALERT "%s:%s:%d Memory allocation failed. Waiting to free\n",+ __FILE__,__FUNCTION__,__LINE__); + if (psync == NULL){ + /* give kmalloc a chance */ + psync=(pagesync_t *)kmem_alloc_wait(sizeof(pagesync_t),GFP_NOFS);+ if(psync == NULL){ + /* increase wait time and try ? */ + /* bail out if failed */ + BUG(); + } + } psync->pb = pb; psync->locking = locking; atomic_set(&psync->remain, 0); --- linux.orig/fs/xfs_support/kmem.c Fri May 31 05:21:05 2002 +++ linux/fs/xfs_support/kmem.c Sat Sep 28 23:04:40 2002 @@ -139,6 +139,47 @@ return rval; } +/* + * in case we run into situations where kmalloc returns + * NULL due to sluggishness of page swapping we will wait + * if we can sleep. + */ + +#define XFS_KMALLOC_MAXTRIES 1000 + +void * +kmem_alloc_wait(size_t size, int flags) +{ + void *ptr=NULL; + unsigned long last_try=0; + int try_cnt=0; + + + /* if size is bigger than max cache size + * kmalloc will return NULL, so we will not + * retry + */ + if(size > MAX_SLAB_SIZE) + return NULL; + /* we wont sleep if we are not supposed to */ + if(!(flags & __GFP_WAIT)) + return kmalloc(size,flags); + while(try_cnt < XFS_KMALLOC_MAXTRIES){ + /* force a sleep first */ + if(try_cnt > 0) + ptr=kmalloc(size,flags); + if(ptr){ + return ptr; + } + if (time_after(jiffies, last_try + 5*HZ)) { + last_try = jiffies; + } + yield(); + try_cnt++; + } +} + + void * kmem_zalloc(size_t size, int flags) { @@ -250,6 +291,7 @@ EXPORT_SYMBOL(kmem_zone_alloc); EXPORT_SYMBOL(kmem_zone_free); EXPORT_SYMBOL(kmem_alloc); +EXPORT_SYMBOL(kmem_alloc_wait); EXPORT_SYMBOL(kmem_realloc); EXPORT_SYMBOL(kmem_zalloc); EXPORT_SYMBOL(kmem_free); ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com From owner-linux-xfs@oss.sgi.com Fri Sep 27 15:00:12 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 15:00:14 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8RM0BtG021309 for ; Fri, 27 Sep 2002 15:00:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA81203; Fri, 27 Sep 2002 17:00:05 -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 RAA74337; Fri, 27 Sep 2002 17:00:05 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8RLsnZ15342; Fri, 27 Sep 2002 16:54:49 -0500 Subject: Re: patch to give kmalloc a chance (RFC) From: Steve Lord To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com, Eric Sandeen , riel@connectiva.com.br.sgi.com In-Reply-To: <20020927215041.77738.qmail@web40614.mail.yahoo.com> References: <20020927215041.77738.qmail@web40614.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 27 Sep 2002 16:54:48 -0500 Message-Id: <1033163688.10533.79.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 626 X-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 I am picturing Rik with shivers going down his spine right now ;-) The better way to deal with this is either to have a small pool of these structures we can fall back on, or even to fail the I/O. The latter will shutdown the filesystem though. I may come up with something else, but I have to dash now. I presume you are running on lvm here? Steve On Fri, 2002-09-27 at 16:50, Ravi Wijayaratne wrote: > Hi all, > > As I indicated On a previous posting we hit a BUG() in > fs/xfs/pagebuf/page_buf.c in the following lines. > > psync = (pagesync_t *) kmalloc(sizeof(pagesync_t), > GFP_NOFS); > /* Ugh - out of memory condition here */ > if(psync == NULL){ > BUG(); > } > > in function _pagebuf_page_io(...). > (linux-2.4.18 xfs-1.1) > The situation occurred in one of our stress tests > under heavy I/O load. We were pounding our server with > Samba clients. I tried many times to recreate the > situation but was unable to do so. May be that is good > :), but there is a loop hole here. Kmlloc is called > with GFP_NOFS here. Therefore I suggest that we give > kmalloc a chance and retry the allocation several > times. That way kswapd has some time to free more > memory. > > The following patch does that. Since the failure path > cannot be reproduced, I could not test the patch in a > real life situation. Some insights are much > appreciated. > > I am not sure whether xfs_support/kmem.c is the proper > place for the patch. > > Thanx > Ravi > > --------0x-------x0-------------- > --- linux.orig/fs/xfs/pagebuf/page_buf.c Fri > May 31 05:21:04 2002 > +++ linux/fs/xfs/pagebuf/page_buf.c Sat Sep 28 > 23:21:00 2002 > @@ -1449,11 +1449,18 @@ > > if (blk_length != 1) { > psync = (pagesync_t *) > kmalloc(sizeof(pagesync_t), GFP_NOFS); > - > /* Ugh - out of memory condition here > */ > - if (psync == NULL) > - BUG(); > - > + printk(KERN_ALERT "%s:%s:%d Memory > allocation failed. Waiting to free\n",+ > __FILE__,__FUNCTION__,__LINE__); > + if (psync == NULL){ > + /* give kmalloc a chance */ > + psync=(pagesync_t > *)kmem_alloc_wait(sizeof(pagesync_t),GFP_NOFS);+ > if(psync == NULL){ > + /* increase wait time > and try ? */ > + /* bail out if failed > */ > + BUG(); > + } > + } > psync->pb = pb; > psync->locking = locking; > atomic_set(&psync->remain, 0); > --- linux.orig/fs/xfs_support/kmem.c Fri May 31 > 05:21:05 2002 > +++ linux/fs/xfs_support/kmem.c Sat Sep 28 23:04:40 > 2002 > @@ -139,6 +139,47 @@ > return rval; > } > > +/* > + * in case we run into situations where kmalloc > returns > + * NULL due to sluggishness of page swapping we will > wait > + * if we can sleep. > + */ > + > +#define XFS_KMALLOC_MAXTRIES 1000 > + > +void * > +kmem_alloc_wait(size_t size, int flags) > +{ > + void *ptr=NULL; > + unsigned long last_try=0; > + int try_cnt=0; > + > + > + /* if size is bigger than max cache size > + * kmalloc will return NULL, so we will not > + * retry > + */ > + if(size > MAX_SLAB_SIZE) > + return NULL; > + /* we wont sleep if we are not supposed to */ > + if(!(flags & __GFP_WAIT)) > + return kmalloc(size,flags); > + while(try_cnt < XFS_KMALLOC_MAXTRIES){ > + /* force a sleep first */ > + if(try_cnt > 0) > + ptr=kmalloc(size,flags); > + if(ptr){ > + return ptr; > + } > + if (time_after(jiffies, last_try + > 5*HZ)) { > + last_try = jiffies; > + } > + yield(); > + try_cnt++; > + } > +} > + > + void * > kmem_zalloc(size_t size, int flags) > { > @@ -250,6 +291,7 @@ > EXPORT_SYMBOL(kmem_zone_alloc); > EXPORT_SYMBOL(kmem_zone_free); > EXPORT_SYMBOL(kmem_alloc); > +EXPORT_SYMBOL(kmem_alloc_wait); > EXPORT_SYMBOL(kmem_realloc); > EXPORT_SYMBOL(kmem_zalloc); > EXPORT_SYMBOL(kmem_free); > > > > > ===== > ------------------------------ > Ravi Wijayaratne > > __________________________________________________ > Do you Yahoo!? > New DSL Internet Access from SBC & Yahoo! > http://sbc.yahoo.com -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Sep 27 15:07:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 15:07:24 -0700 (PDT) Received: from 2-225.ctame701-1.telepar.net.br (teyiot@2-225.ctame701-1.telepar.net.br [200.193.160.225]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8RM7JtG021878 for ; Fri, 27 Sep 2002 15:07:20 -0700 Received: from localhost ([IPv6:::ffff:127.0.0.1]:31431 "EHLO localhost") by imladris.surriel.com with ESMTP id ; Fri, 27 Sep 2002 19:07:00 -0300 Date: Fri, 27 Sep 2002 19:06:57 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Steve Lord cc: Ravi Wijayaratne , , Eric Sandeen Subject: Re: patch to give kmalloc a chance (RFC) In-Reply-To: <1033163688.10533.79.camel@jen.americas.sgi.com> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 627 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: riel@conectiva.com.br Precedence: bulk X-list: linux-xfs On 27 Sep 2002, Steve Lord wrote: > I am picturing Rik with shivers going down his spine right now ;-) Yup ... ;) > The better way to deal with this is either to have a small pool > of these structures we can fall back on, or even to fail the I/O. > The latter will shutdown the filesystem though. Look at the stuff in mm/mempool.c It might be just what you need. Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ Spamtraps of the month: september@surriel.com trac@trac.org From owner-linux-xfs@oss.sgi.com Fri Sep 27 15:52:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 15:52:33 -0700 (PDT) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8RMqRtG023428 for ; Fri, 27 Sep 2002 15:52:27 -0700 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id PAA11107 for ; Fri, 27 Sep 2002 15:52:21 -0700 (PDT) Received: from schumi.digeo.com ([192.168.1.205]) by digeo-nav01.digeo.com (NAVGW 2.5.2.9) with SMTP id M2002092715564201703 ; Fri, 27 Sep 2002 15:56:42 -0700 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by schumi.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Sep 2002 15:52:21 -0700 Received: from digeo.com ([172.17.140.150]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Sep 2002 15:52:20 -0700 Message-ID: <3D94E12C.F0D0FE60@digeo.com> Date: Fri, 27 Sep 2002 15:52:28 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Ravi Wijayaratne , linux-xfs@oss.sgi.com, Eric Sandeen , riel@connectiva.com.br.sgi.com Subject: Re: patch to give kmalloc a chance (RFC) References: <20020927215041.77738.qmail@web40614.mail.yahoo.com> <1033163688.10533.79.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2002 22:52:20.0617 (UTC) FILETIME=[89584F90:01C26678] X-archive-position: 628 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Steve Lord wrote: > > I am picturing Rik with shivers going down his spine right now ;-) > Take a look at __jbd_kmalloc() ;) For a NOFS allocation, simply retrying is a crude-but-effective fix. We have kicked kswapd and kswapd _does_ have __GFP_FS. So things work out, as long as the filesystem doesn't hold locks which would prevent kswapd from being able to reclaim some memory. It's not just a lock ordering thing either - the GFP_NOFS allocator is not able to use the traditional IO-based throttling. It's probably just that there's plenty of writeback in flight but the allocator needs to be more patient. From owner-linux-xfs@oss.sgi.com Fri Sep 27 17:06:58 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 17:07:03 -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 g8S06wtG024485 for ; Fri, 27 Sep 2002 17:06:58 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id EE5E31D6D94; Fri, 27 Sep 2002 17:06:57 -0700 (PDT) Date: Fri, 27 Sep 2002 17:06:57 -0700 From: Chris Wedgwood To: Andrew Morton Cc: Steve Lord , Ravi Wijayaratne , linux-xfs@oss.sgi.com, Eric Sandeen , riel@connectiva.com.br.sgi.com Subject: Re: patch to give kmalloc a chance (RFC) Message-ID: <20020928000657.GA20839@tapu.f00f.org> References: <20020927215041.77738.qmail@web40614.mail.yahoo.com> <1033163688.10533.79.camel@jen.americas.sgi.com> <3D94E12C.F0D0FE60@digeo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D94E12C.F0D0FE60@digeo.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 629 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 27, 2002 at 03:52:28PM -0700, Andrew Morton wrote: > For a NOFS allocation, simply retrying is a crude-but-effective fix. > We have kicked kswapd and kswapd _does_ have __GFP_FS. I wondered about this... and sleeping briefly isn't a bad if it penalizes the memory hog processes (sure, this isn't guaranteed but one hopes it happens more often than not). > So things work out, as long as the filesystem doesn't hold locks > which would prevent kswapd from being able to reclaim some memory. What about swapping to a file on the fs? Might this not be such a lock? --cw From owner-linux-xfs@oss.sgi.com Fri Sep 27 17:10:53 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 17:10:54 -0700 (PDT) Received: from packet.digeo.com (packet.digeo.com [12.110.80.53]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8S0AqtG024958 for ; Fri, 27 Sep 2002 17:10:52 -0700 Received: from digeo-nav01.digeo.com (digeo-nav01.digeo.com [192.168.1.233]) by packet.digeo.com (8.9.3+Sun/8.9.3) with SMTP id RAA13556 for ; Fri, 27 Sep 2002 17:10:46 -0700 (PDT) Received: from schumi.digeo.com ([192.168.1.205]) by digeo-nav01.digeo.com (NAVGW 2.5.2.9) with SMTP id M2002092717150814742 ; Fri, 27 Sep 2002 17:15:08 -0700 Received: from pao-ex01.pao.digeo.com ([172.17.144.34]) by schumi.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Sep 2002 17:10:46 -0700 Received: from digeo.com ([172.17.140.150]) by pao-ex01.pao.digeo.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 27 Sep 2002 17:10:45 -0700 Message-ID: <3D94F38D.DD04A46E@digeo.com> Date: Fri, 27 Sep 2002 17:10:53 -0700 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre4 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Wedgwood CC: Steve Lord , Ravi Wijayaratne , linux-xfs@oss.sgi.com, Eric Sandeen , riel@connectiva.com.br.sgi.com Subject: Re: patch to give kmalloc a chance (RFC) References: <20020927215041.77738.qmail@web40614.mail.yahoo.com> <1033163688.10533.79.camel@jen.americas.sgi.com> <3D94E12C.F0D0FE60@digeo.com> <20020928000657.GA20839@tapu.f00f.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Sep 2002 00:10:45.0432 (UTC) FILETIME=[7DA21B80:01C26683] X-archive-position: 630 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@digeo.com Precedence: bulk X-list: linux-xfs Chris Wedgwood wrote: > > ... > > So things work out, as long as the filesystem doesn't hold locks > > which would prevent kswapd from being able to reclaim some memory. > > What about swapping to a file on the fs? Might this not be such a > lock? > Probably. swapfiles are quite prone to oom deadlocks in 2.4. In 2.5, swapfiles are just as robust as raw swapdevices. From owner-linux-xfs@oss.sgi.com Fri Sep 27 17:26:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 17:26:20 -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 g8S0QGtG025510 for ; Fri, 27 Sep 2002 17:26:17 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 56E6D14360; Sat, 28 Sep 2002 02:26:11 +0200 (MEST) Date: Sat, 28 Sep 2002 02:26:10 +0200 From: Andi Kleen To: Steve Lord Cc: Eric Sandeen , Michael Best , linux-xfs@oss.sgi.com Subject: Re: XFS allows expansions, but no contraction? Message-ID: <20020928022610.A9796@wotan.suse.de> References: <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> <1033072540.5423.17.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033072540.5423.17.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 631 X-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 > Probably an extension of the xfs_fsr approach would be the way to > go. One major issue is it is impossible to do this without changing > inode numbers. Some applications rely on inode numbers remaining a > constant. But none I know do this over umount/remount (ok except for NFS stateless filehandles, but that can be cured by remounting on the client too) So when you limit yourself to doing the shrinking offline (which I think would be ok for most users) then this would be no problem. I guess adding hot-shrinking would be a locking nightmare anyways, because one would need to add checks everywhere in the fs that the blocks it just allocated didn't go away ... -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 27 17:43:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 17:43:22 -0700 (PDT) Received: from questra.com (IDENT:qmailr@ns1.questra.com [64.132.48.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8S0hHtG026063 for ; Fri, 27 Sep 2002 17:43:17 -0700 Received: (qmail 19128 invoked from network); 28 Sep 2002 00:43:16 -0000 Received: from hades.roc.questra.com (HELO questra.com) (64.132.48.226) by ns1.questra.com with SMTP; 28 Sep 2002 00:43:16 -0000 Received: (qmail 8227 invoked from network); 28 Sep 2002 00:43:16 -0000 Received: from odio.roc.questra.com (10.20.8.26) by hades.roc.questra.com with SMTP; 28 Sep 2002 00:43:16 -0000 Received: (from mcdermot@localhost) by odio.roc.questra.com (8.11.6/8.11.4) id g8S0hGw01831 for linux-xfs@oss.sgi.com; Fri, 27 Sep 2002 20:43:16 -0400 Date: Fri, 27 Sep 2002 20:43:16 -0400 From: Scott McDermott To: linux-xfs@oss.sgi.com Subject: Re: XFS allows expansions, but no contraction? Message-ID: <20020927204316.F8288@questra.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> <1033072540.5423.17.camel@jen.americas.sgi.com> <20020928022610.A9796@wotan.suse.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: <20020928022610.A9796@wotan.suse.de>; from ak@suse.de on Sat, Sep 28, 2002 at 02:26:10AM +0200 X-archive-position: 632 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mcdermot@questra.com Precedence: bulk X-list: linux-xfs Andi Kleen on Sat 28/09 02:26 +0200: > > Probably an extension of the xfs_fsr approach would be the way to > > go. One major issue is it is impossible to do this without changing > > inode numbers. Some applications rely on inode numbers remaining a > > constant. > > But none I know do this over umount/remount (ok except for NFS > stateless filehandles, but that can be cured by remounting on the > client too) yeah right, you have XFS for /home/ and you want to tell your hundreds of LAN clients to remount? That is totally impractical. the inodes have to remain constant to be realistic...NFS cookies aren't the only thing that uses them (although I can't think of anything else that would care ;) From owner-linux-xfs@oss.sgi.com Fri Sep 27 18:16:29 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 18:16:31 -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 g8S1GStG026733 for ; Fri, 27 Sep 2002 18:16:29 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 3BA5B14754 for ; Sat, 28 Sep 2002 03:16:23 +0200 (MEST) Date: Sat, 28 Sep 2002 03:16:22 +0200 From: Andi Kleen To: linux-xfs@oss.sgi.com Subject: Re: XFS allows expansions, but no contraction? Message-ID: <20020928031622.A19263@wotan.suse.de> References: <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> <1033072540.5423.17.camel@jen.americas.sgi.com> <20020928022610.A9796@wotan.suse.de> <20020927204316.F8288@questra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020927204316.F8288@questra.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 633 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Fri, Sep 27, 2002 at 08:43:16PM -0400, Scott McDermott wrote: > Andi Kleen on Sat 28/09 02:26 +0200: > > > Probably an extension of the xfs_fsr approach would be the way to > > > go. One major issue is it is impossible to do this without changing > > > inode numbers. Some applications rely on inode numbers remaining a > > > constant. > > > > But none I know do this over umount/remount (ok except for NFS > > stateless filehandles, but that can be cured by remounting on the > > client too) > > yeah right, you have XFS for /home/ and you want to tell your hundreds > of LAN clients to remount? That is totally impractical. /home by definition never shrinks ... Also would you prefer to have no shrinking to shrinking with changed inode numbers ? -Andi From owner-linux-xfs@oss.sgi.com Fri Sep 27 22:03:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 22:03:06 -0700 (PDT) Received: from mx02.cluster1.charter.net (dc-mx02.cluster1.charter.net [209.225.8.12]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8S52xtG002827 for ; Fri, 27 Sep 2002 22:02:59 -0700 Received: from [216.207.95.43] (HELO localhost.localdomain) by mx02.cluster1.charter.net (CommuniGate Pro SMTP 3.5.3) with ESMTP id 8446112 for linux-xfs@oss.sgi.com; Sat, 28 Sep 2002 01:02:53 -0400 Content-Type: text/plain; charset="us-ascii" From: Raymond To: linux-xfs@oss.sgi.com Subject: Suse 8.1 and XFS 1.1 Date: Fri, 27 Sep 2002 22:01:32 -0700 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200209272201.32561.support@bigriverinfotech.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8S534tG002828 X-archive-position: 634 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: support@bigriverinfotech.com Precedence: bulk X-list: linux-xfs Does anybody know if SuSE 8.1 will include XFS 1.1 ? Raymond From owner-linux-xfs@oss.sgi.com Fri Sep 27 22:28:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 22:28:51 -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 g8S5SntG004128 for ; Fri, 27 Sep 2002 22:28:49 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id DE5411D80E3; Fri, 27 Sep 2002 22:28:48 -0700 (PDT) Date: Fri, 27 Sep 2002 22:28:48 -0700 From: Chris Wedgwood To: Raymond Cc: linux-xfs@oss.sgi.com Subject: Re: Suse 8.1 and XFS 1.1 Message-ID: <20020928052848.GA23028@tapu.f00f.org> References: <200209272201.32561.support@bigriverinfotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209272201.32561.support@bigriverinfotech.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 635 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 27, 2002 at 10:01:32PM -0700, Raymond wrote: > Does anybody know if SuSE 8.1 will include XFS 1.1 ? http://www.suse.com/us/private/products/suse_linux/i386/new_features.html File system: * 4 journaling file systems: ReiserFS, Ext3, jfs, XFS * Soft RAID for more data security * Resizing of FAT32 partitions * Crypto file system * Logical Volume Manager * ACL Support: Ext2, Ext3, JFS, XFS ^^^ --cw From owner-linux-xfs@oss.sgi.com Fri Sep 27 23:17:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Sep 2002 23:17:44 -0700 (PDT) Received: from dc-mx04.cluster1.charter.net (dc-mx04.cluster1.charter.net [209.225.8.14]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8S6HftG005678 for ; Fri, 27 Sep 2002 23:17:42 -0700 Received: from [216.207.95.43] (HELO localhost.localdomain) by dc-mx04.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 13021761 for linux-xfs@oss.sgi.com; Sat, 28 Sep 2002 02:17:34 -0400 Content-Type: text/plain; charset="iso-8859-1" From: Raymond To: linux-xfs@oss.sgi.com Subject: Re[2]: Suse 8.1 and XFS 1.1 Date: Fri, 27 Sep 2002 23:16:06 -0700 User-Agent: KMail/1.4.1 References: <200209272201.32561.support@bigriverinfotech.com> <20020928052848.GA23028@tapu.f00f.org> In-Reply-To: <20020928052848.GA23028@tapu.f00f.org> MIME-Version: 1.0 Message-Id: <200209272316.06050.support@bigriverinfotech.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8S6HgtG005679 X-archive-position: 636 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: support@bigriverinfotech.com Precedence: bulk X-list: linux-xfs How 'bout Redhat 8.0 and Debian Woody? From owner-linux-xfs@oss.sgi.com Sat Sep 28 00:59:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Sep 2002 00:59:48 -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 g8S7xgtG007098 for ; Sat, 28 Sep 2002 00:59:42 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id 80F6D1D8101; Sat, 28 Sep 2002 00:59:42 -0700 (PDT) Date: Sat, 28 Sep 2002 00:59:42 -0700 From: Chris Wedgwood To: Raymond Cc: linux-xfs@oss.sgi.com Subject: Re: Re[2]: Suse 8.1 and XFS 1.1 Message-ID: <20020928075942.GA23934@tapu.f00f.org> References: <200209272201.32561.support@bigriverinfotech.com> <20020928052848.GA23028@tapu.f00f.org> <200209272316.06050.support@bigriverinfotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209272316.06050.support@bigriverinfotech.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 637 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: linux-xfs On Fri, Sep 27, 2002 at 11:16:06PM -0700, Raymond wrote: > How 'bout Redhat 8.0 and Debian Woody? Debian has had support for XFS for a while in a sense (ie. it's a pain to install XFS root filesystem but otherwise not too bad). There are XFS install disks for Debian that have been floating about for about a year or so too. http://people.debian.org/~blade/XFS-Install/ seems to contain relevant information. No idea about Redhat ... FWIW, I run Debian across about 20 machines and they are almost all XFS, *none* of these required anything special to install, I just made a kernel to my liking with nfsroot support and booted the machines via nfsroot where I could then install the OS over the network pretty much automatically. This means each machine takes about 30 minutes to install, 25 of which I don't need to attend. The only slightly tricky one was my laptop because it didn't have builtin networking... --cw From owner-linux-xfs@oss.sgi.com Sat Sep 28 13:47:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Sep 2002 13:48:01 -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 g8SKlwtG012681 for ; Sat, 28 Sep 2002 13:47:59 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id CAAC914547; Sat, 28 Sep 2002 22:47:52 +0200 (MEST) Date: Sat, 28 Sep 2002 22:47:50 +0200 From: Andi Kleen To: Raymond Cc: linux-xfs@oss.sgi.com Subject: Re: Suse 8.1 and XFS 1.1 Message-ID: <20020928224750.A16798@wotan.suse.de> References: <200209272201.32561.support@bigriverinfotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200209272201.32561.support@bigriverinfotech.com> User-Agent: Mutt/1.3.22.1i X-archive-position: 638 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ak@suse.de Precedence: bulk X-list: linux-xfs On Fri, Sep 27, 2002 at 10:01:32PM -0700, Raymond wrote: > Does anybody know if SuSE 8.1 will include XFS 1.1 ? Yes it does. The XFS in SuSE 8.0 was also nearly 1.1 level (only a few minor changes missing) -Andi From owner-linux-xfs@oss.sgi.com Sat Sep 28 19:53:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Sep 2002 19:53:23 -0700 (PDT) Received: from questra.com (IDENT:qmailr@ns1.questra.com [64.132.48.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8T2rJtG018232 for ; Sat, 28 Sep 2002 19:53:20 -0700 Received: (qmail 31170 invoked from network); 29 Sep 2002 02:53:19 -0000 Received: from hades.roc.questra.com (HELO questra.com) (64.132.48.226) by ns1.questra.com with SMTP; 29 Sep 2002 02:53:19 -0000 Received: (qmail 29655 invoked from network); 29 Sep 2002 02:53:19 -0000 Received: from odio.roc.questra.com (10.20.8.26) by hades.roc.questra.com with SMTP; 29 Sep 2002 02:53:19 -0000 Received: (from mcdermot@localhost) by odio.roc.questra.com (8.11.6/8.11.4) id g8T2rII26353 for linux-xfs@oss.sgi.com; Sat, 28 Sep 2002 22:53:18 -0400 Date: Sat, 28 Sep 2002 22:53:18 -0400 From: Scott McDermott To: linux-xfs@oss.sgi.com Subject: Re: XFS allows expansions, but no contraction? Message-ID: <20020928225318.G8288@questra.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3D936DFA.5060900@emergence.com> <1033072376.17558.3.camel@stout.americas.sgi.com> <1033072540.5423.17.camel@jen.americas.sgi.com> <20020928022610.A9796@wotan.suse.de> <20020927204316.F8288@questra.com> <20020928031622.A19263@wotan.suse.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: <20020928031622.A19263@wotan.suse.de>; from ak@suse.de on Sat, Sep 28, 2002 at 03:16:22AM +0200 X-archive-position: 639 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mcdermot@questra.com Precedence: bulk X-list: linux-xfs Andi Kleen on Sat 28/09 03:16 +0200: > > yeah right, you have XFS for /home/ and you want to tell your > > hundreds of LAN clients to remount? That is totally impractical. > > /home by definition never shrinks ... what definition? what if admin has /export/something and /export/home on different filesystems (same disk), /export/something starts nearing capacity, and he has plenty of room in /export/home to give to it? > Also would you prefer to have no shrinking to shrinking with changed > inode numbers ? I suppose a feature with a limitation is better than no feature. I think XFS is pretty heavily used for things like /export and such a feature wouldn't be very useful with changing inode numbers, but you're right that it would still be useful for some applications. From owner-linux-xfs@oss.sgi.com Sat Sep 28 23:48:16 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Sep 2002 23:48:19 -0700 (PDT) Received: from localhost (12-248-255-165.client.attbi.com [12.248.255.165]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8T6mFtG012539 for ; Sat, 28 Sep 2002 23:48:15 -0700 Received: (qmail 56721 invoked by uid 1000); 29 Sep 2002 06:48:09 -0000 Date: Sun, 29 Sep 2002 01:48:09 -0500 From: "Corey G." To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: slow performance with 2.4.19 and debian (SOLUTION FOUND) Message-ID: <20020929064809.GA56478@attbi.com> References: <20020926001016.GA7003@attbi.com> 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: 640 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctgaff@attbi.com Precedence: bulk X-list: linux-xfs After 17 hours and 10 or so compilations, I started to look at the problem from another angle. Hard to believe, but here is the solution to the problem. Thanks to everyone who thought it might be a DMA issue!! I never would have guessed that a system could be so slow without properly tuned drives. hdparm -m 8 -d 1 -u 1 -c 1 /dev/hda Best Regards, Corey O Wed, Sep 25, 2002 at 09:18:01PM -0500, Eric Sandeen wrote: > Hi Corey - > > Just off the top of my head, you could try the snapshot patch from: > > ftp://oss.sgi.com/projects/xfs/download/patches/weekly-snapshot-patch/ > > and see if this is any better (it's more recent). Maybe we'll get lucky... > > -Eric > > On Wed, 25 Sep 2002, Corey G. wrote: > > > The patch came from xfs.org site for 2.4.19: > > > > xfs-2.4.19-all-i386.bz2 > > > ---end quoted text--- From owner-linux-xfs@oss.sgi.com Sun Sep 29 03:03:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 03:03:44 -0700 (PDT) Received: from hd315.gov.cn ([211.101.228.166]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TA3dtG028222 for ; Sun, 29 Sep 2002 03:03:40 -0700 Date: Sun, 29 Sep 2002 03:03:39 -0700 Message-Id: <200209291003.g8TA3dtG028222@oss.sgi.com> Received: (eyou send program); Sun, 29 Sep 2002 18:03:06 +0800 From: web@hd315.gov.cn To: "ÒµÎñ²¿" Subject: Re: Meeting notice X-archive-position: 641 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: web@hd315.gov.cn Precedence: bulk X-list: linux-xfs ÏÈÉú/Ůʿ£º ÄúºÃ£¬ ÄúµÄÀ´ÐÅÒÔ¾­ÊÕµ½£¬°ìÀíºóÎÒÃǽ«¾¡¿ìÓëÄúÁªÏµ£¡ From owner-linux-xfs@oss.sgi.com Sun Sep 29 05:23:21 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 05:23:27 -0700 (PDT) Received: from brisant-mail.com (80-26-61-100.uc.nombres.ttd.es [80.26.61.100]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TCNJtG002196 for ; Sun, 29 Sep 2002 05:23:20 -0700 Message-Id: <200209291223.g8TCNJtG002196@oss.sgi.com> From: "schneckchen" To: linux-xfs@oss.sgi.com Subject: Ich bin`s Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sun, 29 Sep 2002 13:18:52 X-archive-position: 642 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: schneckchen@brisant-mail.com Precedence: bulk X-list: linux-xfs Hallo, ....danke für Dein Mail. Ist schon `ne Weile her. Nun ja, bist Du immer noch allein? Einsam? Ich auch. Obwohl Freunde von mir sagen, dass ich recht gut aussehe, fehlt mir doch noch ein netter Partner zum Reden, Lieben und Kuscheln. Vielleicht bist Du es. Dein Alter und Dein Aussehen ist für mich nicht so wichtig. Im Moment spanne ich einige Tage aus, lasse die Seele baumeln-, versuche nach Enttäuschungen mein Leben neu zu ordnen. Ich habe mich bei http://www.singles-contacts.com eingetragen. Du findest ein Foto und meine Wohnungsanschrift mit normaler Telefonnummer unter der Rubrik "Sie sucht Ihn". Wenn ich Dir gefallen sollte, rufe mich doch einfach einmal an. Ich freue mich auf ein Gespräch mit Dir. Bis bald Dein Schneckchen From owner-linux-xfs@oss.sgi.com Sun Sep 29 08:57:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 08:57:43 -0700 (PDT) Received: from ns1.ns1.nabitel.com ([211.218.242.252]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TFvCtG004616 for ; Sun, 29 Sep 2002 08:57:26 -0700 Received: from mail pickup service by ns1.ns1.nabitel.com with Microsoft SMTPSVC; Mon, 30 Sep 2002 00:48:22 +0900 Reply-To: From: To: Subject: (ad)Strong WebRobot/eMailId Collector: Free Download ! Date: Mon, 30 Sep 2002 00:48:18 +0900 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 29 Sep 2002 15:48:22.0928 (UTC) FILETIME=[A4208100:01C267CF] Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Content-length: 1890 X-archive-position: 643 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: herald@ns1.nabitel.com Precedence: bulk X-list: linux-xfs Sorry for interrupting you - click refuse for no more mail...=20=09 =A1=A1=20=09 - Welcome to NabiTel's software products and portal services -=20=09 Software Products=20=09 =20 Web Robot: also called web spider or web crawler, collects useful web page informations by navigating world wide web sites.=20 Download free trial version now ! =20 eMail ID Collector: Collects email ids publicly opened on various web pages.=20 Download free trial version now ! =20 Portal Services=20=09 Web Portal: Do you have your own home page and want to broadcast it all over the world ? Register your home page to NabiTel Portal Now !! (nabi=3Da butterfly) Register your home page now, it's free ! =20 Automobiles: Do you want to sell or buy automobiles ? Cars, trucks, limos, airplanes, ships,.... All That Cars are here ! Register your vehicles now, it's free ! =20 Computers: Do you want to sell or buy computers ? PCs, printers, scanners, servers, mainframes, .... All That Computers are here !=20 Register your computers now, it's free ! =20 =20=20=09 Food & Restaurants: Are you seeking for a nice place to eat ? Or do you run a restaurant ? Foods of the world, restaurants of the world, .... All That Foods are here !=20 Register your restaurant now, it's free ! =20 Have a nice day. Thank you.=20=09 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Sep 29 13:42:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 13:42:28 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TKgMtG008998 for ; Sun, 29 Sep 2002 13:42:22 -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 PAA72567 for ; Sun, 29 Sep 2002 15:42:16 -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 PAA18742 for ; Sun, 29 Sep 2002 15:42:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8TKafX26151; Sun, 29 Sep 2002 15:36:41 -0500 Message-Id: <200209292036.g8TKafX26151@jen.americas.sgi.com> Date: Sun, 29 Sep 2002 15:36:41 -0500 Subject: TAKE - xfs argument parsing cleanup X-archive-position: 644 X-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 bring the 32 bit inode flag back into line with the Irix version. Change the bit used for the flag, and pass it in from the mount arguments rather than setting it at a lower level. Date: Sun Sep 29 13:41:49 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128653a linux/fs/xfs/xfs_vfsops.c - 1.386 - turn on 32 bit inode behavior from the mount arguments linux/fs/xfs/xfs_clnt.h - 1.35 - change the bit used for XFSMNT_32BITINODES to be the same as Irix linux/fs/xfs/linux/xfs_super.c - 1.215 - add the 32 bit inode flag to the mount arguments From owner-linux-xfs@oss.sgi.com Sun Sep 29 14:29:38 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 14:29:44 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TLTctG010199 for ; Sun, 29 Sep 2002 14:29:38 -0700 Received: from SHIVA (shiva.sc.tlinx.org [192.168.3.20]) by ishtar.tlinx.org (8.12.2/8.12.2/SuSE Linux 0.6) with SMTP id g8TLTV3G018608 for ; Sun, 29 Sep 2002 14:29:32 -0700 From: "L A Walsh" To: Subject: block size in XFS = hard coded constant? Date: Sun, 29 Sep 2002 14:28:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 645 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs I wanted to use an alternate block size on my SCSI hard disk. I did a low-level reformat to use 4096 and got an additional 10.3% in hard disk space. (17783MB -> 19627). I can't think of a reason why I'd want to have a 512 byte block when the smallest allocation unit on a disk is 4K. However -- I ran into a hard coded reason with XFS -- it's hard coded to use 512 byte blocks. Is there a reason for this? Am I missing something? Is it a bug, or is there some reason why xfs can't handle different sized blocks? -l From owner-linux-xfs@oss.sgi.com Sun Sep 29 15:01:04 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 15:01:07 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TM13tG010842 for ; Sun, 29 Sep 2002 15:01:03 -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 RAA96679; Sun, 29 Sep 2002 17:00:57 -0500 (CDT) Received: from [192.168.1.100] (cf-vpn-sw-corp-64-22.corp.sgi.com [134.15.64.22]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id RAA73820; Sun, 29 Sep 2002 17:00:57 -0500 (CDT) Subject: Re: block size in XFS = hard coded constant? From: Stephen Lord To: L A Walsh Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 29 Sep 2002 16:59:06 -0500 Message-Id: <1033336748.1088.4.camel@laptop.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 646 X-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 Sun, 2002-09-29 at 16:28, L A Walsh wrote: > I wanted to use an alternate block size on my SCSI hard disk. > > I did a low-level reformat to use 4096 and got an additional 10.3% in hard > disk space. (17783MB -> 19627). > > I can't think of a reason why I'd want to have a 512 byte block when the > smallest allocation unit on a disk is 4K. > > However -- I ran into a hard coded reason with XFS -- it's hard coded to use > 512 byte blocks. > > Is there a reason for this? Am I missing something? Is it a bug, or is there > some reason why xfs can't handle different sized blocks? > > -l > Its pretty hard coded in the code that the disk is addressed in 512 byte sectors. Changing this has been discussed, but it is more complex than just changing a constant in the code. The original design while very scalable, did not consider sector sizes over than 512 as being a possibility. Note that this is not the filesystem block size, most metadata is 4K in size by default. Steve From owner-linux-xfs@oss.sgi.com Sun Sep 29 15:09:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 15:09:59 -0700 (PDT) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8TM9utG011362 for ; Sun, 29 Sep 2002 15:09:56 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NWHQ131K; Fri, 27 Sep 2002 14:00:58 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g8RI3dw07066; Fri, 27 Sep 2002 14:03:39 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3D949D7B.1000508@wgate.com> Date: Fri, 27 Sep 2002 14:03:39 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1b) Gecko/20020813 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Rich CC: Eric Sandeen , XFS mailing list Subject: Re: restoring after running xfs_repair References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 647 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs James Rich wrote: > On Thu, 26 Sep 2002, Michael Sinz wrote: > > >>This sounds like the IDE-write cache does not flush before power off >>problem. There is a "fix" to this in some systems that has the shutdown >>process, after syncing/unmounting stuff do a powerdown of the IDE >>drives to force them to write their caches before doing a shutdown >>of the ATX power supply via APM/APCI. > > > Yes, this seems likely now. After disabling ACPI and APM I noticed a > message indicating that the IDE drives are being flushed. I don't think > this message was there before. Probably a problem with my dist. (I'm > using Slackware - I'll report it there). Note that a message that says they are being flush does not mean that they actually are - many (most) current IDE drives don't actually flush or sync when you tell them unless you tell them to spin down/power off. (At the drive level) This is why many distros are now not only doing the flush/sync command to the drives but then also doing a powerdown to the drives before hitting the ATX power (APM/ACPI). Many others has significant loss due to the power supply turning off faster than the drives had a chance to write their 1M/2M/8M buffers back to disk. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Sun Sep 29 17:41:27 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 17:41:33 -0700 (PDT) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8U0fQtG013358 for ; Sun, 29 Sep 2002 17:41:27 -0700 Received: from user-1121o49.dialup.mindspring.com ([66.32.224.137]) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 17vocq-0006wj-00 for linux-xfs@oss.sgi.com; Sun, 29 Sep 2002 20:41:28 -0400 Subject: Newer RH kernels? From: Chris Weyl To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 29 Sep 2002 19:51:15 -0500 Message-Id: <1033347075.6705.21.camel@athena> Mime-Version: 1.0 X-archive-position: 648 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cweyl@mindspring.com Precedence: bulk X-list: linux-xfs Quick question -- Has anyone recompiled newer RH kernels (e.g. 2.4.18-10-RH) with XFS code? If so, a pointer would be greatly appreciated:-) Thanks- -Chris From owner-linux-xfs@oss.sgi.com Sun Sep 29 21:32:00 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 21:32:06 -0700 (PDT) Received: from web8101.in.yahoo.com (web8101.mail.in.yahoo.com [203.199.70.28]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8U4VutG022650 for ; Sun, 29 Sep 2002 21:31:58 -0700 Message-ID: <20020930043149.43337.qmail@web8101.in.yahoo.com> Received: from [202.179.64.2] by web8101.mail.in.yahoo.com via HTTP; Mon, 30 Sep 2002 05:31:49 BST Date: Mon, 30 Sep 2002 05:31:49 +0100 (BST) From: =?iso-8859-1?q?ninad=20purohit?= Subject: ppp patch for redhat 7.3 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 453 X-archive-position: 649 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ninadpurohit@yahoo.co.in Precedence: bulk X-list: linux-xfs hi i use a redhat 7.3 system with xfs file system i need to use a vpn connection that uses pptp the ppp-mppe patch i have works fine with 2.4.18 but doesnot work at all with 2.4.18-3_sgi-xfs kernel , i tried to compile the kernel manually but there seems to be a problem with the source as well pls tell me where can i find a patch Yahoo! Properties Special Buy, sell, rent...your flat, or even post an ad [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Sep 29 21:43:23 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 21:43:25 -0700 (PDT) Received: from web8005.mail.in.yahoo.com (web8005.mail.in.yahoo.com [203.199.70.65]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8U4hJtG023282 for ; Sun, 29 Sep 2002 21:43:21 -0700 Message-ID: <20020930044311.97359.qmail@web8005.mail.in.yahoo.com> Received: from [203.200.70.152] by web8005.mail.in.yahoo.com via HTTP; Mon, 30 Sep 2002 05:43:11 BST Date: Mon, 30 Sep 2002 05:43:11 +0100 (BST) From: =?iso-8859-1?q?munro=20munro?= Subject: xfs file system resize To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 650 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mun_ind@yahoo.co.in Precedence: bulk X-list: linux-xfs xfs_growfs is not working properly. Tried with 2.4.18. No ioctl() for the divice ... error observed. - mun ________________________________________________________________________ Missed your favourite TV serial last night? Try the new, Yahoo! TV. visit http://in.tv.yahoo.com From owner-linux-xfs@oss.sgi.com Sun Sep 29 21:59:02 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 21:59:06 -0700 (PDT) Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8U4x1tG024098 for ; Sun, 29 Sep 2002 21:59:01 -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 XAA87865; Sun, 29 Sep 2002 23:58:55 -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 XAA60939; Sun, 29 Sep 2002 23:58:55 -0500 (CDT) Date: Sun, 29 Sep 2002 23:58:04 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?iso-8859-1?q?munro=20munro?= cc: linux-xfs@oss.sgi.com Subject: Re: xfs file system resize In-Reply-To: <20020930044311.97359.qmail@web8005.mail.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 651 X-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 What architecture are you running on, and can you run the growfs through strace, so that we can see which ioctl failed? Oh, and what version of xfsprogs are you using... -Eric On Mon, 30 Sep 2002, munro munro wrote: > xfs_growfs is not working properly. Tried with 2.4.18. > No ioctl() for the divice ... error observed. > > - mun > > ________________________________________________________________________ > Missed your favourite TV serial last night? Try the new, Yahoo! TV. > visit http://in.tv.yahoo.com > > From owner-linux-xfs@oss.sgi.com Sun Sep 29 22:03:48 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Sep 2002 22:03:50 -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 g8U53ltG024622 for ; Sun, 29 Sep 2002 22:03:47 -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 AAA97987; Mon, 30 Sep 2002 00:03:42 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.8) with ESMTP id AAA75316; Mon, 30 Sep 2002 00:03:41 -0500 (CDT) Date: Mon, 30 Sep 2002 00:02:50 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?iso-8859-1?q?ninad=20purohit?= cc: linux-xfs@oss.sgi.com Subject: Re: ppp patch for redhat 7.3 In-Reply-To: <20020930043149.43337.qmail@web8101.in.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 652 X-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 took a look at the patch you're talking about, (if I found the right one) and I don't think it touches any files that have anything to do with XFS. If you can offer more details on "the problem with the source" we may be able to help more. However, I don't think this is an XFS issue. -Eric On Mon, 30 Sep 2002, ninad purohit wrote: > > hi > > i use a redhat 7.3 system with xfs file system > > i need to use a vpn connection that uses pptp > > the ppp-mppe patch i have works fine with 2.4.18 but doesnot work at all with 2.4.18-3_sgi-xfs kernel , > > i tried to compile the kernel manually but there seems to be a problem with the source as well > > pls tell me where can i find a patch > > Yahoo! Properties Special Buy, sell, rent...your flat, or even post an ad > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Mon Sep 30 01:56:22 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 01:56:23 -0700 (PDT) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.58.33]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8U8uLtG003020 for ; Mon, 30 Sep 2002 01:56:21 -0700 Received: from SHIVA (shiva.sc.tlinx.org [192.168.3.20]) by ishtar.tlinx.org (8.12.2/8.12.2/SuSE Linux 0.6) with SMTP id g8U8uG3G022128; Mon, 30 Sep 2002 01:56:16 -0700 From: "L A Walsh" To: "Stephen Lord" Cc: "Linux-Xfs" , "Linux-Kernel" , "Linux-Fsdevel" Subject: RE: block size in XFS = hard coded constant? Date: Mon, 30 Sep 2002 01:55:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1033336748.1088.4.camel@laptop.americas.sgi.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 653 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: law@tlinx.org Precedence: bulk X-list: linux-xfs Right -- I know it isn't the filesystem block size. In this day and age, it seems anachronistic. Given the 10% higher block density, not only would it yield higher capacities, but should yield higher transfer rates, no? I know it isn't a simple constant switch -- but I wouldn't want to switch constants since not all disks should be constrained to the same block size. Do other file systems have the same limitation? Are there any problems in the linux-kernel with non-512 byte blocks? -linda -----Original Message----- From: Stephen Lord [mailto:lord@sgi.com] Sent: Sunday, September 29, 2002 2:59 PM To: L A Walsh Cc: linux-xfs@oss.sgi.com Subject: Re: block size in XFS = hard coded constant? On Sun, 2002-09-29 at 16:28, L A Walsh wrote: > I wanted to use an alternate block size on my SCSI hard disk. > > I did a low-level reformat to use 4096 and got an additional 10.3% in hard > disk space. (17783MB -> 19627). > > I can't think of a reason why I'd want to have a 512 byte block when the > smallest allocation unit on a disk is 4K. > > However -- I ran into a hard coded reason with XFS -- it's hard coded to use > 512 byte blocks. > > Is there a reason for this? Am I missing something? Is it a bug, or is there > some reason why xfs can't handle different sized blocks? > > -l > Its pretty hard coded in the code that the disk is addressed in 512 byte sectors. Changing this has been discussed, but it is more complex than just changing a constant in the code. The original design while very scalable, did not consider sector sizes over than 512 as being a possibility. Note that this is not the filesystem block size, most metadata is 4K in size by default. Steve From owner-linux-xfs@oss.sgi.com Mon Sep 30 04:58:24 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 04:58:25 -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 g8UBwNtG007228 for ; Mon, 30 Sep 2002 04:58:23 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) 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 EAA03620 for ; Mon, 30 Sep 2002 04:58:22 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8UBvV8e001009; Mon, 30 Sep 2002 13:57:31 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g8UBvVqg001008; Mon, 30 Sep 2002 13:57:31 +0200 Date: Mon, 30 Sep 2002 13:57:31 +0200 Message-Id: <200209301157.g8UBvVqg001008@lab343.munich.sgi.com> Subject: TAKE - Don't reset blocksize on umount To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 654 X-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@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs In 2.5 the VFS code resets it to the previous blocksize anyway. Date: Mon Sep 30 04:56:35 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.5.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:128659a linux/fs/xfs/linux/xfs_super.c - 1.229 - Remove setting of the blocksize to hardsect size in linvfs_put_super From owner-linux-xfs@oss.sgi.com Mon Sep 30 05:05:55 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 05:05:56 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UC5rtG007866 for ; Mon, 30 Sep 2002 05:05:54 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g8UC5p629342 for linux-xfs@oss.sgi.com.KAV; Mon, 30 Sep 2002 14:05:51 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g8UC5ml29289; Mon, 30 Sep 2002 14:05:48 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g8UC7vn03815; Mon, 30 Sep 2002 14:07:58 +0200 Subject: RE: block size in XFS = hard coded constant? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: L A Walsh Cc: Stephen Lord , Linux-Xfs , Linux-Kernel , Linux-Fsdevel In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 30 Sep 2002 14:07:57 +0200 Message-Id: <1033387679.3719.5.camel@venus> Mime-Version: 1.0 X-archive-position: 655 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs On Mon, 2002-09-30 at 10:55, L A Walsh wrote: > Right -- I know it isn't the filesystem block size. > > In this day and age, it seems anachronistic. Given the 10% higher block > density, not only would it yield higher capacities, but should yield higher > transfer rates, no? > > I know it isn't a simple constant switch -- but I wouldn't want to switch > constants since not all disks should be constrained to the same block size. > > Do other file systems have the same limitation? Are there any problems in the > linux-kernel with non-512 byte blocks? Hi, DVD-RAM (2048 bytes block size) works well in linux. I use ext2 for DVD-RAM. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon Sep 30 05:13:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 05:13:47 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UCDetG008395 for ; Mon, 30 Sep 2002 05:13:41 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 4DDB2C0128C; Mon, 30 Sep 2002 20:13:34 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id 5E6D2C011F5; Mon, 30 Sep 2002 20:13:24 +0800 (PHT) Date: Mon, 30 Sep 2002 20:13:24 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List , Linux Kernel Mailing List Subject: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468 Message-ID: <20020930121323.GA7250@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List , Linux Kernel Mailing List Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CdrF4e02JqNVZeln" Content-Disposition: inline User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-archive-position: 656 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs --CdrF4e02JqNVZeln Content-Type: multipart/mixed; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone, On our server that had been running for 55 days with this 2.4.19-xfs kernel (XFS CVS snapshot 20020809 patched with RML's preempt patches for 2.4.19-rc3 and sys-magic 20020314 from Randy Dunlap, built using GCC 3.1.1 running Debian GNU/Linux), I hit a kernel panic in the process running the distributed-net client. I had been running the distributed-net client -- and everything else on the server -- with no significant changes recently. The server wasn't under any significantly different load, either. I copied the oops by hand onto another computer and am attaching a ksymoops output of that as kernel-panic.out. I rebooted and a few minutes after all the initialization had completed I hit another kernel panic, again because of the distributed-net client process. The oops (passed through ksymoops) is attached as kernel-panic-2.out. After copying the oops message, I attempted to sync the disks using the (Alt + SysRq + S) key combination and after the sync messages I hit a kernel BUG at sched.c:568. In my sched.c (different from the XFS tree only because of RML's preempt patch) line 568 is in the "asmlinkage void schedule(void)" function. The oops (passed through ksymoops) is attached as kernel-bug.out. Some other notes that may be significant to mention: - system is an Intel Pentium III with 512MB RAM and a 3ware 6400 IDE RAID controller, - system has one small ext2 partition for /boot, one ReiserFS partition for Squid cache, and 5 XFS partitions, - system is an NFS server, with NFSv3 enabled in the kernel and running nfs-kernel-server 1.0.2, - system is not exclusively an NFS server, it's a Samba, mail, IRC server as well, and runs lm-sensors, - this happened during a lull in the load because everyone was on their way home at the end of our work day. I am recompiling the kernel now, using a current CVS snapshot of the XFS tree, and using Debian Sid's current default gcc (2.95.4 20011002) instead of gcc 3.1.1 like before, and without RML's preempt patch (the SysMagic patch does not touch sched.c and probably didn't have anything to do with this). I turned off distributed-net as soon as I rebooted this third time, and the system's alive so far and was able to recompile the kernel. I will turn it back on when I boot with the new kernel and will send a follow-up if the kernel panics again. Pointers as to what probably caused this are welcome. If this is a "new" issue I hope the decoded oops messages will be help. Thank you everyone for your time. --> Jijo --=20 Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kernel-bug.out" Content-Transfer-Encoding: quoted-printable ksymoops 2.4.6 on i686 2.4.19-xfs. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.19-xfs/ (specified) -m /boot/System.map-2.4.19-xfs (specified) kernel BUG at sched.c:568! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 00000018 ebx: 00000004 ecx: dcfda000 edx: 00000001 esi: db41c000 edi: ce9d0d28 ebp: db41dce0 esp: db41dcb8 ds: 0018 es: 0018 ss: 0018 Process distributed-net (pid: 598, stackpage=3Ddb41d000) Stack: c0338daa dd287dc0 df2e5600 00000292 db41c000 00000000 00000001 ce9d0= ce0 db41c000 ce9d0d28 db41dcec c01428cd 00000000 00000000 db41c000 dd00d= d18 ce9d0d28 ce9d0ce0 ce9d0ce0 00000000 00000808 c0142c07 ce9d0ce0 db41c= 000 Call Trace: [] [] [] [] [] [<0c25f77b>] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 38 02 a2 8d 33 c0 e9 6f fc ff ff 0f 0b 31 02 a2 8d 33 >>EIP; c011b96a <=3D=3D=3D=3D=3D >>ecx; dcfda000 <_end+1cbcdc7c/2049dcdc> >>esi; db41c000 <_end+1b00fc7c/2049dcdc> >>edi; ce9d0d28 <_end+e5c49a4/2049dcdc> >>ebp; db41dce0 <_end+1b01195c/2049dcdc> >>esp; db41dcb8 <_end+1b011934/2049dcdc> Trace; c01428cd <__wait_on_buffer+6d/a0> Trace; c0142c07 Trace; c0142c43 Trace; c0142cca Trace; c0142e42 Trace; 0c25f77b Before first symbol Trace; c025f87d Trace; c011e823 Trace; c0122597 Trace; c011a980 Trace; c0109856 Trace; c011ac44 Trace; c0246afd Trace; c02bdc99 Trace; c02476b2 Trace; c02493ed Trace; c02480ff Trace; c011a980 Trace; c01092bc Trace; c02bc5ea Trace; c0246976 Trace; c02bc971 Trace; c02bcf16 Trace; c02bcff1 Trace; c010a755 Trace; c010a99f Trace; c010d273 Code; c011b96a 00000000 <_EIP>: Code; c011b96a <=3D=3D=3D=3D=3D 0: 0f 0b ud2a <=3D=3D=3D=3D=3D Code; c011b96c 2: 38 02 cmp %al,(%edx) Code; c011b96e 4: a2 8d 33 c0 e9 mov %al,0xe9c0338d Code; c011b973 9: 6f outsl %ds:(%esi),(%dx) Code; c011b974 a: fc cld=20=20=20=20 Code; c011b975 b: ff (bad)=20=20 Code; c011b976 c: ff 0f decl (%edi) Code; c011b978 e: 0b 31 or (%ecx),%esi Code; c011b97a 10: 02 a2 8d 33 00 00 add 0x338d(%edx),%ah <0>Kernel panic: Aiee, killing interrupt handler! --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kernel-panic.out" Content-Transfer-Encoding: quoted-printable ksymoops 2.4.6 on i686 2.4.19-xfs. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.19-xfs/ (specified) -m /boot/System.map-2.4.19-xfs (specified) Unable to handle kernel NULL pointer dereference at virtual address 00000028 c02bc5ea *pde =3D 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000001 ebx: dfcce3e0 ecx: dfcce3c0 edx: 00000000 esi: dfcce380 edi: c0010200 ebp: dfcce3a8 esp: d1899ee4 ds: 0018 es: 0018 ss: 0018 Process distributed-net (pid: 22272, stackpage=3Dd1899000) Stack: 00000008 c0246976 c354f130 c037e504 dfcce3c0 c15db660 dfcce3a0 dfcce= 3c0 dfcce380 c64f51e0 00000000 c15db67c c15db660 c15db660 dfc285a0 c02bc= f16 c15db660 dfc285a0 00000001 d1898000 d328a000 d1899f48 00000000 c15db= 67c Call Trace: [] [] [] [] [] [] Code: 8b 44 82 24 89 f9 c7 44 24 14 00 00 00 00 c1 e9 0f 83 e1 0f >>EIP; c02bc5ea <=3D=3D=3D=3D=3D >>ebx; dfcce3e0 <_end+1f8c205c/2049dcdc> >>ecx; dfcce3c0 <_end+1f8c203c/2049dcdc> >>esi; dfcce380 <_end+1f8c1ffc/2049dcdc> >>ebp; dfcce3a8 <_end+1f8c2024/2049dcdc> >>esp; d1899ee4 <_end+1148db60/2049dcdc> Trace; c0246979 Trace; c02bcf16 Trace; c02bcff1 Trace; c010a755 Trace; c010a99f Trace; c010d273 Code; c02bc5ea 00000000 <_EIP>: Code; c02bc5ea <=3D=3D=3D=3D=3D 0: 8b 44 82 24 mov 0x24(%edx,%eax,4),%eax <=3D=3D= =3D=3D=3D Code; c02bc5ee 4: 89 f9 mov %edi,%ecx Code; c02bc5f0 6: c7 44 24 14 00 00 00 movl $0x0,0x14(%esp,1) Code; c02bc5f7 d: 00=20 Code; c02bc5f8 e: c1 e9 0f shr $0xf,%ecx Code; c02bc5fb 11: 83 e1 0f and $0xf,%ecx <0>Kernel panic: Aiee, killing interrupt handler! --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kernel-panic-2.out" Content-Transfer-Encoding: quoted-printable ksymoops 2.4.6 on i686 2.4.19-xfs. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.19-xfs/ (specified) -m /boot/System.map-2.4.19-xfs (specified) Unable to handle kernel NULL pointer dereference at virtual address 00000028 c02bc5ea *pde =3D 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 00000001 ebx: dfcce3e0 ecx: dfcce3c0 edx: 00000000 esi: dfcce380 edi: c0010200 ebp: dfcce3a8 esp: d1899ee4 ds: 0018 es: 0018 ss: 0018 Process distributed-net (pid: 598, stackpage=3Ddb41d000) Stack: 00000005 c0246976 d935c130 c037e504 c02bc971 d935c000 dfc285a0 dfcce= 3c0 dfcce380 dfc1a1a0 00000000 c15db67c c15db660 c15db660 dfc28420 c02bc= f16 c15db660 dfc28420 00000001 db41c000 d5c1c000 db41df48 00000000 c15db= 67c Call Trace: [] [] [] [] [] [] [] Code: 8b 44 82 24 89 f9 c7 44 24 14 00 00 00 00 c1 e9 0f 83 e1 0f >>EIP; c02bc5ea <=3D=3D=3D=3D=3D >>ebx; dfcce3e0 <_end+1f8c205c/2049dcdc> >>ecx; dfcce3c0 <_end+1f8c203c/2049dcdc> >>esi; dfcce380 <_end+1f8c1ffc/2049dcdc> >>ebp; dfcce3a8 <_end+1f8c2024/2049dcdc> >>esp; d1899ee4 <_end+1148db60/2049dcdc> Trace; c0246976 Trace; c02bc971 Trace; c02bcf16 Trace; c02bcff1 Trace; c010a755 Trace; c010a99f Trace; c010d273 Code; c02bc5ea 00000000 <_EIP>: Code; c02bc5ea <=3D=3D=3D=3D=3D 0: 8b 44 82 24 mov 0x24(%edx,%eax,4),%eax <=3D=3D= =3D=3D=3D Code; c02bc5ee 4: 89 f9 mov %edi,%ecx Code; c02bc5f0 6: c7 44 24 14 00 00 00 movl $0x0,0x14(%esp,1) Code; c02bc5f7 d: 00=20 Code; c02bc5f8 e: c1 e9 0f shr $0xf,%ecx Code; c02bc5fb 11: 83 e1 0f and $0xf,%ecx <0>Kernel panic: Aiee, killing interrupt handler! --M9NhX3UHpAaciwkO-- --CdrF4e02JqNVZeln Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE9mD/j5rCBSJO3Rr4RAn0pAJ937zwgt7TGpIa3OYinqXNLHLDpMgCfZpcN Bgh+ibOJComFFjGMY1D2B7A= =Svc2 -----END PGP SIGNATURE----- --CdrF4e02JqNVZeln-- From owner-linux-xfs@oss.sgi.com Mon Sep 30 07:14:07 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 07:14:10 -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 g8UEE6tG018536 for ; Mon, 30 Sep 2002 07:14:06 -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 JAA01099 for ; Mon, 30 Sep 2002 09:14:01 -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 JAA23988 for ; Mon, 30 Sep 2002 09:14:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8UE8IT28114; Mon, 30 Sep 2002 09:08:18 -0500 Message-Id: <200209301408.g8UE8IT28114@jen.americas.sgi.com> Date: Mon, 30 Sep 2002 09:08:18 -0500 Subject: TAKE - fix a couple of compiler warnings which crept in. To: linux-xfs@oss.sgi.com X-archive-position: 657 X-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: Mon Sep 30 07:13:41 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:128671a linux/fs/xfs/linux/xfs_aops.c - 1.7 - make convert_page a void function, and remove unused need_trans variable. From owner-linux-xfs@oss.sgi.com Mon Sep 30 07:38:36 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 07:38:42 -0700 (PDT) Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UEcYtG019917 for ; Mon, 30 Sep 2002 07:38:35 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g8UEcVM06556 for linux-xfs@oss.sgi.com.KAV; Mon, 30 Sep 2002 16:38:31 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g8UEcU706550 for ; Mon, 30 Sep 2002 16:38:31 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g8UEefn04730 for ; Mon, 30 Sep 2002 16:40:41 +0200 Subject: Status of XFS for 2.4.19 and GCC 3.2 From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 30 Sep 2002 16:40:41 +0200 Message-Id: <1033396841.4668.5.camel@venus> Mime-Version: 1.0 X-archive-position: 658 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: linux-xfs Hi, Is it safe to use this compiler for linux kernel witth XFS support? Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon Sep 30 08:14:20 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 08:14:25 -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 g8UFEKtG026689 for ; Mon, 30 Sep 2002 08:14:20 -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 17w2FZ-0004We-00 for linux-xfs@oss.sgi.com; Mon, 30 Sep 2002 09:14:21 -0600 Message-ID: <3D986A50.7010906@emergence.com> Date: Mon, 30 Sep 2002 09:14:24 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Status of XFS for 2.4.19 and GCC 3.2 References: <1033396841.4668.5.camel@venus> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 659 X-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 The only issue that might need to be tested in the O_DIRECT issue on i586 that was brought up on the list here. http://bugs.gentoo.org/show_bug.cgi?id=7237 Applies to the regular 2.4.19 XFS kernels. I believe that a patch from Andrea made it's way on to the list that may be related. -Mike Olaf Fra;czyk wrote: > Hi, > > Is it safe to use this compiler for linux kernel witth XFS support? > > Regards, > > Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Mon Sep 30 09:29:59 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 09:30:09 -0700 (PDT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UGTutG029241 for ; Mon, 30 Sep 2002 09:29:57 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 3E937C0128E; Tue, 1 Oct 2002 00:29:51 +0800 (PHT) Received: by gusi.leathercollection.ph (Postfix, from userid 1000) id AA3B6C01290; Tue, 1 Oct 2002 00:29:28 +0800 (PHT) Date: Tue, 1 Oct 2002 00:29:28 +0800 From: Federico Sevilla III To: Linux-XFS Mailing List , Linux Kernel Mailing List Subject: Re: kernel panic "killing interrupt handler" and kernel BUG at sched.c:468 Message-ID: <20020930162928.GB7691@leathercollection.ph> Mail-Followup-To: Linux-XFS Mailing List , Linux Kernel Mailing List References: <20020930121323.GA7250@leathercollection.ph> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <20020930121323.GA7250@leathercollection.ph> User-Agent: Mutt/1.4i X-Organization: The Leather Collection, Inc. X-Organization-URL: http://www.leathercollection.ph X-Personal-URL: http://jijo.free.net.ph X-Virus-Scanned: by AMaViS snapshot-20020316 X-archive-position: 660 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jijo@free.net.ph Precedence: bulk X-list: linux-xfs --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi everyone, On Mon, Sep 30, 2002 at 08:13:24PM +0800, Federico Sevilla III wrote: > On our server that had been running for 55 days with this 2.4.19-xfs > kernel (XFS CVS snapshot 20020809 patched with RML's preempt patches > for 2.4.19-rc3 and sys-magic 20020314 from Randy Dunlap, built using > GCC 3.1.1 running Debian GNU/Linux) And then after approximately 1.5 hours on 2.4.19-xfs (XFS CVS snapshot 20020930 patched only with Randy Dunlap's sys-magic 20020314, built using gcc 2.95.4 running Debian GNU/Linux). > I hit a kernel panic in the process running the distributed-net > client. Now in the process running syslogd. Attached kernel-panic-3.out is the oops. > After copying the oops message, I attempted to sync the disks using > the (Alt + SysRq + S) key combination and after the sync messages I > hit a kernel BUG at sched.c:568. I did this, as well, and hit a kernel BUG at sched.c:566. My sched.c is now exactly the same as the one in the XFS tree (which I think is the same as the one in vanilla 2.4.19). Oops is attached as kernel-bug-2.out. > Pointers as to what probably caused this are welcome. If this is a > "new" issue I hope the decoded oops messages will be help. Thank you > everyone for your time. System has been up for two hours so far and is thankfully alive. I hope someone can point me to what the probably cause of this problem is. I did an xfs_check -- which is from the latest 2.3.1 package -- and all my XFS partitions are okay. I will be looking for a memory scanning tool shortly to make sure I don't suddenly have bad RAM, although the problem doesn't seem to be that. Thanks again to everyone for your time. --> Jijo -- Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kernel-panic-3.out" ksymoops 2.4.6 on i686 2.4.19-xfs. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.19-xfs/ (specified) -m /boot/System.map-2.4.19-xfs (specified) Unable to handle kernel NULL pointer dereference at virtual address 00000002c c026d0c9 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206 eax: 00000028 ebx: dfccc3a8 ecx: 01800204 edx: 00000001 esi: dfccc3a8 edi: dfc265a0 ebp: 00000000 esp: defe5da8 ds: 0018 es: 0018 ss: 0018 Process syslogd (pid: 281, stackpage=defe5000) Stack: c15d957c dfc265a0 c15d9560 00000000 df381018 c01da1dc dfccc3c0 dfc26620 dfccc3e0 dfccc380 dfc0c1e0 00000000 c026d750 c15d9560 dfc265a0 00000001 c15d957c c15d9560 00000001 00000000 00000008 c038e600 00000000 c026d9c2 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 2c 90 8b 44 24 28 c1 e9 08 83 e1 0f d3 ed 83 e5 01 c7 44 >>EIP; c026d0c9 <===== >>ebx; dfccc3a8 <_end+1f924484/2050213c> >>esi; dfccc3a8 <_end+1f924484/2050213c> >>edi; dfc265a0 <_end+1f87e67c/2050213c> >>esp; defe5da8 <_end+1ec3de84/2050213c> Trace; c01da1dc Trace; c026d750 Trace; c026d9c2 Trace; c010985d Trace; c01099c6 Trace; c010bbc8 Trace; c02707e9 Trace; c0271792 Trace; c012f3e4 <__alloc_pages+40/178> Trace; c012f5c3 <__free_pages+1b/1c> Trace; c012f5de Trace; c01408fa Trace; c0140bf8 Trace; c027188e Trace; c0271f44 Trace; c010856f Code; c026d0c9 00000000 <_EIP>: Code; c026d0c9 <===== 0: 8b 2c 90 mov (%eax,%edx,4),%ebp <===== Code; c026d0cc 3: 8b 44 24 28 mov 0x28(%esp,1),%eax Code; c026d0d0 7: c1 e9 08 shr $0x8,%ecx Code; c026d0d3 a: 83 e1 0f and $0xf,%ecx Code; c026d0d6 d: d3 ed shr %cl,%ebp Code; c026d0d8 f: 83 e5 01 and $0x1,%ebp Code; c026d0db 12: c7 44 00 00 00 00 00 movl $0x0,0x0(%eax,%eax,1) Code; c026d0e2 19: 00 <0>Kernel panic: Aiee, killing interrupt handler! --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kernel-bug-2.out" ksymoops 2.4.6 on i686 2.4.19-xfs. Options used -V (specified) -k /proc/ksyms (specified) -l /proc/modules (specified) -o /lib/modules/2.4.19-xfs/ (specified) -m /boot/System.map-2.4.19-xfs (specified) kernel BUG at sched.c:566! invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: 00000018 ebx: defe5be0 ecx: def9c000 edx: 00000001 esi: def4c3e0 edi: defe4000 ebp: defe5bcc esp: defe5ba8 ds: 0018 es: 0018 ss: 0018 Process syslogd (pid: 281, stackpage=defe5000) Stack: c02ca05e defe5be0 def4c3e0 defe4000 dfe24a18 defe5be0 00000000 defe4000 dfe24a74 00000808 c0134a5a def4c3e0 00000005 def4c9e0 00000000 defe4000 def4c42c def4c42c c0134c8b def4c3e0 00000808 00000001 00000001 0000000b Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 36 02 56 a0 2c c0 83 c4 04 8b 4d f4 c1 e1 05 81 c1 40 >>EIP; c0116879 <===== >>ebx; defe5be0 <_end+1ec3dcbc/2050213c> >>ecx; def9c000 <_end+1ebf40dc/2050213c> >>esi; def4c3e0 <_end+1eba44bc/2050213c> >>edi; defe4000 <_end+1ec3c0dc/2050213c> >>ebp; defe5bcc <_end+1ec3dca8/2050213c> >>esp; defe5ba8 <_end+1ec3dc84/2050213c> Trace; c0134a5a <__wait_on_buffer+6e/90> Trace; c0134c8b Trace; c0134cd0 Trace; c0134d17 Trace; c0134dd7 Trace; c02203ca Trace; c0220428 Trace; c0118da3 Trace; c011baf0 Trace; c0115e54 Trace; c0108b36 Trace; c01161a7 Trace; c0115e5f Trace; c0116af6 Trace; c0134a70 <__wait_on_buffer+84/90> Trace; c013552d Trace; c0108660 Trace; c026d0c9 Trace; c01da1dc Trace; c012d750 Trace; c026d9c2 Trace; c010985d Trace; c01099c6 Trace; c010bbc8 Trace; c02707e9 Trace; c0271792 Trace; c012f3e4 <__alloc_pages+40/178> Trace; c012f5c3 <__free_pages+1b/1c> Trace; c012f5de Trace; c01408fa Trace; c0140bf8 Trace; c027188e Trace; c0271f44 Trace; c010856f Code; c0116879 00000000 <_EIP>: Code; c0116879 <===== 0: 0f 0b ud2a <===== Code; c011687b 2: 36 02 56 a0 add %ss:0xffffffa0(%esi),%dl Code; c011687f 6: 2c c0 sub $0xc0,%al Code; c0116881 8: 83 c4 04 add $0x4,%esp Code; c0116884 b: 8b 4d f4 mov 0xfffffff4(%ebp),%ecx Code; c0116887 e: c1 e1 05 shl $0x5,%ecx Code; c011688a 11: 81 c1 40 00 00 00 add $0x40,%ecx <0>Kernel panic: Aiee, killing interrupt handler! --d6Gm4EdcadzBjdND-- From owner-linux-xfs@oss.sgi.com Mon Sep 30 09:43:49 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 09:43:54 -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 g8UGhmtG029937 for ; Mon, 30 Sep 2002 09:43:48 -0700 Received: from lab343.munich.sgi.com (lab343.munich.sgi.com [144.253.195.43]) 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 JAA09810 for ; Mon, 30 Sep 2002 09:43:47 -0700 (PDT) mail_from (hch@lab343.munich.sgi.com) From: hch@lab343.munich.sgi.com Received: from lab343.munich.sgi.com (localhost [127.0.0.1]) by lab343.munich.sgi.com (8.12.3/8.12.2/SuSE Linux 0.6) with ESMTP id g8UGgMDp000979; Mon, 30 Sep 2002 18:42:22 +0200 Received: (from hch@localhost) by lab343.munich.sgi.com (8.12.3/8.12.2/Submit) id g8UGgMvk000978; Mon, 30 Sep 2002 18:42:22 +0200 Date: Mon, 30 Sep 2002 18:42:22 +0200 Message-Id: <200209301642.g8UGgMvk000978@lab343.munich.sgi.com> Subject: TAKE - Set inode operations later in xfs_iget_core To: undisclosed-recipients:;;@lab343.munich.sgi.com X-archive-position: 661 X-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@lab343.munich.sgi.com Precedence: bulk X-list: linux-xfs Chris Wedgwood found this sleep while holding a spinlock (in this case actually a read lock) bug. We keep the Linux inode locked a little longer in iget now, but that can't cause harm. Date: Mon Sep 30 09:40:16 PDT 2002 Workarea: lab343.munich.sgi.com:/home/hch/repo/slinx/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:128691a linux/fs/xfs/xfs_iget.c - 1.173 - Move setting the inode ops later in xfs_iget_core - init_special_inode might sleep. From owner-linux-xfs@oss.sgi.com Mon Sep 30 11:53:42 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 11:53:48 -0700 (PDT) Received: from mail.get2chip.com ([64.169.83.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UIrgtG001879 for ; Mon, 30 Sep 2002 11:53:42 -0700 Subject: security and journaling From: Chris Croswhite To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: 30 Sep 2002 11:53:36 -0700 Message-Id: <1033412016.12588.12.camel@lws020.get2chip.com> Mime-Version: 1.0 X-archive-position: 662 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ccroswhite@get2chip.com Precedence: bulk X-list: linux-xfs Hello, I am not quite clear on this issue and ask for comments. I have a laptop going out with an employee that will use mcrypt to crypt some files on the hard drive. As this computer has XFS, how can I be sure that the original files will not be recovered from the journal? TIA, Chris From owner-linux-xfs@oss.sgi.com Mon Sep 30 11:56:18 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 11:56:19 -0700 (PDT) Received: from tapu.f00f.org (tapu.f00f.org [66.60.186.129]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UIuHtG002309 for ; Mon, 30 Sep 2002 11:56:18 -0700 Received: by tapu.f00f.org (Postfix, from userid 1000) id C37EC1E1B2B; Mon, 30 Sep 2002 11:56:17 -0700 (PDT) Date: Mon, 30 Sep 2002 11:56:17 -0700 From: Chris Wedgwood To: Chris Croswhite Cc: linux-xfs@oss.sgi.com Subject: Re: security and journaling Message-ID: <20020930185617.GA15397@tapu.f00f.org> References: <1033412016.12588.12.camel@lws020.get2chip.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1033412016.12588.12.camel@lws020.get2chip.com> User-Agent: Mutt/1.4i X-No-Archive: Yes X-archive-position: 663 X-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 Mon, Sep 30, 2002 at 11:53:36AM -0700, Chris Croswhite wrote: > I am not quite clear on this issue and ask for comments. I have a > laptop going out with an employee that will use mcrypt to crypt some > files on the hard drive. As this computer has XFS, how can I be > sure that the original files will not be recovered from the journal? Unless I'm mistaken (very possible), only metadata is jornalled and not the data, so the file contents should never be in the journal. That said, if you are *really* paranoid deleting and over-writing the data doesn't suffice unless done carefully and eve nthen there are caveats. --cw From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:04:41 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:04:43 -0700 (PDT) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJ4ftG002910 for ; Mon, 30 Sep 2002 12:04:41 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T7LHQY05; Mon, 30 Sep 2002 15:04:40 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g8UJ4ek04002; Mon, 30 Sep 2002 15:04:40 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3D98A047.7000106@wgate.com> Date: Mon, 30 Sep 2002 15:04:39 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1b) Gecko/20020813 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Croswhite CC: linux-xfs@oss.sgi.com Subject: Re: security and journaling References: <1033412016.12588.12.camel@lws020.get2chip.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 664 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Chris Croswhite wrote: > Hello, > > I am not quite clear on this issue and ask for comments. I have a > laptop going out with an employee that will use mcrypt to crypt some > files on the hard drive. As this computer has XFS, how can I be sure > that the original files will not be recovered from the journal? Two things: 1) The XFS journal does not include file data, just meta-data. (That is, filesystem structure/control information) 2) mcrypt runs above the filesystem which would mean that the filesystem never saw the unencrypted data. So, even if user data was in the journal, it too would be encrypted. Having said that, there is one issue that can not be directly addressed here. That is information that can be learned by the names one gives a file. Unless you pick cryptic names for files you could, say, have "LetterToBillGates.doc" or "Resume.html" or "IBM-DistributionDeal.xml" and thus while the contents of the file are cryptic, the fact that you are talking with Bill Gates and have some distribution deal with IBM will be seen. -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:05:56 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:05:58 -0700 (PDT) Received: from mail.get2chip.com ([64.169.83.2]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJ5utG003036 for ; Mon, 30 Sep 2002 12:05:56 -0700 Subject: security and journaling From: Chris Croswhite To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: 30 Sep 2002 12:05:50 -0700 Message-Id: <1033412750.13916.20.camel@lws020.get2chip.com> Mime-Version: 1.0 X-archive-position: 665 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ccroswhite@get2chip.com Precedence: bulk X-list: linux-xfs People, Thank you for the responses. I am indeed paranoid about recovering the files that will be encrypted. As people on this list have stated, I need to verify that after a clean unmount, the journal is zeroed. Or is it possible to force the journal to zero itself out? Is it possible to force XFS to immediately over write the original space of files that were encrypted? TIA, Chris From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:10:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:10:18 -0700 (PDT) Received: from questra.com (IDENT:qmailr@ns1.questra.com [64.132.48.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJAGtG003890 for ; Mon, 30 Sep 2002 12:10:16 -0700 Received: (qmail 21982 invoked from network); 30 Sep 2002 19:10:13 -0000 Received: from hades.roc.questra.com (HELO questra.com) (64.132.48.226) by ns1.questra.com with SMTP; 30 Sep 2002 19:10:13 -0000 Received: (qmail 30825 invoked from network); 30 Sep 2002 19:10:13 -0000 Received: from odio.roc.questra.com (10.20.8.26) by hades.roc.questra.com with SMTP; 30 Sep 2002 19:10:13 -0000 Received: (from mcdermot@localhost) by odio.roc.questra.com (8.11.6/8.11.4) id g8UJADf30792 for linux-xfs@oss.sgi.com; Mon, 30 Sep 2002 15:10:13 -0400 Date: Mon, 30 Sep 2002 15:10:13 -0400 From: Scott McDermott To: linux-xfs@oss.sgi.com Subject: Re: security and journaling Message-ID: <20020930151013.F24367@questra.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1033412016.12588.12.camel@lws020.get2chip.com> <20020930185617.GA15397@tapu.f00f.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: <20020930185617.GA15397@tapu.f00f.org>; from cw@f00f.org on Mon, Sep 30, 2002 at 11:56:17AM -0700 X-archive-position: 666 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mcdermot@questra.com Precedence: bulk X-list: linux-xfs Chris Wedgwood on Mon 30/09 11:56 -0700: > That said, if you are *really* paranoid deleting and over-writing the > data doesn't suffice unless done carefully and eve nthen there are > caveats. Just use shred(1)...it's from fileutils so it should be on any GNU box. You also have to worry about VM pages being written to swap unencrypted. Encrypted loopback is probably better for this application. From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:18:31 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:18:37 -0700 (PDT) Received: from mail.aem.umn.edu (mail.aem.umn.edu [128.101.142.239]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJIPtG004378 for ; Mon, 30 Sep 2002 12:18:30 -0700 Received: from lightning.aem.umn.edu (lightning.aem.umn.edu [128.101.143.49]) by mail.aem.umn.edu (8.11.3/8.11.3) with ESMTP id g8UJILr39006 for ; Mon, 30 Sep 2002 14:18:21 -0500 (CDT) (envelope-from muno@aem.umn.edu) Received: (from muno@localhost) by lightning.aem.umn.edu (8.11.6/8.9.1) id g8UJILC16443 for linux-xfs@oss.sgi.com; Mon, 30 Sep 2002 14:18:21 -0500 Date: Mon, 30 Sep 2002 14:18:21 -0500 From: Ray Muno To: linux-xfs@oss.sgi.com Subject: Re: security and journaling Message-ID: <20020930191821.GO15322@aem.umn.edu> References: <1033412016.12588.12.camel@lws020.get2chip.com> <20020930185617.GA15397@tapu.f00f.org> <20020930151013.F24367@questra.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020930151013.F24367@questra.com> User-Agent: Mutt/1.5.1i X-archive-position: 667 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: muno@aem.umn.edu Precedence: bulk X-list: linux-xfs SHRED(1) FSF SHRED(1) NAME shred - delete a file securely, first overwriting it to hide its contents SYNOPSIS shred [OPTIONS] FILE [...] ...stuff deleted CAUTION: Note that shred relies on a very important assumption: that the filesystem overwrites data in place. This is the traditional way to do things, but many modern filesystem designs do not satisfy this assumption. The following are examples of filesystems on which shred is not effective: * log-structured or journaled filesystems, such as those supplied with AIX and Solaris (and JFS, ReiserFS, XFS, etc.) --------------------- On Mon, Sep 30, 2002 at 03:10:13PM -0400, Scott McDermott wrote: > Chris Wedgwood on Mon 30/09 11:56 -0700: > > That said, if you are *really* paranoid deleting and over-writing the > > data doesn't suffice unless done carefully and eve nthen there are > > caveats. > > Just use shred(1)...it's from fileutils so it should be on any GNU box. > You also have to worry about VM pages being written to swap unencrypted. > Encrypted loopback is probably better for this application. > ============================================================================= Ray Muno http://www.aem.umn.edu/people/staff/muno University of Minnesota e-mail: muno@aem.umn.edu Aerospace Engineering and Mechanics Phone: (612) 625-9531 110 Union St. S.E. FAX: (612) 626-1558 Minneapolis, Mn 55455 ============================================================================= From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:35:17 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:35: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 g8UJZGtG004937 for ; Mon, 30 Sep 2002 12:35:17 -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 OAA54454; Mon, 30 Sep 2002 14:35:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA33117; Mon, 30 Sep 2002 14:35:09 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g8UJTRq01959; Mon, 30 Sep 2002 14:29:27 -0500 Subject: Re: security and journaling From: Steve Lord To: Ray Muno Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020930191821.GO15322@aem.umn.edu> References: <1033412016.12588.12.camel@lws020.get2chip.com> <20020930185617.GA15397@tapu.f00f.org> <20020930151013.F24367@questra.com> <20020930191821.GO15322@aem.umn.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 30 Sep 2002 14:29:27 -0500 Message-Id: <1033414167.1494.4.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-archive-position: 668 X-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-30 at 14:18, Ray Muno wrote: > SHRED(1) FSF SHRED(1) > > NAME > shred - delete a file securely, first overwriting it to > hide its contents > > SYNOPSIS > shred [OPTIONS] FILE [...] > > ...stuff deleted > > CAUTION: Note that shred relies on a very important > assumption: that the filesystem overwrites data in place. > This is the traditional way to do things, but many modern > filesystem designs do not satisfy this assumption. The > following are examples of filesystems on which shred is > not effective: > > * log-structured or journaled filesystems, such as those > supplied with > > AIX and Solaris (and JFS, ReiserFS, XFS, etc.) If shred just overwrites in place it will be effective with XFS, that man page is wrong. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:36:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:36:51 -0700 (PDT) Received: from questra.com (IDENT:qmailr@ns1.questra.com [64.132.48.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJahtG005339 for ; Mon, 30 Sep 2002 12:36:43 -0700 Received: (qmail 22307 invoked from network); 30 Sep 2002 19:36:43 -0000 Received: from hades.roc.questra.com (HELO questra.com) (64.132.48.226) by ns1.questra.com with SMTP; 30 Sep 2002 19:36:43 -0000 Received: (qmail 32422 invoked from network); 30 Sep 2002 19:36:43 -0000 Received: from odio.roc.questra.com (10.20.8.26) by hades.roc.questra.com with SMTP; 30 Sep 2002 19:36:43 -0000 Received: (from mcdermot@localhost) by odio.roc.questra.com (8.11.6/8.11.4) id g8UJag631597; Mon, 30 Sep 2002 15:36:42 -0400 Date: Mon, 30 Sep 2002 15:36:42 -0400 From: Scott McDermott To: Ray Muno Cc: linux-xfs@oss.sgi.com Subject: Re: security and journaling Message-ID: <20020930153642.G24367@questra.com> Mail-Followup-To: Ray Muno , linux-xfs@oss.sgi.com References: <1033412016.12588.12.camel@lws020.get2chip.com> <20020930185617.GA15397@tapu.f00f.org> <20020930151013.F24367@questra.com> <20020930191821.GO15322@aem.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020930191821.GO15322@aem.umn.edu>; from muno@aem.umn.edu on Mon, Sep 30, 2002 at 02:18:21PM -0500 X-archive-position: 669 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mcdermot@questra.com Precedence: bulk X-list: linux-xfs Ray Muno on Mon 30/09 14:18 -0500: > The following are examples of filesystems on which shred is > not effective: > > * log-structured or journaled filesystems, such as those > supplied with > > AIX and Solaris (and JFS, ReiserFS, XFS, etc.) um...yeah... well, who reads manuals anyways ;) doh! encrypted loopback is the way to go I guess. Unless root can't read these files either, then use something like GPG. From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:40:52 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:40:54 -0700 (PDT) Received: from questra.com (IDENT:qmailr@ns1.questra.com [64.132.48.186]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJeptG005878 for ; Mon, 30 Sep 2002 12:40:52 -0700 Received: (qmail 22370 invoked from network); 30 Sep 2002 19:40:51 -0000 Received: from hades.roc.questra.com (HELO questra.com) (64.132.48.226) by ns1.questra.com with SMTP; 30 Sep 2002 19:40:51 -0000 Received: (qmail 32669 invoked from network); 30 Sep 2002 19:40:51 -0000 Received: from odio.roc.questra.com (10.20.8.26) by hades.roc.questra.com with SMTP; 30 Sep 2002 19:40:51 -0000 Received: (from mcdermot@localhost) by odio.roc.questra.com (8.11.6/8.11.4) id g8UJepB31759 for linux-xfs@oss.sgi.com; Mon, 30 Sep 2002 15:40:51 -0400 Date: Mon, 30 Sep 2002 15:40:51 -0400 From: Scott McDermott To: linux-xfs@oss.sgi.com Subject: Re: security and journaling Message-ID: <20020930154051.H24367@questra.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1033412016.12588.12.camel@lws020.get2chip.com> <20020930185617.GA15397@tapu.f00f.org> <20020930151013.F24367@questra.com> <20020930191821.GO15322@aem.umn.edu> <20020930153642.G24367@questra.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: <20020930153642.G24367@questra.com>; from mcdermot@questra.com on Mon, Sep 30, 2002 at 03:36:42PM -0400 X-archive-position: 670 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mcdermot@questra.com Precedence: bulk X-list: linux-xfs Cc linux-xfs@oss.sgi.com on Mon 30/09 15:36 -0400: > encrypted loopback is the way to go I guess. Unless root can't read > these files either, then use something like GPG. I guess root could read those too while it's in memory...oh well you are screwed if you can't trust root I guess. From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:53:03 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:53:05 -0700 (PDT) Received: from UberGeek ([209.184.141.189]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJr3tG006437 for ; Mon, 30 Sep 2002 12:53:03 -0700 Received: (qmail 28476 invoked by uid 500); 30 Sep 2002 16:51:11 -0000 Subject: Re: Status of XFS for 2.4.19 and GCC 3.2 From: Austin Gonyou To: Olaf =?iso-8859-2?Q?Fr=B1czyk?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <1033396841.4668.5.camel@venus> References: <1033396841.4668.5.camel@venus> Content-Type: text/plain; charset=iso-8859-2 Organization: Coremetrics, Inc. Message-Id: <1033404670.27834.22.camel@UberGeek.coremetrics.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.1.1.99 (Preview Release) Date: 30 Sep 2002 11:51:11 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g8UJr3tG006438 X-archive-position: 671 X-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 use it an SP, DP, and QP x86 boxen with 2.4.19(gcc 3.2). On Mon, 2002-09-30 at 09:40, Olaf Fr±czyk wrote: > Hi, > > Is it safe to use this compiler for linux kernel witth XFS support? > > Regards, > > Olaf Fraczyk -- Austin Gonyou Coremetrics, Inc. From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:55:51 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:55:53 -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 g8UJtmtG006910 for ; Mon, 30 Sep 2002 12:55:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA69750 for ; Mon, 30 Sep 2002 14:55:42 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.8) with ESMTP id OAA10606 for ; Mon, 30 Sep 2002 14:55:42 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA38774; Mon, 30 Sep 2002 14:55:42 -0500 (CDT) Message-Id: <200209301955.OAA38774@slobber.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: XFS allows expansions, but no contraction? Date: Mon, 30 Sep 2002 14:55:42 -0500 From: Dean Roehrich X-archive-position: 672 X-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 >From: Andi Kleen >> Probably an extension of the xfs_fsr approach would be the way to >> go. One major issue is it is impossible to do this without changing >> inode numbers. Some applications rely on inode numbers remaining a >> constant. > >But none I know do this over umount/remount (ok except for NFS stateless >filehandles, but that can be cured by remounting on the client too) Hierarchical Storage Managers (HSMs)--the things that use DMAPI--may very well expect filehandles to be valid across reboots (the DMAPI spec supports this expectation). Dean From owner-linux-xfs@oss.sgi.com Mon Sep 30 12:59:25 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 12:59:27 -0700 (PDT) Received: from homer.nks.net (homer.nks.net [66.152.21.172]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UJxOtG007386 for ; Mon, 30 Sep 2002 12:59:24 -0700 Received: from hoju.nks.net (hoju.nks.net [192.168.1.17]) by homer.nks.net (8.9.3/8.9.3) with ESMTP id PAA30546 for ; Mon, 30 Sep 2002 15:59:20 -0400 Received: from localhost.localdomain (two.nks.net [192.168.1.22]) by hoju.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id PAA26213 for ; Mon, 30 Sep 2002 15:59:18 -0400 Subject: Re: security and journaling From: Derek Glidden To: "linux-xfs@oss.sgi.com" In-Reply-To: <20020930151013.F24367@questra.com> References: <1033412016.12588.12.camel@lws020.get2chip.com> <20020930185617.GA15397@tapu.f00f.org> <20020930151013.F24367@questra.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 30 Sep 2002 15:59:18 -0400 Message-Id: <1033415958.25020.41.camel@two.nks.net> Mime-Version: 1.0 X-archive-position: 673 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dglidden@illusionary.com Precedence: bulk X-list: linux-xfs On Mon, 2002-09-30 at 15:10, Scott McDermott wrote: > Chris Wedgwood on Mon 30/09 11:56 -0700: > > That said, if you are *really* paranoid deleting and over-writing the > > data doesn't suffice unless done carefully and eve nthen there are > > caveats. > Encrypted loopback is probably better for this application. agreed. if you are that paranoid, you should set up your swap and your XFS volume on an encrypted loopback device. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Mon Sep 30 13:24:26 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 13:24:29 -0700 (PDT) Received: from mail.tvol.net (pr-66-150-46-254.wgate.com [66.150.46.254]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g8UKOQtG008034 for ; Mon, 30 Sep 2002 13:24:26 -0700 Received: from sinz.eng.tvol.net ([10.32.2.99]) by mail.tvol.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T7LHQZ8F; Mon, 30 Sep 2002 16:24:25 -0400 Received: from wgate.com (localhost [127.0.0.1]) by sinz.eng.tvol.net (8.11.6/8.11.6) with ESMTP id g8UKOPk04282; Mon, 30 Sep 2002 16:24:25 -0400 (EDT) (envelope-from msinz@wgate.com) Message-ID: <3D98B2F9.7000302@wgate.com> Date: Mon, 30 Sep 2002 16:24:25 -0400 From: Michael Sinz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.1b) Gecko/20020813 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Croswhite CC: linux-xfs@oss.sgi.com Subject: Re: security and journaling References: <1033412750.13916.20.camel@lws020.get2chip.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 674 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: msinz@wgate.com Precedence: bulk X-list: linux-xfs Chris Croswhite wrote: > People, > > Thank you for the responses. > > I am indeed paranoid about recovering the files that will be encrypted. > As people on this list have stated, I need to verify that after a clean > unmount, the journal is zeroed. Or is it possible to force the journal > to zero itself out? Is it possible to force XFS to immediately over > write the original space of files that were encrypted? If the encryption process uses mmap() to open/read/encrypt/write the file (and the size does not get smaller) then you would be fine. This will alter the data on disk "in place" and happens to also be a fine/fast way to do so :-) -- Michael Sinz -- Director, Systems Engineering -- Worldgate Communications A master's secrets are only as good as the master's ability to explain them to others. From owner-linux-xfs@oss.sgi.com Mon Sep 30 14:27:50 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 14:27:55 -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 g8ULRotG008981 for ; Mon, 30 Sep 2002 14:27:50 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id OAA06603 for ; Mon, 30 Sep 2002 14:27:48 -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 HAA00788; Tue, 1 Oct 2002 07:26:29 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA14968; Tue, 1 Oct 2002 07:26:27 +1000 (EST) Date: Tue, 1 Oct 2002 07:26:27 +1000 From: Nathan Scott To: L A Walsh Cc: Linux-Xfs , Linux-Kernel , Linux-Fsdevel Subject: Re: block size in XFS = hard coded constant? Message-ID: <20021001072627.A218954@wobbly.melbourne.sgi.com> References: <1033336748.1088.4.camel@laptop.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: ; from law@tlinx.org on Mon, Sep 30, 2002 at 01:55:38AM -0700 X-archive-position: 675 X-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 Hello, On Mon, Sep 30, 2002 at 01:55:38AM -0700, L A Walsh wrote: > Right -- I know it isn't the filesystem block size. > > In this day and age, it seems anachronistic. Given the 10% higher block > density, not only would it yield higher capacities, but should yield higher > transfer rates, no? > > I know it isn't a simple constant switch -- but I wouldn't want to switch > constants since not all disks should be constrained to the same block size. > I have some code which implements an initial version of >512 byte sector sizes for the XFS data device - I was just chatting about this with Steve today. Initial benchmarking results seem to suggest that it does indeed perform slightly better. Support for this will likely be making its way into XFS in the future, but not right away. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Sep 30 21:34:28 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 21:34:32 -0700 (PDT) Received: from amikkiworld.com (nycmny1-ar1-4-33-084-046.nycmny1.elnk.dsl.genuity.net [4.33.84.46]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g914YRtG014877 for ; Mon, 30 Sep 2002 21:34:28 -0700 Message-Id: <200210010434.g914YRtG014877@oss.sgi.com> Content-Type: text/plain; charset="US-ASCII" Date: Tue, 1 Oct 2002 00:34:18 -0400 To: linux-xfs@oss.sgi.com From: moneyhome@amikkiworld.com X-Mailer: Version 5.0 Subject: FREE traffic to YOUR website ! Organization: X-archive-position: 676 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: moneyhome@amikkiworld.com Precedence: bulk X-list: linux-xfs Hi, My name is Mike and I have visited your web site. I love it. So I have decided to write to you. I thought that because generating traffic is so critical for any website, you could be interested in some information I have about FREE web traffic. If you want to read it, simply reply to this email with a blank message and I will email it to you. Have a great day, Mike. From owner-linux-xfs@oss.sgi.com Mon Sep 30 21:47:44 2002 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Sep 2002 21:47:48 -0700 (PDT) Received: from ilanz.monex.li (ilanz.monex.li [164.128.93.104]) by oss.sgi.com (8.12.5/8.12.5) with SMTP id g914lYtG015513 for ; Mon, 30 Sep 2002 21:47:41 -0700 Received: from spalegna.monex.li (spalegna [164.128.93.99]) by ilanz.monex.li (8.11.6/8.11.6) with ESMTP id g914lQn08254; Tue, 1 Oct 2002 06:47:26 +0200 Received: from relay.monex.li (8.9.3/8.9.3) id IAA02268; Tue, 1 Oct 2002 08:25:43 +0200 Received: from mailpumpe.monex.li by relay.monex.li via smtp; Received: from vorab.monex.li by mailpumpe.monex.li (8.11.6/8.11.6) with ESMTP id g914l1i26785; Tue, 1 Oct 2002 06:47:01 +0200 Subject: Re: Convert Log Format from old to v2 format From: Oliver Jehle To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1029360439.21217.179.camel@stout.americas.sgi.com> References: <1029319626.1094.22.camel@vorab> <1029360439.21217.179.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.8 Date: 01 Oct 2002 06:45:54 +0200 Message-Id: <1033447554.997.11.camel@vorab> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g914litG015526 X-archive-position: 677 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: oliver.jehle@monex.li Precedence: bulk X-list: linux-xfs Hi Eric.... i like to convert my current system (evms1.0.0/xfs1.1.0) to evms(1.2.0) and need to convert my log format to version 2. can you give me a hint where i can find the script to change the log format ???? thanks oliver On Wed, 2002-08-14 at 23:27, Eric Sandeen wrote: > Hi Oliver - > > There is a script here that's a perl wrapper around xfs_db - let me look > at it a bit and see what shape it's in. If it looks sane I'll put it > out there for testing. > > Thanks, > > -Eric > > > On Wed, 2002-08-14 at 05:07, Oliver Jehle wrote: > > is there a way to convert the logging format from old xfs-filestem to > > the new version 2 logging in xfs without backup/recreate/restore the > > filesystem ??? for example unmounting, run utility, mount it... > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. 651-683-3102 > -- Oliver Jehle Monex AG Föhrenweg 18 FL-9496 Balzers Tel: +423 388 1988 Fax: +423 388 1980 ---- I've not lost my mind. It's backed up on tape somewhere. ----