From owner-linux-xfs@oss.sgi.com Sun Feb 1 14:18:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Feb 2004 14:18:37 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i11MIJ7J028539 for ; Sun, 1 Feb 2004 14:18:20 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i11MIEtl023814 for ; Sun, 1 Feb 2004 16:18:14 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i11MIE5O32878499; Sun, 1 Feb 2004 16:18:14 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i11MID0n829278; Sun, 1 Feb 2004 16:18:13 -0600 (CST) Date: Sun, 1 Feb 2004 16:18:13 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Gaspar Bakos cc: linux-xfs@oss.sgi.com Subject: Re: system hangs after mounting XFS root fs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1952 X-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, 31 Jan 2004, Gaspar Bakos wrote: > Hi, > > I encountered a strange thing. My RH7.3 linux with 2.4.18 kernel, which > has been running fine in the past 3 months, after a reboot (issued by me) > stopped at the following lines: > > XFS mounting filesystem md(9,3) > XFS: WARNING: recovery required on readonly filesysten > Starting XFS recovery on filesystem: ... > Ending XFS recovery on filesystem: ... > VFS: mounted root (xfs filesystem) readonly At this point it's hard to know what's going on, but it looks like XFS is done for now, the root filesystem is mounted. If kdb is on, you could maybe break into kdb to see what's going on. Or perhaps the sysrq "t" command will tell you what tasks are running. -Eric From owner-linux-xfs@oss.sgi.com Sun Feb 1 16:40:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Feb 2004 16:40:23 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i120eI7J003425 for ; Sun, 1 Feb 2004 16:40:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i120eCMU025848 for ; Sun, 1 Feb 2004 18:40:12 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i120e9hI1931858 for ; Mon, 2 Feb 2004 11:40:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i120e9Bb1932357 for linux-xfs@oss.sgi.com; Mon, 2 Feb 2004 11:40:09 +1100 (EST) Date: Mon, 2 Feb 2004 11:40:09 +1100 (EST) From: Nathan Scott Message-Id: <200402020040.i120e9Bb1932357@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.2-rc3 X-archive-position: 1953 X-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 Feb 1 16:38:26 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:165978a drivers/usb/gadget/file_storage.c - 1.1 drivers/usb/host/ohci-omap.h - 1.1 drivers/usb/host/ohci-omap.c - 1.1 arch/ia64/sn/kernel/sn2/timer_interrupt.c - 1.1 Documentation/fb/modedb.txt - 1.3 Documentation/kernel-parameters.txt - 1.4 Makefile - 1.4 arch/arm/configs/cerfcube_defconfig - 1.2 arch/arm/kernel/asm-offsets.c - 1.2 arch/arm/kernel/entry-armv.S - 1.2 arch/arm/kernel/process.c - 1.2 arch/arm/kernel/ptrace.c - 1.2 arch/arm/lib/csumpartial.S - 1.2 arch/arm/lib/csumpartialcopygeneric.S - 1.2 arch/arm/lib/io-readsb.S - 1.2 arch/arm/lib/uaccess.S - 1.2 arch/arm/mach-sa1100/cerf.c - 1.2 arch/arm/mach-sa1100/generic.c - 1.2 arch/i386/boot/setup.S - 1.2 arch/i386/kernel/acpi/boot.c - 1.3 arch/i386/kernel/apm.c - 1.3 arch/i386/kernel/cpu/cpufreq/acpi.c - 1.3 arch/i386/kernel/dmi_scan.c - 1.3 arch/i386/kernel/io_apic.c - 1.3 arch/i386/kernel/mpparse.c - 1.3 arch/i386/kernel/setup.c - 1.3 arch/i386/mach-es7000/es7000.c - 1.2 arch/i386/pci/acpi.c - 1.2 arch/i386/pci/common.c - 1.2 arch/i386/pci/pci.h - 1.2 arch/ia64/Kconfig - 1.4 arch/ia64/hp/common/sba_iommu.c - 1.3 arch/ia64/kernel/entry.S - 1.3 arch/ia64/kernel/ia64_ksyms.c - 1.4 arch/ia64/kernel/irq_lsapic.c - 1.2 arch/ia64/kernel/smpboot.c - 1.4 arch/ia64/kernel/time.c - 1.3 arch/ia64/kernel/unaligned.c - 1.2 arch/ia64/mm/extable.c - 1.3 arch/ia64/mm/fault.c - 1.2 arch/ia64/sn/io/sn2/xbow.c - 1.3 arch/ia64/sn/kernel/sn2/Makefile - 1.3 arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.3 arch/sparc64/kernel/head.S - 1.3 arch/sparc64/kernel/power.c - 1.2 arch/sparc64/kernel/setup.c - 1.3 arch/sparc64/mm/init.c - 1.3 arch/x86_64/kernel/acpi/boot.c - 1.2 arch/x86_64/kernel/io_apic.c - 1.3 arch/x86_64/kernel/mpparse.c - 1.3 arch/x86_64/kernel/setup.c - 1.3 arch/x86_64/mm/extable.c - 1.3 arch/x86_64/mm/k8topology.c - 1.3 crypto/sha256.c - 1.2 drivers/acpi/ac.c - 1.2 drivers/acpi/asus_acpi.c - 1.2 drivers/acpi/battery.c - 1.2 drivers/acpi/bus.c - 1.2 drivers/acpi/button.c - 1.2 drivers/acpi/dispatcher/dsfield.c - 1.2 drivers/acpi/dispatcher/dsinit.c - 1.2 drivers/acpi/dispatcher/dsmethod.c - 1.2 drivers/acpi/dispatcher/dsmthdat.c - 1.2 drivers/acpi/dispatcher/dsobject.c - 1.2 drivers/acpi/dispatcher/dsopcode.c - 1.2 drivers/acpi/dispatcher/dsutils.c - 1.2 drivers/acpi/dispatcher/dswexec.c - 1.2 drivers/acpi/dispatcher/dswload.c - 1.2 drivers/acpi/dispatcher/dswscope.c - 1.2 drivers/acpi/dispatcher/dswstate.c - 1.2 drivers/acpi/ec.c - 1.2 drivers/acpi/events/evevent.c - 1.2 drivers/acpi/events/evgpe.c - 1.2 drivers/acpi/events/evgpeblk.c - 1.2 drivers/acpi/events/evmisc.c - 1.2 drivers/acpi/events/evregion.c - 1.2 drivers/acpi/events/evrgnini.c - 1.2 drivers/acpi/events/evsci.c - 1.2 drivers/acpi/events/evxface.c - 1.2 drivers/acpi/events/evxfevnt.c - 1.2 drivers/acpi/events/evxfregn.c - 1.2 drivers/acpi/executer/exconfig.c - 1.2 drivers/acpi/executer/exconvrt.c - 1.2 drivers/acpi/executer/excreate.c - 1.2 drivers/acpi/executer/exdump.c - 1.2 drivers/acpi/executer/exfield.c - 1.2 drivers/acpi/executer/exfldio.c - 1.2 drivers/acpi/executer/exmisc.c - 1.2 drivers/acpi/executer/exmutex.c - 1.2 drivers/acpi/executer/exnames.c - 1.2 drivers/acpi/executer/exoparg1.c - 1.2 drivers/acpi/executer/exoparg2.c - 1.2 drivers/acpi/executer/exoparg3.c - 1.2 drivers/acpi/executer/exoparg6.c - 1.2 drivers/acpi/executer/exprep.c - 1.2 drivers/acpi/executer/exregion.c - 1.2 drivers/acpi/executer/exresnte.c - 1.2 drivers/acpi/executer/exresolv.c - 1.2 drivers/acpi/executer/exresop.c - 1.2 drivers/acpi/executer/exstore.c - 1.2 drivers/acpi/executer/exstoren.c - 1.2 drivers/acpi/executer/exstorob.c - 1.2 drivers/acpi/executer/exsystem.c - 1.2 drivers/acpi/executer/exutils.c - 1.2 drivers/acpi/fan.c - 1.2 drivers/acpi/hardware/hwacpi.c - 1.2 drivers/acpi/hardware/hwgpe.c - 1.2 drivers/acpi/hardware/hwregs.c - 1.2 drivers/acpi/hardware/hwsleep.c - 1.2 drivers/acpi/hardware/hwtimer.c - 1.2 drivers/acpi/namespace/nsaccess.c - 1.2 drivers/acpi/namespace/nsalloc.c - 1.2 drivers/acpi/namespace/nsdump.c - 1.2 drivers/acpi/namespace/nsdumpdv.c - 1.2 drivers/acpi/namespace/nseval.c - 1.2 drivers/acpi/namespace/nsinit.c - 1.2 drivers/acpi/namespace/nsload.c - 1.2 drivers/acpi/namespace/nsnames.c - 1.2 drivers/acpi/namespace/nsobject.c - 1.2 drivers/acpi/namespace/nsparse.c - 1.2 drivers/acpi/namespace/nssearch.c - 1.2 drivers/acpi/namespace/nsutils.c - 1.2 drivers/acpi/namespace/nswalk.c - 1.2 drivers/acpi/namespace/nsxfeval.c - 1.2 drivers/acpi/namespace/nsxfname.c - 1.2 drivers/acpi/namespace/nsxfobj.c - 1.2 drivers/acpi/osl.c - 1.3 drivers/acpi/parser/psargs.c - 1.2 drivers/acpi/parser/psopcode.c - 1.2 drivers/acpi/parser/psparse.c - 1.2 drivers/acpi/parser/psscope.c - 1.2 drivers/acpi/parser/pstree.c - 1.2 drivers/acpi/parser/psutils.c - 1.2 drivers/acpi/parser/pswalk.c - 1.2 drivers/acpi/parser/psxface.c - 1.2 drivers/acpi/pci_link.c - 1.2 drivers/acpi/pci_root.c - 1.2 drivers/acpi/power.c - 1.2 drivers/acpi/processor.c - 1.2 drivers/acpi/resources/rsaddr.c - 1.2 drivers/acpi/resources/rscalc.c - 1.2 drivers/acpi/resources/rscreate.c - 1.2 drivers/acpi/resources/rsdump.c - 1.2 drivers/acpi/resources/rsio.c - 1.2 drivers/acpi/resources/rsirq.c - 1.2 drivers/acpi/resources/rslist.c - 1.2 drivers/acpi/resources/rsmemory.c - 1.2 drivers/acpi/resources/rsmisc.c - 1.2 drivers/acpi/resources/rsutils.c - 1.2 drivers/acpi/resources/rsxface.c - 1.2 drivers/acpi/scan.c - 1.2 drivers/acpi/sleep/proc.c - 1.2 drivers/acpi/tables.c - 1.2 drivers/acpi/tables/tbconvrt.c - 1.2 drivers/acpi/tables/tbget.c - 1.2 drivers/acpi/tables/tbgetall.c - 1.2 drivers/acpi/tables/tbinstal.c - 1.2 drivers/acpi/tables/tbrsdt.c - 1.2 drivers/acpi/tables/tbutils.c - 1.2 drivers/acpi/tables/tbxface.c - 1.2 drivers/acpi/tables/tbxfroot.c - 1.2 drivers/acpi/thermal.c - 1.2 drivers/acpi/toshiba_acpi.c - 1.2 drivers/acpi/utilities/utalloc.c - 1.2 drivers/acpi/utilities/utcopy.c - 1.2 drivers/acpi/utilities/utdebug.c - 1.2 drivers/acpi/utilities/utdelete.c - 1.2 drivers/acpi/utilities/uteval.c - 1.2 drivers/acpi/utilities/utglobal.c - 1.2 drivers/acpi/utilities/utinit.c - 1.2 drivers/acpi/utilities/utmath.c - 1.2 drivers/acpi/utilities/utmisc.c - 1.2 drivers/acpi/utilities/utobject.c - 1.2 drivers/acpi/utilities/utxface.c - 1.2 drivers/cpufreq/cpufreq.c - 1.2 drivers/i2c/busses/i2c-philips-par.c - 1.3 drivers/i2c/busses/i2c-piix4.c - 1.4 drivers/i2c/chips/lm75.c - 1.4 drivers/i2c/chips/lm78.c - 1.4 drivers/i2c/chips/lm85.c - 1.3 drivers/media/common/saa7146_hlp.c - 1.4 drivers/media/common/saa7146_video.c - 1.4 drivers/media/dvb/dvb-core/dvb_frontend.c - 1.3 drivers/media/dvb/frontends/alps_tdmb7.c - 1.3 drivers/media/dvb/frontends/nxt6000.c - 1.3 drivers/media/dvb/ttpci/Kconfig - 1.3 drivers/media/dvb/ttusb-dec/Kconfig - 1.3 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.4 drivers/mtd/maps/sa1100-flash.c - 1.2 drivers/net/irda/act200l.c - 1.2 drivers/net/irda/actisys-sir.c - 1.3 drivers/net/irda/actisys.c - 1.2 drivers/net/irda/ali-ircc.c - 1.3 drivers/net/irda/ep7211_ir.c - 1.2 drivers/net/irda/esi.c - 1.2 drivers/net/irda/girbil.c - 1.2 drivers/net/irda/irport.c - 1.2 drivers/net/irda/litelink.c - 1.2 drivers/net/irda/ma600.c - 1.2 drivers/net/irda/mcp2120.c - 1.2 drivers/net/irda/nsc-ircc.c - 1.2 drivers/net/irda/old_belkin.c - 1.2 drivers/net/irda/smsc-ircc2.c - 1.2 drivers/net/irda/tekram-sir.c - 1.3 drivers/net/irda/tekram.c - 1.2 drivers/net/irda/via-ircc.c - 1.2 drivers/net/irda/w83977af_ir.c - 1.2 drivers/net/wan/pc300_drv.c - 1.3 drivers/pci/bus.c - 1.2 drivers/pci/gen-devlist.c - 1.2 drivers/pci/hotplug/acpiphp.h - 1.2 drivers/pci/hotplug/acpiphp_core.c - 1.2 drivers/pci/hotplug/acpiphp_glue.c - 1.2 drivers/pci/hotplug/acpiphp_pci.c - 1.2 drivers/pci/hotplug/acpiphp_res.c - 1.2 drivers/pci/hotplug/cpcihp_zt5550.c - 1.2 drivers/pci/hotplug/pci_hotplug.h - 1.2 drivers/pci/hotplug/pci_hotplug_core.c - 1.2 drivers/pci/hotplug/pcihp_skeleton.c - 1.2 drivers/pci/names.c - 1.2 drivers/pci/pci-sysfs.c - 1.2 drivers/pci/pci.ids - 1.4 drivers/pci/probe.c - 1.3 drivers/pci/search.c - 1.2 drivers/pcmcia/sa1100_cerf.c - 1.2 drivers/serial/sunsab.c - 1.2 drivers/usb/Kconfig - 1.2 drivers/usb/core/hub.c - 1.3 drivers/usb/core/message.c - 1.3 drivers/usb/core/usb.c - 1.3 drivers/usb/core/usb.h - 1.2 drivers/usb/gadget/Kconfig - 1.3 drivers/usb/gadget/Makefile - 1.3 drivers/usb/gadget/ether.c - 1.3 drivers/usb/gadget/inode.c - 1.2 drivers/usb/gadget/net2280.c - 1.2 drivers/usb/gadget/net2280.h - 1.2 drivers/usb/gadget/zero.c - 1.3 drivers/usb/host/ohci-hcd.c - 1.3 drivers/usb/media/dabusb.c - 1.2 drivers/usb/misc/Kconfig - 1.4 drivers/usb/misc/auerswald.c - 1.2 drivers/usb/misc/tiglusb.c - 1.2 drivers/usb/serial/kobil_sct.c - 1.2 drivers/usb/serial/whiteheat.c - 1.3 drivers/usb/storage/scsiglue.c - 1.4 drivers/usb/storage/unusual_devs.h - 1.4 drivers/video/console/fbcon.c - 1.2 include/acpi/acconfig.h - 1.2 include/acpi/acdebug.h - 1.2 include/acpi/acdisasm.h - 1.2 include/acpi/acdispat.h - 1.2 include/acpi/acevents.h - 1.2 include/acpi/acexcep.h - 1.2 include/acpi/acglobal.h - 1.2 include/acpi/achware.h - 1.2 include/acpi/acinterp.h - 1.2 include/acpi/aclocal.h - 1.2 include/acpi/acmacros.h - 1.2 include/acpi/acnamesp.h - 1.2 include/acpi/acobject.h - 1.2 include/acpi/acoutput.h - 1.2 include/acpi/acparser.h - 1.2 include/acpi/acpi.h - 1.2 include/acpi/acpi_drivers.h - 1.2 include/acpi/acpiosxf.h - 1.2 include/acpi/acpixf.h - 1.2 include/acpi/acresrc.h - 1.2 include/acpi/acstruct.h - 1.2 include/acpi/actables.h - 1.2 include/acpi/actbl.h - 1.2 include/acpi/actbl1.h - 1.2 include/acpi/actbl2.h - 1.2 include/acpi/actypes.h - 1.2 include/acpi/acutils.h - 1.2 include/acpi/amlcode.h - 1.2 include/acpi/amlresrc.h - 1.2 include/acpi/platform/acenv.h - 1.2 include/acpi/platform/acgcc.h - 1.2 include/acpi/platform/aclinux.h - 1.2 include/acpi/processor.h - 1.2 include/asm-arm/arch-sa1100/cerf.h - 1.2 include/asm-arm/assembler.h - 1.2 include/asm-arm/bitops.h - 1.2 include/asm-arm/cacheflush.h - 1.2 include/asm-arm/thread_info.h - 1.2 include/asm-i386/acpi.h - 1.2 include/asm-i386/system.h - 1.2 include/asm-ia64/a.out.h - 1.2 include/asm-ia64/bugs.h - 1.2 include/asm-ia64/byteorder.h - 1.3 include/asm-ia64/checksum.h - 1.2 include/asm-ia64/current.h - 1.2 include/asm-ia64/errno.h - 1.2 include/asm-ia64/fcntl.h - 1.2 include/asm-ia64/ioctl.h - 1.2 include/asm-ia64/ioctls.h - 1.2 include/asm-ia64/machvec.h - 1.2 include/asm-ia64/machvec_sn1.h - 1.2 include/asm-ia64/machvec_sn2.h - 1.2 include/asm-ia64/mman.h - 1.2 include/asm-ia64/namei.h - 1.2 include/asm-ia64/numa.h - 1.4 include/asm-ia64/param.h - 1.2 include/asm-ia64/poll.h - 1.2 include/asm-ia64/posix_types.h - 1.2 include/asm-ia64/processor.h - 1.3 include/asm-ia64/resource.h - 1.2 include/asm-ia64/scatterlist.h - 1.2 include/asm-ia64/siginfo.h - 1.2 include/asm-ia64/signal.h - 1.2 include/asm-ia64/socket.h - 1.3 include/asm-ia64/sockios.h - 1.2 include/asm-ia64/stat.h - 1.2 include/asm-ia64/statfs.h - 1.3 include/asm-ia64/termbits.h - 1.2 include/asm-ia64/termios.h - 1.2 include/asm-ia64/tlb.h - 1.2 include/asm-ia64/types.h - 1.2 include/asm-ia64/uaccess.h - 1.4 include/asm-ia64/unaligned.h - 1.2 include/asm-ia64/user.h - 1.2 include/asm-sparc64/io.h - 1.2 include/asm-sparc64/sections.h - 1.2 include/asm-x86_64/acpi.h - 1.3 include/linux/pci.h - 1.3 include/linux/usb.h - 1.3 init/main.c - 1.4 ipc/msg.c - 1.2 kernel/power/pmdisk.c - 1.2 kernel/sched.c - 1.4 net/ipv6/tcp_ipv6.c - 1.2 sound/usb/usbaudio.c - 1.2 Documentation/i2c/porting-clients - 1.3 drivers/usb/gadget/serial.c - 1.2 drivers/net/irda/old_belkin-sir.c - 1.2 drivers/net/irda/mcp2120-sir.c - 1.2 drivers/net/irda/ma600-sir.c - 1.2 drivers/net/irda/litelink-sir.c - 1.2 drivers/net/irda/girbil-sir.c - 1.2 drivers/net/irda/act200l-sir.c - 1.2 drivers/i2c/busses/i2c-parport.h - 1.2 From owner-linux-xfs@oss.sgi.com Sun Feb 1 17:14:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Feb 2004 17:14:29 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i121EF7J004902 for ; Sun, 1 Feb 2004 17:14:16 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i121E9MU007923 for ; Sun, 1 Feb 2004 19:14:10 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i121ANf8005787 for ; Mon, 2 Feb 2004 12:10:23 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i121AMwU005786 for linux-xfs@oss.sgi.com; Mon, 2 Feb 2004 12:10:22 +1100 Date: Mon, 2 Feb 2004 12:10:22 +1100 From: FSG QA Message-Id: <200402020110.i121AMwU005786@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 1954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Minor xfstests tweaks - report kernel version in check as in bench. Date: Sun Feb 1 17:13:25 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165979a xfstests/common.rc - 1.32 xfstests/check - 1.17 xfstests/tools/auto-qa - 1.46 xfstests/bench - 1.26 From owner-linux-xfs@oss.sgi.com Sun Feb 1 17:44:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Feb 2004 17:44:56 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i121iY7J006461 for ; Sun, 1 Feb 2004 17:44:34 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i121iRMU018373 for ; Sun, 1 Feb 2004 19:44:28 -0600 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 MAA13610; Mon, 2 Feb 2004 12:44:16 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i121iEUc3426020; Mon, 2 Feb 2004 12:44:14 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i121hnpV001089; Mon, 2 Feb 2004 12:43:50 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i121hdRN001087; Mon, 2 Feb 2004 12:43:39 +1100 Date: Mon, 2 Feb 2004 12:43:39 +1100 From: Nathan Scott To: Jakub Bogusz , agruen@suse.de Cc: linux-xfs@oss.sgi.com, acl-devel@bestbits.at Subject: Re: Polish translation for attr and acl packages, some i18n notes Message-ID: <20040202014339.GA1014@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 1955 X-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 Thu, 29 Jan 2004 00:43:34 +0100, Jakub Bogusz wrote: > > I've just made Polish translation for these packages > (attr 2.4.14 and acl 2.2.22). > > pl.po files are available on > http://cyber.cs.net.pl/~qboosh/pl.po/attr-2.4.14.pl.po > http://cyber.cs.net.pl/~qboosh/pl.po/acl-2.2.22.pl.po > and can be included in future attr and acl releases > (I would be glad to see them there). Thanks Jakub, I've included your translations. > BTW - when preparing it I found that: > - in both packages ENABLE_GETTEXT is not defined automatically even if > --enable-gettext is passed (proper AC_DEFINE is missing?) Hmm... I'm not sure why that might be - it works for me with no changes or configure options (enabled by default too). > - included attr.pot and acl.pot included in packages were made for some > older version and not updated for current > (in most packages *.pot files are regenerated when making release, > just before packaging to bring them up to date) I'll update those then. There was a reason for not automatically updating them, IIRC it was to do with overwriting files which are also checked into the repository causing problems during builds, but too long ago for me to remember the exact issue there. The strings rarely change now, so I don't expect this to cause many problems in practice. They can be built by, eg., "make acl.pot" using the Makefile in the acl/po subdirectory. > - in attr/setfattr/setfattr.c:126 there is message containing: > "No filename found inline %d of standard input" > shouldn't it be "No filename found in line %d of standard input"? > (i.e. s/inline/in line/) Yep, right you are - I've fixed that now. Thanks! > -- > Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ > PLD Team http://www.pld-linux.org/ > > -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 1 17:45:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Feb 2004 17:45:48 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i121jk7J006684 for ; Sun, 1 Feb 2004 17:45:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i121jeMU019098 for ; Sun, 1 Feb 2004 19:45:40 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i121jchI1940728; Mon, 2 Feb 2004 12:45:38 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i121jbjA1938514; Mon, 2 Feb 2004 12:45:37 +1100 (EST) Date: Mon, 2 Feb 2004 12:45:37 +1100 (EST) From: Nathan Scott Message-Id: <200402020145.i121jbjA1938514@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - acl/attr update X-archive-position: 1956 X-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 Merge in acl/attr Polish message translations from Jakub Bogusz. Date: Sun Feb 1 17:45:03 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:165980a acl/po/pl.po - 1.1 attr/po/pl.po - 1.1 acl/VERSION - 1.63 acl/doc/CHANGES - 1.70 acl/debian/changelog - 1.56 attr/VERSION - 1.45 attr/doc/CHANGES - 1.53 attr/debian/changelog - 1.46 attr/setfattr/setfattr.c - 1.15 acl/po/acl.pot - 1.7 acl/po/Makefile - 1.8 attr/po/attr.pot - 1.3 attr/po/Makefile - 1.4 From owner-linux-xfs@oss.sgi.com Mon Feb 2 08:16:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 08:16:26 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12GGC7J017843 for ; Mon, 2 Feb 2004 08:16:12 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12GG6QB017094 for ; Mon, 2 Feb 2004 10:16:06 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i12GG5j833102208; Mon, 2 Feb 2004 10:16:05 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i12GG4kP489410; Mon, 2 Feb 2004 10:16:04 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i12GFu9i3746924; Mon, 2 Feb 2004 10:16:03 -0600 (CST) Message-Id: <200402021616.i12GFu9i3746924@clink.americas.sgi.com> To: John Groves cc: linux-xfs@oss.sgi.com Subject: Re: Dmapi questions Date: Mon, 02 Feb 2004 10:15:56 -0600 From: Dean Roehrich X-archive-position: 1957 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs >From: John Groves >I'm trying to track changes to a filesystem via dmapi. There are a few >things that I haven't figured out yet, and I'm hoping somebody can set >me straight. My filesystems can be huge, so want to avoid full scans to >the extent possible. I can get CREATE events, but in some cases I need >the filename & path to pass to a separate program. Maybe. Does it just need to access the file, or does it really need to know it's pathname? > * If I have a file handle, can I get the relevant the relevant > directory handle somehow? If so I could presumably use The CREATE event gave you the filehandle of the parent directory.... > dm_handle_to_path() to generate the path... You won't like it. Unix-based filesystems don't provide anything special for translating an inode into a filename; you just have to search the filesystem for the inode--and then you know the filename. There's nothing special about XFS in this regard. Also, the implementation of dm_handle_to_path that I wrote for libdm is aweful. I won't turn down a better implementation if it's offered. Anyway, you won't like it. > * Given a handle, how can I tell whether it is for a file or directory? dm_get_fileattr() will give you that info. Dean From owner-linux-xfs@oss.sgi.com Mon Feb 2 09:40:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 09:40:34 -0800 (PST) Received: from microtecsecurite.com (mail.microtecsecuri-t.com [199.84.138.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12HeU7J023628 for ; Mon, 2 Feb 2004 09:40:30 -0800 Received: from microtecsecurite.com [10.1.8.7] by microtecsecurite.com with ESMTP (SMTPD32-8.05) id AB893E501DA; Mon, 02 Feb 2004 12:40:25 -0500 Message-ID: <401E8B88.2040405@microtecsecurite.com> Date: Mon, 02 Feb 2004 12:40:24 -0500 From: Patrick Ouellet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-ca, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS restoration utility Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pouellet@microtecsecurite.com Precedence: bulk X-list: linux-xfs Hi, im new to xfs never used it personnaly but the other day I realised that our Linksys EFG80 NAS was working on xfs filesystem My problem is that the drive in this NAS has been corrupted in someway, and I would like to salvage data on this drive. So I put the drive in a Linux machine, installed the XFS kernel supplied of oss.sgi.com web site. But when I try to mount the drive mount -t xfs /dev/hdb1 /mnt/nas I get these errors: XFS: bad magic number XFS: SB validate failed mount: wrong fs type, bad option, bad superblock on /dev/hdb1 or too many mounted filesystems Is there a way for me to restore this drive, is there any utility that can be downloaded to restore this drive? Thanx for your time. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Patrick Ouellet - pouellet@microtecsecurite.com Administrateur des serveurs reseaux Informatique - Poste 130 Microtec Technologies inc. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "First they ignore you. Then they laugh at you. Then they fight you. Then you win." -Mahatma Gandhi =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From owner-linux-xfs@oss.sgi.com Mon Feb 2 12:05:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 12:05:30 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12K5G7J001038 for ; Mon, 2 Feb 2004 12:05:16 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12K4kVU011542 for ; Mon, 2 Feb 2004 12:04:46 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i12K3uMG33174157; Mon, 2 Feb 2004 14:03:56 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i12K3u0n928960; Mon, 2 Feb 2004 14:03:56 -0600 (CST) Date: Mon, 2 Feb 2004 14:03:56 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Patrick Ouellet cc: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility In-Reply-To: <401E8B88.2040405@microtecsecurite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1959 X-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 Mon, 2 Feb 2004, Patrick Ouellet wrote: > > Hi, im new to xfs never used it personnaly but > the other day I realised that our Linksys EFG80 NAS > was working on xfs filesystem Hm, very interesting... :) > My problem is that the drive in this NAS has been corrupted > in someway, and I would like to salvage data on this drive. > > So I put the drive in a Linux machine, installed the XFS kernel > supplied of oss.sgi.com web site. But when I try to mount the drive > > mount -t xfs /dev/hdb1 /mnt/nas Just to be sure, how do you know it's really xfs on-disk? > I get these errors: > > XFS: bad magic number > XFS: SB validate failed > mount: wrong fs type, bad option, bad superblock on /dev/hdb1 > or too many mounted filesystems try "dmesg' to see what kernel messages may have come from the failed mount. > Is there a way for me to restore this drive, is there any utility that > can be downloaded to restore this drive? Ask linksys... ;-) if it's really xfs, and they haven't munged it too much, you could try xfs_repair. (with -n to do a dry run first) -Eric > Thanx for your time. > > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Patrick Ouellet - pouellet@microtecsecurite.com > Administrateur des serveurs reseaux > Informatique - Poste 130 > Microtec Technologies inc. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > "First they ignore you. Then they laugh at you. > Then they fight you. Then you win." > -Mahatma Gandhi > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > From owner-linux-xfs@oss.sgi.com Mon Feb 2 12:14:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 12:14:20 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12KEI7J001651 for ; Mon, 2 Feb 2004 12:14:19 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12KEDQB030075 for ; Mon, 2 Feb 2004 14:14:13 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i12KEDMG33173144; Mon, 2 Feb 2004 14:14:13 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i12KED0n938260; Mon, 2 Feb 2004 14:14:13 -0600 (CST) Date: Mon, 2 Feb 2004 14:14:13 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Patrick Ouellet cc: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility In-Reply-To: <401E8B88.2040405@microtecsecurite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1960 X-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 It appears that it is in fact xfs, from looking at the 'firmware' image.... -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 2 13:20:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 13:20:35 -0800 (PST) Received: from imf13aec.mail.bellsouth.net (imf13aec.mail.bellsouth.net [205.152.59.61]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LK97J006643 for ; Mon, 2 Feb 2004 13:20:13 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf17aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040202195608.RNUT1917.imf17aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 2 Feb 2004 14:56:08 -0500 Subject: Re: noatime From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Robert Brockway Cc: Christoph Hellwig , AndyLiebman@aol.com, ewwhite@mac.com, linux-xfs@oss.sgi.com In-Reply-To: References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> Content-Type: text/plain Message-Id: <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Mon, 02 Feb 2004 14:55:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1961 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs On Sat, 2004-01-31 at 03:37, Robert Brockway wrote: > On Fri, 30 Jan 2004, Christoph Hellwig wrote: > > > There's no data-integrity issues, but there's certain applications that rely > > on atime information. > > The question is which apps. > > I usually mount filesystems noatime but the caveat has always been, > "watchout some apps require it". I think this has reached the point of > being unix folk-lore. > > I've asked many Sysadmins to name a single app that misbehaves if > filesystems are mounted noatime and (as far as I recall) no one has yet > presented a credible example. This isn't criticism of the claim, just a > genuine request. > > Can anyone name an application which misbehaves or breaks if filesystems > it relies on are mounted noatime? > > This is somewhat OT I know, but while we're talking about it... > > Rob Part of my company does computer forensics. As part of that our forensics team might testify in court that "Rob created a flat file export of the Customer Database on Dec 15, 03. He accessed this flat file at 2pm, Feb 2, 04. This is 2 hours after he was notified that he was being fired, so it is possible that he was making an improper copy to use outside the company." Obviously the above is not rock-solid evidence of IP theft, but it is far stronger than if the access time was not available. I know our forensic team wishes that all computers would maintain a much better history of access times than just the most recent. I guess what I'm saying is, if you are maintaining valuable info on a computer and the possibility of having to litigate about its use exists, then having access times available to a computer forensic examiner is a good idea. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Feb 2 13:31:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 13:31:30 -0800 (PST) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LVR7J009479 for ; Mon, 2 Feb 2004 13:31:28 -0800 Received: from zen.canint.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.138.11.154]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id i12LVFW0019752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 3 Feb 2004 07:31:18 +1000 Received: from zen.canint.timetraveller.org (zen.canint.timetraveller.org [192.168.120.1]) by zen.canint.timetraveller.org (8.12.11/8.12.11) with ESMTP id i12LUBsJ014505 for ; Mon, 2 Feb 2004 16:30:12 -0500 Date: Mon, 2 Feb 2004 16:30:11 -0500 (EST) From: Robert Brockway X-X-Sender: robert@zen.canint.timetraveller.org To: linux-xfs@oss.sgi.com Subject: Re: noatime In-Reply-To: <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> Message-ID: References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs On Mon, 2 Feb 2004, Greg Freemyer wrote: > "Rob created a flat file export of the Customer Database on Dec 15, 03. > He accessed this flat file at 2pm, Feb 2, 04. This is 2 hours after he > was notified that he was being fired, so it is possible that he was > making an improper copy to use outside the company." I do know of one such use of atime by a friend of mine while tracking an errant user. The problem (as I see it) is that a knowledgable user who owns the file or has root access (all too common on many boxes) will use /bin/touch to hide their tracks so I've long believed the usefulness of atime in this way was limited. Maybe I'm over-estimating errant users ;) > I guess what I'm saying is, if you are maintaining valuable info on a > computer and the possibility of having to litigate about its use exists, > then having access times available to a computer forensic examiner is a > good idea. Fair point. This reminds me of discussions relating to system optimization (eg, use of hdparm). If I really care about a system being rock solid and am not so worried about performance, I'm going to be much more conservative with hdparm optimizations. I suppose this could be said to be similar - being more conservative with a performance optimization (noatime) because I'd like the extra auditability. Cheers, Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Mon Feb 2 13:34:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 13:34:07 -0800 (PST) Received: from microtecsecurite.com (mail.microtecsecuri-t.com [199.84.138.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12LY37J009884 for ; Mon, 2 Feb 2004 13:34:04 -0800 Received: from microtecsecurite.com [10.1.8.7] by microtecsecurite.com with ESMTP (SMTPD32-8.05) id A246FD1022A; Mon, 02 Feb 2004 16:33:58 -0500 Message-ID: <401EC246.3070609@microtecsecurite.com> Date: Mon, 02 Feb 2004 16:33:58 -0500 From: Patrick Ouellet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-ca, en-us, en MIME-Version: 1.0 To: SGI XFS Subject: [Fwd: Re: XFS restoration utility] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1963 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pouellet@microtecsecurite.com Precedence: bulk X-list: linux-xfs I recent this mail to the list so that archive are complete. And I'm adding answer to a question you asked me about sending you the kernel message when I try to mount the drive. Here is the dmesg output ( I stripped everything that's related to booting) FAT: bogus logical sector size 28783 VFS: Can't find a valid FAT filesystem on dev 03:41. SGI XFS 1.3.1 with ACLs, no debug enabled SGI XFS Quota Management subsystem XFS: bad magic number XFS: SB validate failed The FAT & VFS message is related to when I try to mount the drive without specifying the filesystem type. ( mount -t xfs ) >>Hi, im new to xfs never used it personnaly but >>the other day I realised that our Linksys EFG80 NAS >>was working on xfs filesystem >Hm, very interesting... :) >>My problem is that the drive in this NAS has been corrupted >>in someway, and I would like to salvage data on this drive. >> >>So I put the drive in a Linux machine, installed the XFS kernel >>supplied of oss.sgi.com web site. But when I try to mount the drive >> >>mount -t xfs /dev/hdb1 /mnt/nas >Just to be sure, how do you know it's really xfs on-disk? The unit is composed of two disk, the second one didn't fail and I was able to mount the drive and use it with XFS. And before I installed the XFS enabled kernel, when I tried to mount the drive I had the error message: mount does not support XFS filesystems >>I get these errors: >> >>XFS: bad magic number >>XFS: SB validate failed >>mount: wrong fs type, bad option, bad superblock on /dev/hdb1 >>or too many mounted filesystems >try "dmesg' to see what kernel messages may have come from >the failed mount. >>Is there a way for me to restore this drive, is there any utility that >>can be downloaded to restore this drive? >Ask linksys... ;-) if it's really xfs, and they haven't munged >it too much, you could try xfs_repair. (with -n to do a dry run >first) HAHAHA when I contacted live support at Linksys, they were unable to tell me the exact type of filsystem used on their device, they could only tell me it was a Linux based system, so a linux based filesystem. >-Eric Thanx Eric for your comments, questions and answers. >Thanx for your time. > >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Patrick Ouellet - pouellet@microtecsecurite.com >Administrateur des serveurs reseaux >Informatique - Poste 130 >Microtec Technologies inc. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >"First they ignore you. Then they laugh at you. >Then they fight you. Then you win." >-Mahatma Gandhi >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From owner-linux-xfs@oss.sgi.com Mon Feb 2 14:04:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 14:05:51 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12M4a7J011106 for ; Mon, 2 Feb 2004 14:04:36 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12LwAVU032316 for ; Mon, 2 Feb 2004 13:58:10 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i12LvKw833141567; Mon, 2 Feb 2004 15:57:20 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i12LvK0n991720; Mon, 2 Feb 2004 15:57:20 -0600 (CST) Date: Mon, 2 Feb 2004 15:57:20 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Patrick Ouellet cc: SGI XFS Subject: Re: [Fwd: Re: XFS restoration utility] In-Reply-To: <401EC246.3070609@microtecsecurite.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1964 X-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 Mon, 2 Feb 2004, Patrick Ouellet wrote: > Here is the dmesg output ( I stripped everything that's related to booting) > > FAT: bogus logical sector size 28783 > VFS: Can't find a valid FAT filesystem on dev 03:41. > SGI XFS 1.3.1 with ACLs, no debug enabled > SGI XFS Quota Management subsystem > XFS: bad magic number > XFS: SB validate failed Ah, so it looks like the superblock is in fact bad; you could try xfs_db /dev/hdawhatever, then do xfs_db> sb 0 xfs_db> p and see what it says. However, this is really -ancient- xfs code, if it matches the kernel (linux-2.4.14-xfs) so debugging it will be tough (read: no time hehre to debug ancient codebase problems that have probably been fixed by now). OTOH you can probably hack the box to run something more recent... :) -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 2 14:26:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 14:26:30 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12MQH7J012033 for ; Mon, 2 Feb 2004 14:26:17 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12MQBdg004150 for ; Mon, 2 Feb 2004 14:26:12 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i12MQAw833188855; Mon, 2 Feb 2004 16:26:10 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AnmW9-0003Hs-00; Mon, 02 Feb 2004 16:26:09 -0600 Subject: TAKE 908436 - Fix buffer teardown on _pagebuf_lookup_pages failure Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com, sgi.bugs.snlinux@fido.engr.sgi.com, FTR@maine.americas.sgi.com Date: Mon, 02 Feb 2004 16:26:09 -0600 X-archive-position: 1965 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Feb 2 14:25:29 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:166032a fs/xfs/linux-2.6/xfs_buf.c - 1.140 - If a buffer is on the hash we can't simply call pagebuf_free on it. fs/xfs/linux-2.4/xfs_buf.c - 1.159 - If a buffer is on the hash we can't simply call pagebuf_free on it. From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:07:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:07:26 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12N7B7J013408 for ; Mon, 2 Feb 2004 15:07:12 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12N7uVU012258 for ; Mon, 2 Feb 2004 15:07:56 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i12N75w833212793; Mon, 2 Feb 2004 17:07:05 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ann9b-0003dz-00; Mon, 02 Feb 2004 17:06:55 -0600 Subject: TAKE 898070 - Remove the lockable/not lockable buffer distinction. Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Mon, 02 Feb 2004 17:06:55 -0600 X-archive-position: 1966 X-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 All metada buffers are lockable these days. Date: Mon Feb 2 15:06:23 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:166042a fs/xfs/linux-2.6/xfs_buf.h - 1.85 - remove definition of PBF_LOCKABLE fs/xfs/linux-2.6/xfs_buf.c - 1.141 - remove checks for _PBF_LOCKABLE fs/xfs/linux-2.4/xfs_buf.h - 1.90 - remove definition of PBF_LOCKABLE fs/xfs/linux-2.4/xfs_buf.c - 1.160 - remove checks for _PBF_LOCKABLE From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:24:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:25:21 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12NOv7J014256 for ; Mon, 2 Feb 2004 15:24:57 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i12NOoOZ014527 for ; Mon, 2 Feb 2004 15:24:51 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i12NOlhI2003475; Tue, 3 Feb 2004 10:24:47 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i12NOkjr2031991; Tue, 3 Feb 2004 10:24:46 +1100 (EST) Date: Tue, 3 Feb 2004 10:24:46 +1100 (EST) From: Nathan Scott Message-Id: <200402022324.i12NOkjr2031991@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 908796 - tweak pagebuf list manipulation code X-archive-position: 1967 X-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 Use list_move for moving pagebufs between lists, not list_add/list_del. Date: Mon Feb 2 15:23:48 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166046a linux-2.6/xfs_buf.c - 1.142 linux-2.4/xfs_buf.c - 1.161 From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:28:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:28:53 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12NSo7J014735 for ; Mon, 2 Feb 2004 15:28:50 -0800 Received: from stinkpad ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id PAA11677 for ; Mon, 2 Feb 2004 15:28:56 -0800 Message-Id: <200402022328.PAA11677@amber.he.net> From: "Mike Young" To: Subject: Snapshots with external logs Date: Mon, 2 Feb 2004 15:28:57 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcPp5FPUq3Dk/ZJuTVGkWG4c3R7YKA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 284 X-archive-position: 1968 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Hi, I was wondering if anyone using the external logs also utilizes snapshots. I'm trying to figure out how to do this so I can recover properly in the case of rollback. Any help on this is greatly appreciated. Thanks, Mike [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:36:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:37:01 -0800 (PST) Received: from gate.firmix.at (gate.firmix.at [80.109.18.208]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Naq7J015323 for ; Mon, 2 Feb 2004 15:36:54 -0800 Received: from buffy.firmix.at ([10.0.0.10]) by gate.firmix.at (8.12.8/8.12.8) with ESMTP id i12NakI6004314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Feb 2004 00:36:46 +0100 Received: from localhost (gate.firmix.at [10.0.0.1]) (authenticated bits=0) by buffy.firmix.at (8.12.8/8.12.8) with ESMTP id i12NajKr000511 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 3 Feb 2004 00:36:46 +0100 Subject: Re: noatime From: Bernd Petrovitsch To: linux-xfs@oss.sgi.com In-Reply-To: <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> Content-Type: text/plain Organization: http://www.firmix.at/ Message-Id: <1075765005.3722.9.camel@gimli.at.home> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 03 Feb 2004 00:36:45 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 1969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bernd@firmix.at Precedence: bulk X-list: linux-xfs On Mon, 2004-02-02 at 20:55, Greg Freemyer wrote: [...] > Part of my company does computer forensics. As part of that our > forensics team might testify in court that > > "Rob created a flat file export of the Customer Database on Dec 15, 03. > He accessed this flat file at 2pm, Feb 2, 04. This is 2 hours after he > was notified that he was being fired, so it is possible that he was > making an improper copy to use outside the company." > > Obviously the above is not rock-solid evidence of IP theft, but it is > far stronger than if the access time was not available. Given the possibilities to fake that info it is[0] (for usage in court or similar) probably better to actually have no atime. > I know our forensic team wishes that all computers would maintain a much > better history of access times than just the most recent. But if you (or someone) wants to use it in court (or similar) it should not be easy to fake[0]. So this rules almost all computer-related stuff completely out. > I guess what I'm saying is, if you are maintaining valuable info on a > computer and the possibility of having to litigate about its use exists, > then having access times available to a computer forensic examiner is a > good idea. Yes. But time info on an a computers harddisk is far from "valuable" because it is quite easy to manipulate it[0]. Sorry for OT .... Bernd [0]: Yes, this depends on circumstances etc. -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:52:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:52:19 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Nq57J016801 for ; Mon, 2 Feb 2004 15:52:06 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id B5A74FB89B; Mon, 2 Feb 2004 17:51:46 -0600 (CST) Date: Mon, 2 Feb 2004 15:51:46 -0800 From: Chris Wedgwood To: Greg Freemyer Cc: Robert Brockway , Christoph Hellwig , AndyLiebman@aol.com, ewwhite@mac.com, linux-xfs@oss.sgi.com Subject: [OT] noatime Message-ID: <20040202235146.GC493@dingdong.cryptoapps.com> References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> X-archive-position: 1970 X-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, Feb 02, 2004 at 02:55:34PM -0500, Greg Freemyer wrote: > "Rob created a flat file export of the Customer Database on Dec 15, > 03. He accessed this flat file at 2pm, Feb 2, 04. This is 2 hours > after he was notified that he was being fired, so it is possible > that he was making an improper copy to use outside the company." I'm amazed that stands up in court for a regular filesystem on a regular OS[1]. Lots of things mess with atime (some backup software for example). If you have permissions on the file you can trivially reset it by hand if you wanted: cw@pain:~$ ls -l --time=atime secret-stuff.doc -rw-r--r-- 2 cw cw 144159 Aug 6 05:33 secret-stuff.doc cw@pain:~$ touch -r secret-stuff.doc .timeref cw@pain:~$ ls -l --time=atime .timeref -rw-r--r-- 1 cw cw 0 Aug 6 05:33 .timeref cw@pain:~$ cp secret-stuff.doc jokes.doc cw@pain:~$ ls -l --time=atime secret-stuff.doc -rw-r--r-- 2 cw cw 144159 Feb 2 15:42 secret-stuff.doc cw@pain:~$ touch -r .timeref -a secret-stuff.doc cw@pain:~$ ls -l --time=atime secret-stuff.doc -rw-r--r-- 2 cw cw 144159 Aug 6 05:33 secret-stuff.doc As a practical joke I once wrote a daemon that scanned proxy logs and downloaded random mpegs into various people's home directories.. obviously this frobbed the atime and mtime to try and keep up the illusion. > Obviously the above is not rock-solid evidence of IP theft, but it > is far stronger than if the access time was not available. I would argue it's not very strong at all. --cw From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:52:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:52:40 -0800 (PST) Received: from imf17aec.mail.bellsouth.net (imf17aec.mail.bellsouth.net [205.152.59.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12Nqc7J016915 for ; Mon, 2 Feb 2004 15:52:38 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf17aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040202235233.YBMJ1917.imf17aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 2 Feb 2004 18:52:33 -0500 Subject: Re: Snapshots with external logs From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Mike Young Cc: linux-xfs@oss.sgi.com In-Reply-To: <200402022328.PAA11677@amber.he.net> References: <200402022328.PAA11677@amber.he.net> Content-Type: text/plain Message-Id: <1075765917.13711.21.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Mon, 02 Feb 2004 18:51:57 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1971 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs On Mon, 2004-02-02 at 18:28, Mike Young wrote: > Hi, > > > > I was wondering if anyone using the external logs also utilizes snapshots. > I'm trying to figure out how to do this so I can recover properly in the > case of rollback. Any help on this is greatly appreciated. > > > > Thanks, > > > > Mike > How are you doing snapshot rollbacks? I have never been exposed to that concept. Does anyone know if xfs_freeze flushes the log to disk? If xfs_freeze does cause the log to be flushed to disk, you don't need to snapshot the log. You just rollback the snapshot of the data volume, and clear the log volume. FYI: The vfs_lock kernel patch invokes the same logic as xfs_freeze, so it too flushes the disk if I am right. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Feb 2 15:54:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 15:54:30 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i12NsK7J017563 for ; Mon, 2 Feb 2004 15:54:21 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 2DE3CFB89B; Mon, 2 Feb 2004 17:54:20 -0600 (CST) Date: Mon, 2 Feb 2004 15:54:20 -0800 From: Chris Wedgwood To: Dean Roehrich Cc: John Groves , linux-xfs@oss.sgi.com Subject: Re: Dmapi questions Message-ID: <20040202235420.GD493@dingdong.cryptoapps.com> References: <200402021616.i12GFu9i3746924@clink.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402021616.i12GFu9i3746924@clink.americas.sgi.com> X-archive-position: 1972 X-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, Feb 02, 2004 at 10:15:56AM -0600, Dean Roehrich wrote: > You won't like it. Unix-based filesystems don't provide anything > special for translating an inode into a filename; you just have to > search the filesystem for the inode--and then you know the filename. Under Linux you could walk the dentries and get a usable path at the VFS layer. There is already code that does this. In fact, I was considering various ways to do something like dnotify that would give full path information via a magic network socket or something (exactly how it should work is still unclear to me, different permissions along the path might mean you aren't entitled to events you would otherwise get). --cw From owner-linux-xfs@oss.sgi.com Mon Feb 2 16:13:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 16:13:35 -0800 (PST) Received: from imf16aec.mail.bellsouth.net (imf16aec.mail.bellsouth.net [205.152.59.64]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i130DF7J018459 for ; Mon, 2 Feb 2004 16:13:15 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf16aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040203001309.HBWN1899.imf16aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Mon, 2 Feb 2004 19:13:09 -0500 Subject: Re: noatime From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Bernd Petrovitsch Cc: linux-xfs@oss.sgi.com In-Reply-To: <1075765005.3722.9.camel@gimli.at.home> References: <115.2e2700bf.2d4bf471@aol.com> <20040130175756.A23646@infradead.org> <1075751733.13701.11.camel@david.internal.NorcrossGroup.com> <1075765005.3722.9.camel@gimli.at.home> Content-Type: text/plain Message-Id: <1075767154.13711.42.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Mon, 02 Feb 2004 19:12:34 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1973 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs On Mon, 2004-02-02 at 18:36, Bernd Petrovitsch wrote: > On Mon, 2004-02-02 at 20:55, Greg Freemyer wrote: > [...] > > Part of my company does computer forensics. As part of that our > > forensics team might testify in court that > > > > "Rob created a flat file export of the Customer Database on Dec 15, 03. > > He accessed this flat file at 2pm, Feb 2, 04. This is 2 hours after he > > was notified that he was being fired, so it is possible that he was > > making an improper copy to use outside the company." > > > > Obviously the above is not rock-solid evidence of IP theft, but it is > > far stronger than if the access time was not available. > > Given the possibilities to fake that info it is[0] (for usage in court > or similar) probably better to actually have no atime. > I don't do the forensic work myself but I know our examiners try to use the access time (and create/modify). FYI: About 10 years ago I was working at a company were a manager inadvertently corrupted some important files. For some reason, he did not want to accept responsibility. As you said, he manipulated the files and the access times to make it look like one of the consultants did it. The data was important enough that a small internal investigation was done and shell history logs for everyone with access to the data was reviewed. It turned out the manager did not clean up his shell history file so all of his activities became obvious. He did not have a job for much longer. > > I know our forensic team wishes that all computers would maintain a much > > better history of access times than just the most recent. > > But if you (or someone) wants to use it in court (or similar) it should > not be easy to fake[0]. So this rules almost all computer-related stuff > completely out. I recently heard that 50% of all new FBI cases have a computer forensics portion. Those results are definately reported in court. I believe our main examiner testifies a couple times a month. FYI: I don't know the source of the 50% number, so treat it as rumor. > > > I guess what I'm saying is, if you are maintaining valuable info on a > > computer and the possibility of having to litigate about its use exists, > > then having access times available to a computer forensic examiner is a > > good idea. > > Yes. But time info on an a computers harddisk is far from "valuable" > because it is quite easy to manipulate it[0]. I was talking to company several months ago in the "web-hosting" business. They claimed to get 5 or more FBI requests per week to preserve server hard-disks. The assumption in turn is that the FBI analyses the harddisks. I suspect they like having date/time info on there. That is doubly true if only the web-hosting personnel have shell accounts. FYI: As I understand it, the preservation request does not require a court order. Actual analysis of the data does. > Sorry for OT .... > Bernd > > [0]: Yes, this depends on circumstances etc. Greg From owner-linux-xfs@oss.sgi.com Mon Feb 2 16:13:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 16:14:01 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i130Dw7J018621 for ; Mon, 2 Feb 2004 16:13:59 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i130DrOZ023964 for ; Mon, 2 Feb 2004 16:13:53 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i130Dqw833031553; Mon, 2 Feb 2004 18:13:52 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AnoCN-00045x-00; Mon, 02 Feb 2004 18:13:51 -0600 Subject: TAKE 908003 - "backport" d_alloc_anon Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Mon, 02 Feb 2004 18:13:51 -0600 X-archive-position: 1974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Feb 2 16:13:28 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:166048a fs/xfs/dmapi/dmapi_xfs.c - 1.27 - use generic d_alloc_anon routine instead of opencoding fs/xfs/dmapi/dmapi_register.c - 1.30 - use generic d_alloc_anon routine instead of opencoding fs/xfs/linux-2.4/xfs_ioctl.c - 1.103 - use generic d_alloc_anon routine instead of opencoding fs/xfs/linux-2.4/xfs_super.h - 1.59 - add d_alloc_anon prototype fs/xfs/linux-2.4/xfs_super.c - 1.280 - use generic d_alloc_anon routine instead of opencoding From owner-linux-xfs@oss.sgi.com Mon Feb 2 16:17:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 16:17:01 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i130Gw7J019339 for ; Mon, 2 Feb 2004 16:16:59 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AnoFC-0000CK-5H; Tue, 03 Feb 2004 00:16:46 +0000 Date: Tue, 3 Feb 2004 00:16:45 +0000 From: Christoph Hellwig To: Chris Wedgwood Cc: Dean Roehrich , John Groves , linux-xfs@oss.sgi.com Subject: Re: Dmapi questions Message-ID: <20040203001645.A685@infradead.org> References: <200402021616.i12GFu9i3746924@clink.americas.sgi.com> <20040202235420.GD493@dingdong.cryptoapps.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: <20040202235420.GD493@dingdong.cryptoapps.com>; from cw@f00f.org on Mon, Feb 02, 2004 at 03:54:20PM -0800 X-archive-position: 1975 X-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, Feb 02, 2004 at 03:54:20PM -0800, Chris Wedgwood wrote: > > You won't like it. Unix-based filesystems don't provide anything > > special for translating an inode into a filename; you just have to > > search the filesystem for the inode--and then you know the filename. > > Under Linux you could walk the dentries and get a usable path at the > VFS layer. There is already code that does this. You can't. To get a path you also need a vfsmnt. > In fact, I was considering various ways to do something like dnotify > that would give full path information via a magic network socket or > something (exactly how it should work is still unclear to me, > different permissions along the path might mean you aren't entitled to > events you would otherwise get). Again doesn't work. You can give the names of the directory entries to dnotify (in fact I did a hack like that not long ago), but not a full filename. From owner-linux-xfs@oss.sgi.com Mon Feb 2 16:26:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 16:26:25 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i130QC7J022825 for ; Mon, 2 Feb 2004 16:26:12 -0800 Received: from stinkpad ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id QAA17886; Mon, 2 Feb 2004 16:26:16 -0800 Message-Id: <200402030026.QAA17886@amber.he.net> From: "Mike Young" To: Cc: Subject: RE: Snapshots with external logs Date: Mon, 2 Feb 2004 16:26:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1075765917.13711.21.camel@david.internal.NorcrossGroup.com> Thread-Index: AcPp56RRXEkBPwZBQI6mEhqrIdKhfQABDH7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-archive-position: 1976 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Hi Greg, Thanks for the quick response. I'm using LVM for the snapshot and rollback. You're right it is doing an xfs_freeze, which does flush the log to disk. So, without the log present, I'm sure I'm going to have to use some option at mount time to create a new log. Is this a correct assumption? Do you know what the option will be so I can just automate the mount? Thanks, Mike -----Original Message----- From: Greg Freemyer [mailto:freemyer-ml@NorcrossGroup.com] Sent: Monday, February 02, 2004 3:52 PM To: Mike Young Cc: linux-xfs@oss.sgi.com Subject: Re: Snapshots with external logs On Mon, 2004-02-02 at 18:28, Mike Young wrote: > Hi, > > > > I was wondering if anyone using the external logs also utilizes snapshots. > I'm trying to figure out how to do this so I can recover properly in the > case of rollback. Any help on this is greatly appreciated. > > > > Thanks, > > > > Mike > How are you doing snapshot rollbacks? I have never been exposed to that concept. Does anyone know if xfs_freeze flushes the log to disk? If xfs_freeze does cause the log to be flushed to disk, you don't need to snapshot the log. You just rollback the snapshot of the data volume, and clear the log volume. FYI: The vfs_lock kernel patch invokes the same logic as xfs_freeze, so it too flushes the disk if I am right. Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Mon Feb 2 17:38:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 17:38:47 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i131cW7J025322 for ; Mon, 2 Feb 2004 17:38:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i131cR7L011111 for ; Mon, 2 Feb 2004 19:38:27 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i131cQal33211905; Mon, 2 Feb 2004 19:38:26 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i131cQ0n1121663; Mon, 2 Feb 2004 19:38:26 -0600 (CST) Date: Mon, 2 Feb 2004 19:38:26 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mike Young cc: freemyer-ml@NorcrossGroup.com, Subject: RE: Snapshots with external logs In-Reply-To: <200402030026.QAA17886@amber.he.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1977 X-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 freeze does indeed flush the log; in fact it also writes an unmount record to disk. If you're snapshotting off to some other device and want to mount it, just have any old device around that is at least as big as your log, and dd zeros into it to zero the whole log space. Then you can mount it up. If I'm understanding what you're asking... -Eric On Mon, 2 Feb 2004, Mike Young wrote: > Hi Greg, > > Thanks for the quick response. > > I'm using LVM for the snapshot and rollback. You're right it is doing an > xfs_freeze, which does flush the log to disk. So, without the log present, > I'm sure I'm going to have to use some option at mount time to create a new > log. Is this a correct assumption? Do you know what the option will be so > I can just automate the mount? > > Thanks, > From owner-linux-xfs@oss.sgi.com Mon Feb 2 17:54:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 17:54:44 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i131sg7J026194 for ; Mon, 2 Feb 2004 17:54:43 -0800 Received: from spindle.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i131sbOZ014045 for ; Mon, 2 Feb 2004 17:54:37 -0800 Received: from gollum (dhcp11.melbourne.sgi.com [134.14.55.11]) by spindle.corp.sgi.com (8.12.9/8.12.9/generic_config-1.2) with SMTP id i131sK2a5083373; Mon, 2 Feb 2004 17:54:22 -0800 (PST) From: "Mike Gigante" To: "Christoph Hellwig" , "Chris Wedgwood" Cc: "Dean Roehrich" , "John Groves" , Subject: RE: Dmapi questions Date: Tue, 3 Feb 2004 12:54:20 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <20040203001645.A685@infradead.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-archive-position: 1978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mg@sgi.com Precedence: bulk X-list: linux-xfs It sounds like the original poster should look at imon/fam. Mike From owner-linux-xfs@oss.sgi.com Mon Feb 2 19:43:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 19:43:21 -0800 (PST) Received: from zok.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i133h87J029380 for ; Mon, 2 Feb 2004 19:43:08 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i133h1OZ010590 for ; Mon, 2 Feb 2004 19:43:02 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i133h0hI2159006 for ; Tue, 3 Feb 2004 14:43:00 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i133gx3X2160303 for linux-xfs@oss.sgi.com; Tue, 3 Feb 2004 14:42:59 +1100 (EST) Date: Tue, 3 Feb 2004 14:42:59 +1100 (EST) From: Nathan Scott Message-Id: <200402030342.i133gx3X2160303@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 907983 - tweak 2.6 fs/Kconfig X-archive-position: 1979 X-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 Update XFS config items help text, add in security label option. Date: Mon Feb 2 19:42:01 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166065a fs/Kconfig - 1.4 From owner-linux-xfs@oss.sgi.com Mon Feb 2 20:27:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 20:27:27 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i134RP7J002055 for ; Mon, 2 Feb 2004 20:27:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i134RK7L029637 for ; Mon, 2 Feb 2004 22:27:20 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i134RKal33338559 for ; Mon, 2 Feb 2004 22:27:20 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i134RI4X915601; Mon, 2 Feb 2004 22:27:18 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i134Pkxs012688; Mon, 2 Feb 2004 22:25:46 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i134PkEF012686; Mon, 2 Feb 2004 22:25:46 -0600 Date: Mon, 2 Feb 2004 22:25:46 -0600 From: Eric Sandeen Message-Id: <200402030425.i134PkEF012686@penguin.americas.sgi.com> Subject: PARTIAL TAKE 907982 - X-archive-position: 1980 X-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@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Fix a few more leaks in libxfs/xfs_repair Date: Mon Feb 2 20:26:51 PST 2004 Workarea: penguin.americas.sgi.com:/src/sandeen/xfs-cmds Inspected by: nathans,hch The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166066a xfsprogs/doc/CHANGES - 1.134 - doc changes xfsprogs/repair/dir2.c - 1.15 - free up bplist, this was a fairly significant leak xfsprogs/repair/sb.c - 1.16 - remove #if 0'd code, check_growfs xfsprogs/repair/protos.h - 1.6 - remove unused check_growfs prototype xfsprogs/repair/io.c - 1.10 - don't alloc a handful of memory that was never used for anything anyway... xfsprogs/libxfs/init.c - 1.34 - free up pagb_lists that were never explicitly freed From owner-linux-xfs@oss.sgi.com Mon Feb 2 21:25:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Feb 2004 21:25:50 -0800 (PST) Received: from amber.he.net (amber.he.net [216.218.172.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i135PZ7J003896 for ; Mon, 2 Feb 2004 21:25:35 -0800 Received: from stinkpad ([208.35.40.2] (may be forged)) by amber.he.net (8.8.6p2003-03-31/8.8.2) with ESMTP id VAA11751; Mon, 2 Feb 2004 21:25:43 -0800 Message-Id: <200402030525.VAA11751@amber.he.net> From: "Mike Young" To: "'Eric Sandeen'" Cc: Subject: RE: Snapshots with external logs Date: Mon, 2 Feb 2004 21:25:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Thread-Index: AcPp9nDJiBDIpBGIQbu3wmiQ07r/7gAHwj+g X-archive-position: 1981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: myoung@wildernessvoice.com Precedence: bulk X-list: linux-xfs Hi Eric, Thanks for the response. It sounds like I only have to worry about snapshotting the data volume and then if my external log is on another device I can just reset it using dd and the configured block-size and block count, which the log was created with. Is this to prevent me from having an inconsistent file-system? And it also sounds like the zeroing of the log is only necessary if I implement a rollback. Otherwise the log and the filesystem should be consistent. I hope that makes sense to you. I'm just trying to see if I've got the gist of things. -Mike -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Monday, February 02, 2004 5:38 PM To: Mike Young Cc: freemyer-ml@NorcrossGroup.com; linux-xfs@oss.sgi.com Subject: RE: Snapshots with external logs freeze does indeed flush the log; in fact it also writes an unmount record to disk. If you're snapshotting off to some other device and want to mount it, just have any old device around that is at least as big as your log, and dd zeros into it to zero the whole log space. Then you can mount it up. If I'm understanding what you're asking... -Eric On Mon, 2 Feb 2004, Mike Young wrote: > Hi Greg, > > Thanks for the quick response. > > I'm using LVM for the snapshot and rollback. You're right it is doing an > xfs_freeze, which does flush the log to disk. So, without the log present, > I'm sure I'm going to have to use some option at mount time to create a new > log. Is this a correct assumption? Do you know what the option will be so > I can just automate the mount? > > Thanks, > From owner-linux-xfs@oss.sgi.com Tue Feb 3 01:04:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 01:04:50 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1394SKO022661 for ; Tue, 3 Feb 2004 01:04:28 -0800 Received: from erbenson.alaska.net (201-pm20.nwc.alaska.net [209.112.142.201]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id i1394LN7081552 for ; Tue, 3 Feb 2004 00:04:24 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id CAEC439EC for ; Tue, 3 Feb 2004 00:04:17 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id CE21140FF35; Tue, 3 Feb 2004 00:04:16 -0900 (AKST) Date: Tue, 3 Feb 2004 00:04:16 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility Message-ID: <20040203090416.GU5676@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <401E8B88.2040405@microtecsecurite.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+mr2ctTDD1GjnQwB" Content-Disposition: inline In-Reply-To: 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-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.61; spamdefang 1.93 X-archive-position: 1982 X-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 --+mr2ctTDD1GjnQwB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 02, 2004 at 02:14:13PM -0600, Eric Sandeen wrote: > It appears that it is in fact xfs, from looking at the > 'firmware' image.... are they making full source code available as required by the GPL? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --+mr2ctTDD1GjnQwB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkAfZBAACgkQJKx7GixEevy1ZQCfSCQyAS71cb7yz+rpYu8rIUG6 D0YAni5e/bMUMCGfNa6ALjFyAbFNyev7 =AZic -----END PGP SIGNATURE----- --+mr2ctTDD1GjnQwB-- From owner-linux-xfs@oss.sgi.com Tue Feb 3 05:11:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 05:11:58 -0800 (PST) Received: from microtecsecurite.com (mail.microtecsecuri-t.com [199.84.138.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13DBbKO011832 for ; Tue, 3 Feb 2004 05:11:38 -0800 Received: from microtecsecurite.com [10.1.8.7] by microtecsecurite.com with ESMTP (SMTPD32-8.05) id AE037A20198; Tue, 03 Feb 2004 08:11:31 -0500 Message-ID: <401F9E03.2070105@microtecsecurite.com> Date: Tue, 03 Feb 2004 08:11:31 -0500 From: Patrick Ouellet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr-ca, en-us, en MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility References: <401E8B88.2040405@microtecsecurite.com> <20040203090416.GU5676@plato.local.lan> In-Reply-To: <20040203090416.GU5676@plato.local.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pouellet@microtecsecurite.com Precedence: bulk X-list: linux-xfs Yes they are, you can go to they're support web site you'll find a section Download GPL Code. Ethan Benson wrote: >On Mon, Feb 02, 2004 at 02:14:13PM -0600, Eric Sandeen wrote: > > >>It appears that it is in fact xfs, from looking at the >>'firmware' image.... >> >> > >are they making full source code available as required by the GPL? > > > -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Patrick Ouellet - pouellet@microtecsecurite.com Administrateur des serveurs reseaux Informatique - Poste 130 Microtec Technologies inc. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "First they ignore you. Then they laugh at you. Then they fight you. Then you win." -Mahatma Gandhi =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= From owner-linux-xfs@oss.sgi.com Tue Feb 3 05:53:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 05:54:05 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13DrpKO018275 for ; Tue, 3 Feb 2004 05:53:51 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i13DrkoM012643 for ; Tue, 3 Feb 2004 07:53:46 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i13DrjxF33429907; Tue, 3 Feb 2004 07:53:45 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i13DrjkP798163; Tue, 3 Feb 2004 07:53:45 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i13Drb9i4058337; Tue, 3 Feb 2004 07:53:38 -0600 (CST) Message-Id: <200402031353.i13Drb9i4058337@clink.americas.sgi.com> To: Chris Wedgwood cc: John Groves , linux-xfs@oss.sgi.com Subject: Re: Dmapi questions Date: Tue, 03 Feb 2004 07:53:37 -0600 From: Dean Roehrich X-archive-position: 1984 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs >From: Chris Wedgwood >On Mon, Feb 02, 2004 at 10:15:56AM -0600, Dean Roehrich wrote: > >> You won't like it. Unix-based filesystems don't provide anything >> special for translating an inode into a filename; you just have to >> search the filesystem for the inode--and then you know the filename. > >Under Linux you could walk the dentries and get a usable path at the >VFS layer. There is already code that does this. You're presuming that the file has already been accessed via a pathname, and that it's still in the dcache. When you have a filehandle, you don't need a pathname. >(exactly how it should work is still unclear to me, >different permissions along the path might mean you aren't entitled to >events you would otherwise get). If an HSM is supposed to make that filesystem appear bottomless, then it must have sufficient privilege to see everything that happens on that filesystem. Dean From owner-linux-xfs@oss.sgi.com Tue Feb 3 07:07:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 07:07:43 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13F7fKO021462 for ; Tue, 3 Feb 2004 07:07:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i13F63hb004480 for ; Tue, 3 Feb 2004 07:06:03 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i13F59xF33429492; Tue, 3 Feb 2004 09:05:09 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i13F570n1638913; Tue, 3 Feb 2004 09:05:08 -0600 (CST) Date: Tue, 3 Feb 2004 09:05:07 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ethan Benson cc: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility In-Reply-To: <20040203090416.GU5676@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1985 X-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 Tue, 3 Feb 2004, Ethan Benson wrote: > On Mon, Feb 02, 2004 at 02:14:13PM -0600, Eric Sandeen wrote: > > It appears that it is in fact xfs, from looking at the > > 'firmware' image.... > > are they making full source code available as required by the GPL? Not on the web site, I also do not see the gpl "offer" anywhere in the firmware package. They do have a "gpl code center" with downloads for many of their linux-based products (and there are a lot!) but this product is not there. I reminded them nicely, in a non-sgi capacity, to include this code as well, let's give it a little time before we bring the full wrath of slashdot down upon their heads. ;-) (p.s. the firmware image has what looks like a fairly full loopback root filesystem, might be fun to hack around on a bit.) -Eric From owner-linux-xfs@oss.sgi.com Tue Feb 3 07:40:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 07:40:45 -0800 (PST) Received: from imf22aec.mail.bellsouth.net (imf22aec.mail.bellsouth.net [205.152.59.70]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13FebKO024376 for ; Tue, 3 Feb 2004 07:40:37 -0800 Received: from david.internal.NorcrossGroup.com ([68.213.19.251]) by imf22aec.mail.bellsouth.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040203154026.EOZU1950.imf22aec.mail.bellsouth.net@david.internal.NorcrossGroup.com>; Tue, 3 Feb 2004 10:40:26 -0500 Subject: RE: Snapshots with external logs From: Greg Freemyer Reply-To: freemyer-ml@NorcrossGroup.com To: Mike Young Cc: linux-xfs@oss.sgi.com In-Reply-To: <200402030026.QAA17886@amber.he.net> References: <200402030026.QAA17886@amber.he.net> Content-Type: text/plain Message-Id: <1075822785.16997.6.camel@david.internal.NorcrossGroup.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Rubber Turnip www.usr-local-bin.org Date: Tue, 03 Feb 2004 10:39:45 -0500 Content-Transfer-Encoding: 7bit X-archive-position: 1986 X-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-ml@NorcrossGroup.com Precedence: bulk X-list: linux-xfs On Mon, 2004-02-02 at 19:26, Mike Young wrote: > Hi Greg, > > Thanks for the quick response. > > I'm using LVM for the snapshot and rollback. Sistina must hide that rollback feature in their docs. I just finished reading their howto and feature list. No mention of snapshot rollback. Is it LVM 1, or LVM 2? What lvm command do you use to invoke the rollback? Greg -- Greg Freemyer From owner-linux-xfs@oss.sgi.com Tue Feb 3 08:21:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 08:21:45 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13GLbKO029287 for ; Tue, 3 Feb 2004 08:21:37 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i13GLWOI021109 for ; Tue, 3 Feb 2004 10:21:32 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i13GLUxF33473485; Tue, 3 Feb 2004 10:21:30 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ao3Io-0002mE-00; Tue, 03 Feb 2004 10:21:30 -0600 Subject: TAKE 908809 - Remove PBF_MAPPABLE Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Tue, 03 Feb 2004 10:21:30 -0600 X-archive-position: 1987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Feb 3 08:21:12 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166087a fs/xfs/linux-2.6/xfs_buf.h - 1.86 - Remove PBF_MAPPABLE - it was always set for ages. fs/xfs/linux-2.6/xfs_buf.c - 1.143 - Remove PBF_MAPPABLE - it was always set for ages. fs/xfs/linux-2.4/xfs_buf.h - 1.91 - Remove PBF_MAPPABLE - it was always set for ages. fs/xfs/linux-2.4/xfs_buf.c - 1.162 - Remove PBF_MAPPABLE - it was always set for ages. From owner-linux-xfs@oss.sgi.com Tue Feb 3 09:36:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 09:36:39 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13HaQKO003272 for ; Tue, 3 Feb 2004 09:36:26 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i13HVrhb004189 for ; Tue, 3 Feb 2004 09:31:53 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i13HUxYO33489472; Tue, 3 Feb 2004 11:31:00 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i13HUx0m1692705; Tue, 3 Feb 2004 11:30:59 -0600 (CST) Subject: Re: XFS restoration utility From: Eric Sandeen To: Patrick Ouellet Cc: Ethan Benson , linux-xfs@oss.sgi.com In-Reply-To: <401F9E03.2070105@microtecsecurite.com> References: <401E8B88.2040405@microtecsecurite.com> <20040203090416.GU5676@plato.local.lan> <401F9E03.2070105@microtecsecurite.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1075829459.17582.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 03 Feb 2004 11:30:59 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 1988 X-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 see a link at http://www.linksys.com/support/gpl.asp, do you have another URL? On Tue, 2004-02-03 at 07:11, Patrick Ouellet wrote: > Yes they are, you can go to they're support web site > you'll find a section Download GPL Code. -- Eric Sandeen [C]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 Feb 3 13:14:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 13:14:27 -0800 (PST) Received: from rj.sgi.com (mtvcafw.sgi.com [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13LEOKO014011 for ; Tue, 3 Feb 2004 13:14:24 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i13LFB1d019206 for ; Tue, 3 Feb 2004 13:15:11 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i13LEDYO33537608; Tue, 3 Feb 2004 15:14:14 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ao7s5-0004V7-00; Tue, 03 Feb 2004 15:14:13 -0600 Subject: TAKE 908145 - plug a pagebuf leak Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Tue, 03 Feb 2004 15:14:13 -0600 X-archive-position: 1989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Feb 3 13:13:55 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:166109a fs/xfs/linux-2.6/xfs_buf.c - 1.144 - need to decrement the reference count in pagebuf_free or the race detection will get a false positive fs/xfs/linux-2.4/xfs_buf.c - 1.163 - need to decrement the reference count in pagebuf_free or the race detection will get a false positive From owner-linux-xfs@oss.sgi.com Tue Feb 3 14:10:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 14:11:22 -0800 (PST) Received: from mailhub-4.iastate.edu (mailhub-4.iastate.edu [129.186.140.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i13MA3KO024787 for ; Tue, 3 Feb 2004 14:10:03 -0800 Received: from mailout-2.iastate.edu (mailout-2.iastate.edu [129.186.140.2]) by mailhub-4.iastate.edu (8.12.10/8.12.10) with SMTP id i13M9sj3027393; Tue, 3 Feb 2004 16:09:54 -0600 Received: from pircsds0.agron.iastate.edu(129.186.26.63) by mailout-2.iastate.edu via csmap id aeafe4ce_5695_11d8_8216_00304811d932_2882; Tue, 03 Feb 2004 16:09:48 -0600 (CST) Date: Tue, 3 Feb 2004 16:10:12 -0600 (CST) From: Daryl Herzmann X-X-Sender: akrherz@pircsds0.agron.iastate.edu To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akrherz@iastate.edu Precedence: bulk X-list: linux-xfs Eric, On Tue, 3 Feb 2004, Eric Sandeen wrote: >Not on the web site, I also do not see the gpl "offer" anywhere >in the firmware package. > >They do have a "gpl code center" with downloads for many >of their linux-based products (and there are a lot!) but >this product is not there. > >I reminded them nicely, in a non-sgi capacity, to include >this code as well, let's give it a little time before we bring >the full wrath of slashdot down upon their heads. ;-) Linksys and the GPL have been mentioned a few times on slashdot already. Here is one of the stories... http://developers.slashdot.org/developers/03/07/31/1350217.shtml?tid=106 Daryl -- /** * Daryl Herzmann (akrherz@iastate.edu) * Program Assistant -- Iowa Environmental Mesonet * http://mesonet.agron.iastate.edu */ From owner-linux-xfs@oss.sgi.com Tue Feb 3 16:03:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 16:03:41 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1403OKO030188 for ; Tue, 3 Feb 2004 16:03:27 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AoAVg-00039f-2k; Wed, 04 Feb 2004 00:03:16 +0000 Date: Wed, 4 Feb 2004 00:03:15 +0000 From: Christoph Hellwig To: Miquel van Smoorenburg Cc: Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040204000315.A12127@infradead.org> Mail-Followup-To: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040129232033.GA10541@cistron.nl>; from miquels@cistron.nl on Fri, Jan 30, 2004 at 12:20:33AM +0100 X-archive-position: 1991 X-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 Okay, what about this little patch?: Index: fs/xfs/linux-2.6/xfs_iops.c =================================================================== RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c,v retrieving revision 1.212 diff -u -p -r1.212 xfs_iops.c --- fs/xfs/linux-2.6/xfs_iops.c 12 Dec 2003 04:17:52 -0000 1.212 +++ fs/xfs/linux-2.6/xfs_iops.c 3 Feb 2004 23:56:17 -0000 @@ -80,11 +80,15 @@ validate_fields( vattr_t va; int error; - va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS; + va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS|XFS_AT_SIZE; VOP_GETATTR(vp, &va, ATTR_LAZY, NULL, error); ip->i_nlink = va.va_nlink; ip->i_size = va.va_size; ip->i_blocks = va.va_nblocks; + + /* we're under i_sem so i_size can't change under us */ + if (i_size_read(ip) != va.va_size) + i_size_write(ip, va.va_size); } /* @@ -186,8 +190,7 @@ linvfs_mknod( if (S_ISCHR(mode) || S_ISBLK(mode)) ip->i_rdev = rdev; - else if (S_ISDIR(mode)) - validate_fields(ip); + validate_fields(ip); d_instantiate(dentry, ip); validate_fields(dir); } @@ -536,6 +539,7 @@ linvfs_setattr( if (error) return(-error); /* Positive error up from XFS */ if (ia_valid & ATTR_SIZE) { + i_size_write(inode, vattr.va_size); error = vmtruncate(inode, attr->ia_size); } Index: fs/xfs/linux-2.6/xfs_vnode.c =================================================================== RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c,v retrieving revision 1.120 diff -u -p -r1.120 xfs_vnode.c --- fs/xfs/linux-2.6/xfs_vnode.c 20 Oct 2003 02:08:58 -0000 1.120 +++ fs/xfs/linux-2.6/xfs_vnode.c 3 Feb 2004 23:56:17 -0000 @@ -213,7 +213,6 @@ vn_revalidate( inode->i_mtime = va.va_mtime; inode->i_ctime = va.va_ctime; inode->i_atime = va.va_atime; - i_size_write(inode, va.va_size); if (va.va_xflags & XFS_XFLAG_IMMUTABLE) inode->i_flags |= S_IMMUTABLE; else From owner-linux-xfs@oss.sgi.com Tue Feb 3 16:06:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 16:06:30 -0800 (PST) Received: from khan.acc.umu.se (postfix@khan.acc.umu.se [130.239.18.139]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1406QKO030557 for ; Tue, 3 Feb 2004 16:06:27 -0800 Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id DE9D5D270; Wed, 4 Feb 2004 01:06:24 +0100 (MET) Received: by khan.acc.umu.se (Postfix, from userid 23136) id B11DED2F4; Wed, 4 Feb 2004 01:06:23 +0100 (MET) Date: Wed, 4 Feb 2004 01:06:23 +0100 From: David Weinehall To: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040204000623.GI15492@khan.acc.umu.se> Mail-Followup-To: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040204000315.A12127@infradead.org> User-Agent: Mutt/1.4.1i X-Accept-Language: Swedish, English X-GPG-Fingerprint: 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16 X-GPG-Key: http://www.acc.umu.se/~tao/files/pubkey_dc47ca16.gpg.asc X-Virus-Scanned: by amavisd-new at acc.umu.se X-archive-position: 1992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tao@acc.umu.se Precedence: bulk X-list: linux-xfs On Wed, Feb 04, 2004 at 12:03:15AM +0000, Christoph Hellwig wrote: > Okay, what about this little patch?: > > > Index: fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c,v > retrieving revision 1.212 > diff -u -p -r1.212 xfs_iops.c > --- fs/xfs/linux-2.6/xfs_iops.c 12 Dec 2003 04:17:52 -0000 1.212 > +++ fs/xfs/linux-2.6/xfs_iops.c 3 Feb 2004 23:56:17 -0000 > @@ -80,11 +80,15 @@ validate_fields( > vattr_t va; > int error; > > - va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS; > + va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS|XFS_AT_SIZE; Huh? XFS_AT_SIZE twice?! [snip] Regards: David Weinehall -- /) David Weinehall /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/ (/ Full colour fire (/ From owner-linux-xfs@oss.sgi.com Tue Feb 3 16:07:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 16:07:41 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1407dKO031048 for ; Tue, 3 Feb 2004 16:07:40 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AoAZr-0003BL-3E; Wed, 04 Feb 2004 00:07:35 +0000 Date: Wed, 4 Feb 2004 00:07:35 +0000 From: Christoph Hellwig To: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040204000735.A12232@infradead.org> Mail-Followup-To: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> <20040204000623.GI15492@khan.acc.umu.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040204000623.GI15492@khan.acc.umu.se>; from tao@acc.umu.se on Wed, Feb 04, 2004 at 01:06:23AM +0100 X-archive-position: 1993 X-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, Feb 04, 2004 at 01:06:23AM +0100, David Weinehall wrote: > > - va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS; > > + va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS|XFS_AT_SIZE; > > Huh? XFS_AT_SIZE twice?! Ah thanks. Stupid braino but fortunately harmless.. From owner-linux-xfs@oss.sgi.com Tue Feb 3 16:18:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 16:19:14 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i140IuKO031707 for ; Tue, 3 Feb 2004 16:18:57 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id i140ItrN015893 for ; Tue, 3 Feb 2004 19:18:55 -0500 (EST) Date: Tue, 3 Feb 2004 19:18:55 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: patch version Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 1994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, Just a short question: If I go to ftp://oss.sgi.com/projects/xfs/patches/ to download a patch (2.4.22), then - is this xfs version 1.3.1? - or you'd rather call it something higher than 1.3.1, a snapshot as of 2003-10-10_04:57_UTC? I would need this info so in case I find anomalies, I can properly report what exactly I am using... Cheers Gaspar From owner-linux-xfs@oss.sgi.com Tue Feb 3 16:57:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 16:57:29 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i140vRKO003698 for ; Tue, 3 Feb 2004 16:57:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i140vKeu023675 for ; Tue, 3 Feb 2004 18:57:21 -0600 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 LAA18747 for ; Wed, 4 Feb 2004 11:57:19 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 0860CC00AA; Wed, 4 Feb 2004 11:57:16 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 05991140115; Wed, 4 Feb 2004 11:57:16 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: gbakos@cfa.harvard.edu Cc: linux-xfs@oss.sgi.com Subject: Re: patch version In-reply-to: Your message of "Tue, 03 Feb 2004 19:18:55 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Feb 2004 11:57:14 +1100 Message-ID: <2825.1075856234@kao2.melbourne.sgi.com> X-archive-position: 1995 X-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 Tue, 3 Feb 2004 19:18:55 -0500 (EST), Gaspar Bakos wrote: >If I go to >ftp://oss.sgi.com/projects/xfs/patches/ >to download a patch (2.4.22), then >- is this xfs version 1.3.1? >- or you'd rather call it something higher than 1.3.1, a snapshot as > of 2003-10-10_04:57_UTC? It is a snapshot of the XFS development tree as of 2.4.22-2003-11-10_23:49_UTC, no more, no less, and should be reported as exactly that. See the README in the same directory. From owner-linux-xfs@oss.sgi.com Tue Feb 3 23:28:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Feb 2004 23:28:29 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i147SFKO021174 for ; Tue, 3 Feb 2004 23:28:16 -0800 Received: from port-212-202-171-108.reverse.qdsl-home.de ([212.202.171.108] helo=hro.bluespice.org) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1AoHSD-0005j8-00 for linux-xfs@oss.sgi.com; Wed, 04 Feb 2004 08:28:09 +0100 Received: from ij by hro.bluespice.org with local (Exim 4.30) id 1AoHSK-0006q5-Lv for linux-xfs@oss.sgi.com; Wed, 04 Feb 2004 08:28:16 +0100 Date: Wed, 4 Feb 2004 08:28:16 +0100 From: Ingo Juergensmann To: linux-xfs@oss.sgi.com Subject: XFS problem with 2.6.2-rc2 Message-ID: <20040204072816.GA24743@2004.bluespice.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 1996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ij@2004.bluespice.org Precedence: bulk X-list: linux-xfs Hi! I'm getting (more or less) random errors on my XFS partitions with kernel 2.6.2-rc*, currently rc2. It happened today during the daily cron runs of updatedb f.e., but happened as well during "normal" activity when using the machine. When I run xfs_repair several times, the errors are mostly fixed, although many files usually get moved to lost+found. Anyway, you can find the excerpt from syslog and the System.map here: http://bluespice.dyndns.org/xfsproblem.txt (~5700 lines) http://bluespice.dyndns.org/System.map-2.6.2-rc2 -- Ciao... // Ingo \X/ From owner-linux-xfs@oss.sgi.com Wed Feb 4 00:41:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 00:42:10 -0800 (PST) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i148fkKO026508 for ; Wed, 4 Feb 2004 00:41:46 -0800 Received: from erbenson.alaska.net (26-pm21.nwc.alaska.net [209.112.143.26]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id i148fhjE024581 for ; Tue, 3 Feb 2004 23:41:44 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 693E339E7 for ; Tue, 3 Feb 2004 23:41:42 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 72E4040FF35; Tue, 3 Feb 2004 23:41:42 -0900 (AKST) Date: Tue, 3 Feb 2004 23:41:42 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS restoration utility Message-ID: <20040204084142.GB4347@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040203090416.GU5676@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fba/0zbH8Xs+Fj9o" Content-Disposition: inline In-Reply-To: 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-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.61; spamdefang 1.93 X-archive-position: 1997 X-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 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 03, 2004 at 09:05:07AM -0600, Eric Sandeen wrote: > On Tue, 3 Feb 2004, Ethan Benson wrote: >=20 > > On Mon, Feb 02, 2004 at 02:14:13PM -0600, Eric Sandeen wrote: > > > It appears that it is in fact xfs, from looking at the > > > 'firmware' image.... > >=20 > > are they making full source code available as required by the GPL? >=20 > Not on the web site, I also do not see the gpl "offer" anywhere > in the firmware package. that in and of itself is a GPL violation. all binaries are required to be shipped with a complete, unabridged copy of the GPL. > They do have a "gpl code center" with downloads for many > of their linux-based products (and there are a lot!) but > this product is not there.=20=20 >=20 > I reminded them nicely, in a non-sgi capacity, to include > this code as well, let's give it a little time before we bring > the full wrath of slashdot down upon their heads. ;-) of course, quiet diplomacy has proved effective in most cases. however if they don't comply i would imagine SGI would be interested, since as i understand it one of their main reasons for using the GPL instead of say the BSD licence is to prevent exactly this sort of `take, make money, not give anything back' type of behavior. > (p.s. the firmware image has what looks like a fairly full loopback > root filesystem, might be fun to hack around on a bit.) yes its definitly nice to see this type of hardware using normal operating systems in normal enough manner, makes modification much easier, esp with source code. GPL is a wonderful thing, but it does take diligence to keep it that way. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkAgsEYACgkQJKx7GixEevyNgwCfYiUH0BkoKV4yQUP9wYHwVSMG kiQAn2ktSZEFRIMqTwqj4ZW6HDgihrIr =Uc7P -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-linux-xfs@oss.sgi.com Wed Feb 4 03:24:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 03:24:26 -0800 (PST) Received: from mailbox.gfdl.noaa.gov (mailbox.GFDL.NOAA.GOV [140.208.1.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14BOHKO006085 for ; Wed, 4 Feb 2004 03:24:18 -0800 Received: from majordomo2.gfdl.noaa.gov (majordomo2.GFDL.NOAA.GOV [140.208.1.206]) by mailbox.gfdl.noaa.gov (Netscape Messaging Server 4.15) with ESMTP id HSK5CS00.K0E for ; Wed, 4 Feb 2004 06:31:40 -0500 Received: from pimdev.gfdl.noaa.gov (root@pimdev [140.208.1.39]) by majordomo2.gfdl.noaa.gov (8.12.10/8.12.10) with ESMTP id i14BNupj020480 for ; Wed, 4 Feb 2004 06:23:56 -0500 Received: from pimdev.gfdl.noaa.gov (smmsp@localhost [127.0.0.1]) by pimdev.gfdl.noaa.gov (8.12.9/8.11.4) with ESMTP id i14BNspR020802; Wed, 4 Feb 2004 06:23:54 -0500 Received: (from root@localhost) by pimdev.gfdl.noaa.gov (8.12.9/8.12.4/Submit) id i14BNsQH020801; Wed, 4 Feb 2004 06:23:54 -0500 Date: Wed, 4 Feb 2004 06:23:54 -0500 Message-Id: <4229-Wed04Feb2004062354-0500-Philip.Macias@NOAA.gov> X-Mailer: emacs 21.2.1 (via feedmail 8 I) To: linux-xfs@oss.sgi.com Subject: xfsrestore fails to exit properly under 2.6.1 From: Phil Macias Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-archive-position: 1998 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Philip.Macias@NOAA.gov Precedence: bulk X-list: linux-xfs Hello, We have been using XFS on RedHat linux for over two years (since I have been here). I have been using a script to clone workstations from one-another for over a year whereby the host-to-be-cloned exports it's XFS partitions over NFS and they are mounted by the donor host and contents copied with: xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var This process worked reliably for over a year on the 2.4.x kernels and these versions of xfs tools: acl-2.1.1-gfdl-1-1 attr-2.1.1-gfdl-1-1 dmapi-2.0.5-gfdl-1-1 kernel-2.4.18-XFS-NFS-base-gfdl-2-1 xfsdump-2.2.4-gfdl-1-1 xfsprogs-2.3.6-gfdl-1-1 PROBLEM: I am testing the 2.6.1 kernel and the following relevant packages: libelf-0.8.2-2-gfdl-1-1 elfutils-libelf-0.89-2-gfdl-1-1 popt-1.8.1-0.31-gfdl-1-1 gcc-3.3-gfdl-1-1 kernel-2.6.0-complete-gfdl-1-1 glibc-2.3.2-gfdl-1-1 beecrypt-3.0.1-gfdl-1-1 acl-2.2.21-gfdl.tgz attr-2.4.12-gfdl.tgz binutils-2.14-gfdl.tgz dmapi-2.1.0-gfdl.tgz xfsprogs-2.6.0-gfdl.tgz Everything on the system works well except the remote xfsdump/xfsrestore. Running: xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var on the 2.6.1 system does dump/restore properly, but xfsrestore never exits. I have to issue these commands to release xfsrestore: kill % fuser -k /clone-var/ ...where /clone-var/ is the target partition. Please note that the target host is still running the old (2.4.x) kernel. Here are the last lines to the "-v5" output: ... xfsrestore: read file hdr off 0 flags 0x0 ino 14680333 mode 0x0000a1ff xfsrestore: preemptchk( ) xfsrestore: restoring lib/scrollkeeper/pt_BR (14680333 0) xfsrestore: restoring symbolic link ino 14680333 lib/scrollkeeper/pt_BR xfsrestore: drive_simple read( want 32 ) xfsrestore: drive_simple return_read_buf( returning 32 ) xfsrestore: xlate_extenthdr xfsrestore: read extent hdr size 32 offset 0 type 4 flags 00000000 xfsrestore: drive_simple read( want 32 ) xfsrestore: drive_simple return_read_buf( returning 32 ) xfsrestore: drive_simple get_mark( ) xfsrestore: drive_simple read( want 256 ) xfsrestore: drive_simple return_read_buf( returning 256 ) xfsrestore: xlate_bstat xfsrestore: xlate_bstat: pre-xlate bs_ino 0 bs_mode 0 xfsrestore: xlate_bstat: post-xlate bs_ino 0 bs_mode 0 xfsrestore: xlate_filehdr: pre-xlate fh_offset 0 fh_flags 83886080 fh_checksum 13835040720794157312 xfsrestore: xlate_filehdr: post-xlate fh_offset 0 fh_flags 5 fh_checksum 13835040720794157312 xfsrestore: read file hdr off 0 flags 0x5 ino 0 mode 0x00000000 xfsrestore: preemptchk( ) xfsrestore: Media_end: pos==3 xfsrestore: drive_simple end_read( ) xfsrestore: getting next media file for non-dir restore xfsrestore: Media_mfile_next: purp==2 pos==0 xfsrestore: tree finalize xfsrestore: restore complete: 139 seconds elapsed ------------------------------------------------- Syslog shows no erors or any info about xfsrestore. Any idea why xfsrestore fails to exit properly? Thanx, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Phil Macias" , RSIS, Inc. * NOAA/GFDL * Princeton, NJ ___,___ |_|_, 609 987 5059 office | 609 203 5874 cell >__, From owner-linux-xfs@oss.sgi.com Wed Feb 4 07:07:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 07:07:39 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14F7NKO002283 for ; Wed, 4 Feb 2004 07:07:23 -0800 Received: (qmail 7478 invoked from network); 4 Feb 2004 14:13:55 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 4 Feb 2004 14:13:55 -0000 Message-ID: <401FAC70.8070104@xfs.org> Date: Tue, 03 Feb 2004 08:13:04 -0600 From: Steve Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> In-Reply-To: <20040204000315.A12127@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 1999 X-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@xfs.org Precedence: bulk X-list: linux-xfs Christoph Hellwig wrote: > Okay, what about this little patch?: > > > Index: fs/xfs/linux-2.6/xfs_iops.c > =================================================================== > RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c,v > retrieving revision 1.212 > diff -u -p -r1.212 xfs_iops.c > --- fs/xfs/linux-2.6/xfs_iops.c 12 Dec 2003 04:17:52 -0000 1.212 > +++ fs/xfs/linux-2.6/xfs_iops.c 3 Feb 2004 23:56:17 -0000 > @@ -80,11 +80,15 @@ validate_fields( > vattr_t va; > int error; > > - va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS; > + va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS|XFS_AT_SIZE; > VOP_GETATTR(vp, &va, ATTR_LAZY, NULL, error); > ip->i_nlink = va.va_nlink; > ip->i_size = va.va_size; > ip->i_blocks = va.va_nblocks; > + > + /* we're under i_sem so i_size can't change under us */ > + if (i_size_read(ip) != va.va_size) > + i_size_write(ip, va.va_size); > } > > /* > @@ -186,8 +190,7 @@ linvfs_mknod( > > if (S_ISCHR(mode) || S_ISBLK(mode)) > ip->i_rdev = rdev; > - else if (S_ISDIR(mode)) > - validate_fields(ip); > + validate_fields(ip); There was some reason this was only necessary on directories, but I cannot remember why just now. > d_instantiate(dentry, ip); > validate_fields(dir); > } > @@ -536,6 +539,7 @@ linvfs_setattr( > if (error) > return(-error); /* Positive error up from XFS */ > if (ia_valid & ATTR_SIZE) { > + i_size_write(inode, vattr.va_size); > error = vmtruncate(inode, attr->ia_size); > } > > Index: fs/xfs/linux-2.6/xfs_vnode.c > =================================================================== > RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c,v > retrieving revision 1.120 > diff -u -p -r1.120 xfs_vnode.c > --- fs/xfs/linux-2.6/xfs_vnode.c 20 Oct 2003 02:08:58 -0000 1.120 > +++ fs/xfs/linux-2.6/xfs_vnode.c 3 Feb 2004 23:56:17 -0000 > @@ -213,7 +213,6 @@ vn_revalidate( > inode->i_mtime = va.va_mtime; > inode->i_ctime = va.va_ctime; > inode->i_atime = va.va_atime; > - i_size_write(inode, va.va_size); > if (va.va_xflags & XFS_XFLAG_IMMUTABLE) > inode->i_flags |= S_IMMUTABLE; > else > I think this should work, it just leaves the extending O_DIRECT write case. Keeping the revalidate call out of the path for creating regular files would be nice though, why did you deem that necessary? Steve From owner-linux-xfs@oss.sgi.com Wed Feb 4 07:17:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 07:17:14 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14FGxKO003801 for ; Wed, 4 Feb 2004 07:17:00 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AoOlj-0004zH-JC; Wed, 04 Feb 2004 15:16:47 +0000 Date: Wed, 4 Feb 2004 15:16:47 +0000 From: Christoph Hellwig To: Steve Lord Cc: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040204151647.A19158@infradead.org> Mail-Followup-To: Christoph Hellwig , Steve Lord , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> <401FAC70.8070104@xfs.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: <401FAC70.8070104@xfs.org>; from lord@xfs.org on Tue, Feb 03, 2004 at 08:13:04AM -0600 X-archive-position: 2000 X-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, Feb 03, 2004 at 08:13:04AM -0600, Steve Lord wrote: > > ip->i_rdev = rdev; > > - else if (S_ISDIR(mode)) > > - validate_fields(ip); > > + validate_fields(ip); > > There was some reason this was only necessary on directories, but I > cannot remember why just now. Well, it is nessecary now to update i_size. Or rather it was, I think I can get rid of it again after taking care of initialize_vnode. > I think this should work, it just leaves the extending O_DIRECT write > case. And initialize_vnode. I have a working patch for the latter, but I still need to take a look at O_DIRECT. > Keeping the revalidate call out of the path for creating regular > files would be nice though, why did you deem that necessary? I thought I need it for i_size udates, but we should be able to take care of it in initialize_vnode. From owner-linux-xfs@oss.sgi.com Wed Feb 4 09:11:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 09:12:10 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@universe.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14HBsKO011796 for ; Wed, 4 Feb 2004 09:11:55 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.10/8.12.10) with ESMTP id i14HBstW003562 for ; Wed, 4 Feb 2004 10:11:54 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.10/8.12.10/Submit) with ESMTP id i14HBsLj003559 for ; Wed, 4 Feb 2004 10:11:54 -0700 Date: Wed, 4 Feb 2004 10:11:54 -0700 (MST) From: James Rich To: XFS mailing list Subject: ghost files Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2001 X-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@universe.chowhouse.com Precedence: bulk X-list: linux-xfs Hi folks, I have a strange thing happening. My rsync mirror of slackware.com has "ghost files" in it, i.e. files that don't exist yet most file operations still find them. Here is an example using 'ls': root@universe:/home/ftp/pub/slackware-current/slackware/xap# ls /bin/ls: mozilla-1.4.1-i486-1.tgz: No such file or directory /bin/ls: mozilla-1.4.1-i486-1.tgz.asc: No such file or directory /bin/ls: mozilla-1.4.1-i486-1.txt: No such file or directory /bin/ls: gimp-1.3.23-i486-1.txt: No such file or directory /bin/ls: mozilla-plugins-1.4.1-noarch-1.tgz: No such file or directory /bin/ls: mozilla-plugins-1.4.1-noarch-1.tgz.asc: No such file or directory /bin/ls: mozilla-plugins-1.4.1-noarch-1.txt: No such file or directory Notice 'ls' "sees" these files, but they don't actually exist. I don't know how to delete what doesn't exist, but I would like to get ls to quit reporting these files (ls isn't the only command, chown does the same thing). What should I do? James Rich From owner-linux-xfs@oss.sgi.com Wed Feb 4 09:42:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 09:42:07 -0800 (PST) Received: from lips.borg.umn.edu (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14Hg3KO013118 for ; Wed, 4 Feb 2004 09:42:04 -0800 Received: from [24.118.170.148] (c-24-118-170-148.mn.client2.attbi.com [24.118.170.148]) by lips.borg.umn.edu (8.12.11/8.12.11) with ESMTP id i14HfuPA099904; Wed, 4 Feb 2004 11:42:00 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: xfsrestore fails to exit properly under 2.6.1 From: Russell Cattelan To: Phil Macias Cc: linux-xfs@oss.sgi.com In-Reply-To: <4229-Wed04Feb2004062354-0500-Philip.Macias@NOAA.gov> References: <4229-Wed04Feb2004062354-0500-Philip.Macias@NOAA.gov> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-P/55uI4EMIJNOPBs/njs" Message-Id: <1075916534.96681.5.camel@lupo.thebarn.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 04 Feb 2004 11:42:14 -0600 X-archive-position: 2002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs --=-P/55uI4EMIJNOPBs/njs Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Are you able to attach gdb to the hung process and get a backtrace? On Wed, 2004-02-04 at 05:23, Phil Macias wrote: > Hello, >=20 > We have been using XFS on RedHat linux for over two years (since I > have been here). I have been using a script to clone workstations from > one-another for over a year whereby the host-to-be-cloned exports it's > XFS partitions over NFS and they are mounted by the donor host and > contents copied with: >=20 > xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var >=20 > This process worked reliably for over a year on the 2.4.x kernels and > these versions of xfs tools: >=20 > acl-2.1.1-gfdl-1-1 > attr-2.1.1-gfdl-1-1 > dmapi-2.0.5-gfdl-1-1 > kernel-2.4.18-XFS-NFS-base-gfdl-2-1 > xfsdump-2.2.4-gfdl-1-1 > xfsprogs-2.3.6-gfdl-1-1 >=20 > PROBLEM: I am testing the 2.6.1 kernel and the following relevant > packages:=20 >=20 > libelf-0.8.2-2-gfdl-1-1 > elfutils-libelf-0.89-2-gfdl-1-1 > popt-1.8.1-0.31-gfdl-1-1 > gcc-3.3-gfdl-1-1 > kernel-2.6.0-complete-gfdl-1-1 > glibc-2.3.2-gfdl-1-1 > beecrypt-3.0.1-gfdl-1-1 >=20=20=20 > acl-2.2.21-gfdl.tgz > attr-2.4.12-gfdl.tgz > binutils-2.14-gfdl.tgz > dmapi-2.1.0-gfdl.tgz > xfsprogs-2.6.0-gfdl.tgz >=20=20=20=20=20=20=20=20=20=20=20=20 > Everything on the system works well except the remote > xfsdump/xfsrestore. Running: >=20 > xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var >=20 > on the 2.6.1 system does dump/restore properly, but xfsrestore never > exits. I have to issue these commands to release xfsrestore: >=20 > kill % > fuser -k /clone-var/ >=20 > ...where /clone-var/ is the target partition. Please note that > the target host is still running the old (2.4.x) kernel. >=20 > Here are the last lines to the "-v5" output: >=20 > ... > xfsrestore: read file hdr off 0 flags 0x0 ino 14680333 mode 0x0000a1ff > xfsrestore: preemptchk( ) > xfsrestore: restoring lib/scrollkeeper/pt_BR (14680333 0) > xfsrestore: restoring symbolic link ino 14680333 lib/scrollkeeper/pt_BR > xfsrestore: drive_simple read( want 32 ) > xfsrestore: drive_simple return_read_buf( returning 32 ) > xfsrestore: xlate_extenthdr > xfsrestore: read extent hdr size 32 offset 0 type 4 flags 00000000 > xfsrestore: drive_simple read( want 32 ) > xfsrestore: drive_simple return_read_buf( returning 32 ) > xfsrestore: drive_simple get_mark( ) > xfsrestore: drive_simple read( want 256 ) > xfsrestore: drive_simple return_read_buf( returning 256 ) > xfsrestore: xlate_bstat > xfsrestore: xlate_bstat: pre-xlate > bs_ino 0 > bs_mode 0 > xfsrestore: xlate_bstat: post-xlate > bs_ino 0 > bs_mode 0 > xfsrestore: xlate_filehdr: pre-xlate > fh_offset 0 > fh_flags 83886080 > fh_checksum 13835040720794157312 > xfsrestore: xlate_filehdr: post-xlate > fh_offset 0 > fh_flags 5 > fh_checksum 13835040720794157312 > xfsrestore: read file hdr off 0 flags 0x5 ino 0 mode 0x00000000 > xfsrestore: preemptchk( ) > xfsrestore: Media_end: pos=3D=3D3 > xfsrestore: drive_simple end_read( ) > xfsrestore: getting next media file for non-dir restore > xfsrestore: Media_mfile_next: purp=3D=3D2 pos=3D=3D0 > xfsrestore: tree finalize > xfsrestore: restore complete: 139 seconds elapsed > ------------------------------------------------- >=20 > Syslog shows no erors or any info about xfsrestore. >=20 > Any idea why xfsrestore fails to exit properly? >=20 > Thanx, >=20 >=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Phil Macias" ,=20 >=20 > RSIS, Inc. * NOAA/GFDL * Princeton, NJ >=20 > ___,___ > |_|_, 609 987 5059 office=20=20=20=20=20=20=20=20=20 > | 609 203 5874 cell=20=20=20=20=20=20=20=20=20=20=20 > >__, >=20 >=20 >=20 --=20 Russell Cattelan --=-P/55uI4EMIJNOPBs/njs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBAIS72NRmM+OaGhBgRApgsAJ91dL40QRuf489yvuWP0edD5CW3mgCePnHE jJKK3969prkDV3Ty8A15YcE= =PMku -----END PGP SIGNATURE----- --=-P/55uI4EMIJNOPBs/njs-- From owner-linux-xfs@oss.sgi.com Wed Feb 4 10:03:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 10:03:28 -0800 (PST) Received: from mailbox.gfdl.noaa.gov (mailbox.GFDL.NOAA.GOV [140.208.1.202]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14I3CKO013888 for ; Wed, 4 Feb 2004 10:03:12 -0800 Received: from majordomo2.gfdl.noaa.gov (majordomo2.GFDL.NOAA.GOV [140.208.1.206]) by mailbox.gfdl.noaa.gov (Netscape Messaging Server 4.15) with ESMTP id HSKNTP00.L2A; Wed, 4 Feb 2004 13:10:37 -0500 Received: from pimdev.gfdl.noaa.gov (root@pimdev [140.208.1.39]) by majordomo2.gfdl.noaa.gov (8.12.10/8.12.10) with ESMTP id i14I2ob5030521; Wed, 4 Feb 2004 13:02:50 -0500 Received: from pimdev.gfdl.noaa.gov (smmsp@localhost [127.0.0.1]) by pimdev.gfdl.noaa.gov (8.12.9/8.11.4) with ESMTP id i14I2mpR024785; Wed, 4 Feb 2004 13:02:48 -0500 Received: (from root@localhost) by pimdev.gfdl.noaa.gov (8.12.9/8.12.4/Submit) id i14I2mE1024784; Wed, 4 Feb 2004 13:02:48 -0500 Date: Wed, 4 Feb 2004 13:02:48 -0500 Message-Id: <3174-Wed04Feb2004130248-0500-Philip.Macias@NOAA.gov> X-Mailer: emacs 21.2.1 (via feedmail 8 I) To: cattelan@xfs.org CC: Philip.Macias@noaa.gov, linux-xfs@oss.sgi.com In-reply-to: <1075916534.96681.5.camel@lupo.thebarn.com> (cattelan@xfs.org) Subject: Re: xfsrestore fails to exit properly under 2.6.1 From: Phil Macias References: <4229-Wed04Feb2004062354-0500-Philip.Macias@NOAA.gov> <1075916534.96681.5.camel@lupo.thebarn.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII X-archive-position: 2003 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Philip.Macias@noaa.gov Precedence: bulk X-list: linux-xfs Here you go: root: ~# gdb --pid=7896 GNU gdb Red Hat Linux (5.2-2) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux". Attaching to process 7896 Reading symbols from /usr/sbin/xfsrestore...done. Reading symbols from /usr/lib/libhandle.so.1...done. Loaded symbols for /usr/lib/libhandle.so.1 Reading symbols from /usr/lib/libattr.so.1...done. Loaded symbols for /usr/lib/libattr.so.1 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libgcc_s.so.1...done. Loaded symbols for /usr/lib/libgcc_s.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 0x4010c566 in open64 () from /lib/libc.so.6 (gdb) backtrace #0 0x4010c566 in open64 () from /lib/libc.so.6 #1 0x400e4dd9 in opendir () from /lib/libc.so.6 #2 0x08073a0b in wipepersstate () at content.c:3600 #3 0x08072701 in content_complete () at content.c:2587 #4 0x08062de7 in main (argc=4, argv=0xbffff514) at main.c:636 #5 0x4004ed06 in __libc_start_main () from /lib/libc.so.6 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Phil Macias" , RSIS, Inc. * NOAA/GFDL * Princeton, NJ ___,___ |_|_, 609 987 5059 office | 609 203 5874 cell >__, | From: Russell Cattelan | Cc: linux-xfs@oss.sgi.com | Date: Wed, 04 Feb 2004 11:42:14 -0600 | | Are you able to attach gdb to the hung process and | get a backtrace? | | On Wed, 2004-02-04 at 05:23, Phil Macias wrote: | > Hello, | > | > We have been using XFS on RedHat linux for over two years (since I | > have been here). I have been using a script to clone workstations from | > one-another for over a year whereby the host-to-be-cloned exports it's | > XFS partitions over NFS and they are mounted by the donor host and | > contents copied with: | > | > xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var | > | > This process worked reliably for over a year on the 2.4.x kernels and | > these versions of xfs tools: | > | > acl-2.1.1-gfdl-1-1 | > attr-2.1.1-gfdl-1-1 | > dmapi-2.0.5-gfdl-1-1 | > kernel-2.4.18-XFS-NFS-base-gfdl-2-1 | > xfsdump-2.2.4-gfdl-1-1 | > xfsprogs-2.3.6-gfdl-1-1 | > | > PROBLEM: I am testing the 2.6.1 kernel and the following relevant | > packages: | > | > libelf-0.8.2-2-gfdl-1-1 | > elfutils-libelf-0.89-2-gfdl-1-1 | > popt-1.8.1-0.31-gfdl-1-1 | > gcc-3.3-gfdl-1-1 | > kernel-2.6.0-complete-gfdl-1-1 | > glibc-2.3.2-gfdl-1-1 | > beecrypt-3.0.1-gfdl-1-1 | > | > acl-2.2.21-gfdl.tgz | > attr-2.4.12-gfdl.tgz | > binutils-2.14-gfdl.tgz | > dmapi-2.1.0-gfdl.tgz | > xfsprogs-2.6.0-gfdl.tgz | > | > Everything on the system works well except the remote | > xfsdump/xfsrestore. Running: | > | > xfsdump -v5 -l 0 - /dev/hda7 | xfsrestore -v5 - /clone-var | > | > on the 2.6.1 system does dump/restore properly, but xfsrestore never | > exits. I have to issue these commands to release xfsrestore: | > | > kill % | > fuser -k /clone-var/ | > | > ...where /clone-var/ is the target partition. Please note that | > the target host is still running the old (2.4.x) kernel. | > | > Here are the last lines to the "-v5" output: | > | > ... | > xfsrestore: read file hdr off 0 flags 0x0 ino 14680333 mode 0x0000a1ff | > xfsrestore: preemptchk( ) | > xfsrestore: restoring lib/scrollkeeper/pt_BR (14680333 0) | > xfsrestore: restoring symbolic link ino 14680333 lib/scrollkeeper/pt_BR | > xfsrestore: drive_simple read( want 32 ) | > xfsrestore: drive_simple return_read_buf( returning 32 ) | > xfsrestore: xlate_extenthdr | > xfsrestore: read extent hdr size 32 offset 0 type 4 flags 00000000 | > xfsrestore: drive_simple read( want 32 ) | > xfsrestore: drive_simple return_read_buf( returning 32 ) | > xfsrestore: drive_simple get_mark( ) | > xfsrestore: drive_simple read( want 256 ) | > xfsrestore: drive_simple return_read_buf( returning 256 ) | > xfsrestore: xlate_bstat | > xfsrestore: xlate_bstat: pre-xlate | > bs_ino 0 | > bs_mode 0 | > xfsrestore: xlate_bstat: post-xlate | > bs_ino 0 | > bs_mode 0 | > xfsrestore: xlate_filehdr: pre-xlate | > fh_offset 0 | > fh_flags 83886080 | > fh_checksum 13835040720794157312 | > xfsrestore: xlate_filehdr: post-xlate | > fh_offset 0 | > fh_flags 5 | > fh_checksum 13835040720794157312 | > xfsrestore: read file hdr off 0 flags 0x5 ino 0 mode 0x00000000 | > xfsrestore: preemptchk( ) | > xfsrestore: Media_end: pos=3D=3D3 | > xfsrestore: drive_simple end_read( ) | > xfsrestore: getting next media file for non-dir restore | > xfsrestore: Media_mfile_next: purp=3D=3D2 pos=3D=3D0 | > xfsrestore: tree finalize | > xfsrestore: restore complete: 139 seconds elapsed | > ------------------------------------------------- | > | > Syslog shows no erors or any info about xfsrestore. | > | > Any idea why xfsrestore fails to exit properly? | > | > Thanx, | > | > | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | > "Phil Macias" , | > | > RSIS, Inc. * NOAA/GFDL * Princeton, NJ | > | > ___,___ | > |_|_, 609 987 5059 office | > | 609 203 5874 cell | > >__, | > | > | > | -- | Russell Cattelan | | --=-P/55uI4EMIJNOPBs/njs | Content-Type: application/pgp-signature; name=signature.asc | Content-Description: This is a digitally signed message part | | -----BEGIN PGP SIGNATURE----- | Version: GnuPG v1.2.4 (FreeBSD) | | iD8DBQBAIS72NRmM+OaGhBgRApgsAJ91dL40QRuf489yvuWP0edD5CW3mgCePnHE | jJKK3969prkDV3Ty8A15YcE= | =PMku | -----END PGP SIGNATURE----- | | --=-P/55uI4EMIJNOPBs/njs-- | | From owner-linux-xfs@oss.sgi.com Wed Feb 4 10:17:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 10:17:25 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14IHKKO015828 for ; Wed, 4 Feb 2004 10:17:23 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AoRaH-0005Uh-RP; Wed, 04 Feb 2004 18:17:09 +0000 Date: Wed, 4 Feb 2004 18:17:09 +0000 From: Christoph Hellwig To: Steve Lord Cc: Christoph Hellwig , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040204181709.A21093@infradead.org> Mail-Followup-To: Christoph Hellwig , Steve Lord , Miquel van Smoorenburg , Andrew Morton , Nathan Scott , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> <401FAC70.8070104@xfs.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: <401FAC70.8070104@xfs.org>; from lord@xfs.org on Tue, Feb 03, 2004 at 08:13:04AM -0600 X-archive-position: 2004 X-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 Here's a new diff, that should get rid of all the warnings except for O_DIRECT. I've also addressed the comments from Dave and Steve. Index: fs/xfs/linux-2.6/xfs_iops.c =================================================================== RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c,v retrieving revision 1.212 diff -u -p -r1.212 xfs_iops.c --- fs/xfs/linux-2.6/xfs_iops.c 12 Dec 2003 04:17:52 -0000 1.212 +++ fs/xfs/linux-2.6/xfs_iops.c 4 Feb 2004 17:56:34 -0000 @@ -82,9 +82,14 @@ validate_fields( va.va_mask = XFS_AT_NLINK|XFS_AT_SIZE|XFS_AT_NBLOCKS; VOP_GETATTR(vp, &va, ATTR_LAZY, NULL, error); - ip->i_nlink = va.va_nlink; - ip->i_size = va.va_size; - ip->i_blocks = va.va_nblocks; + if (likely(!error)) { + ip->i_nlink = va.va_nlink; + ip->i_blocks = va.va_nblocks; + + /* we're under i_sem so i_size can't change under us */ + if (i_size_read(ip) != va.va_size) + i_size_write(ip, va.va_size); + } } /* @@ -536,6 +541,7 @@ linvfs_setattr( if (error) return(-error); /* Positive error up from XFS */ if (ia_valid & ATTR_SIZE) { + i_size_write(inode, vattr.va_size); error = vmtruncate(inode, attr->ia_size); } Index: fs/xfs/linux-2.6/xfs_super.c =================================================================== RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c,v retrieving revision 1.294 diff -u -p -r1.294 xfs_super.c --- fs/xfs/linux-2.6/xfs_super.c 21 Jan 2004 16:46:06 -0000 1.294 +++ fs/xfs/linux-2.6/xfs_super.c 4 Feb 2004 17:56:55 -0000 @@ -178,7 +178,7 @@ xfs_revalidate_inode( } inode->i_blksize = PAGE_CACHE_SIZE; inode->i_generation = ip->i_d.di_gen; - i_size_write(inode, ip->i_d.di_size); + inode->i_size = ip->i_d.di_size; inode->i_blocks = XFS_FSB_TO_BB(mp, ip->i_d.di_nblocks + ip->i_delayed_blks); inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; Index: fs/xfs/linux-2.6/xfs_vnode.c =================================================================== RCS file: /cvs/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c,v retrieving revision 1.120 diff -u -p -r1.120 xfs_vnode.c --- fs/xfs/linux-2.6/xfs_vnode.c 20 Oct 2003 02:08:58 -0000 1.120 +++ fs/xfs/linux-2.6/xfs_vnode.c 4 Feb 2004 17:56:55 -0000 @@ -213,7 +213,6 @@ vn_revalidate( inode->i_mtime = va.va_mtime; inode->i_ctime = va.va_ctime; inode->i_atime = va.va_atime; - i_size_write(inode, va.va_size); if (va.va_xflags & XFS_XFLAG_IMMUTABLE) inode->i_flags |= S_IMMUTABLE; else From owner-linux-xfs@oss.sgi.com Wed Feb 4 10:17:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 10:17:47 -0800 (PST) Received: from medoc.inf.ethz.ch (medoc.inf.ethz.ch [129.132.178.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14IHYKO015861 for ; Wed, 4 Feb 2004 10:17:34 -0800 Received: from localhost (localhost [127.0.0.1]) by medoc.inf.ethz.ch (Postfix) with ESMTP id 986CAB566; Wed, 4 Feb 2004 18:36:27 +0100 (MET) Received: from medoc.inf.ethz.ch ([127.0.0.1]) by localhost (medoc [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04917-01-8; Wed, 4 Feb 2004 18:36:27 +0100 (MET) Received: from inf.ethz.ch (ikarus.inf.ethz.ch [129.132.10.58]) by medoc.inf.ethz.ch (Postfix) with ESMTP id 16EE0B561; Wed, 4 Feb 2004 18:36:27 +0100 (MET) Message-ID: <40212D9B.9000702@inf.ethz.ch> Date: Wed, 04 Feb 2004 18:36:27 +0100 From: Marc Schmitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Rich Cc: XFS mailing list Subject: Re: ghost files References: In-Reply-To: X-Enigmail-Version: 0.76.4.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at inf.ethz.ch X-archive-position: 2005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs I had a similar problem with 3 files on ext3 today. What worked for me was to copy any intact files out of the folder to another partition, `rm -rf` the folder (in your case xap) and then recreate the folder and copy the intact files back. The deletion brought up some kernel warnings: EXT3-fs warning (device sd(8,113)): ext3_unlink: Deleting nonexistent file (1868346), 0 EXT3-fs warning (device sd(8,113)): ext3_unlink: Deleting nonexistent file (1868345), 0 EXT3-fs warning (device sd(8,113)): ext3_unlink: Deleting nonexistent file (1868347), 0 But it worked. Finally I did restore the buggy files from tape, they were backed up sucessfuly two months ago or so. I'm not sure if it will work on XFS but might be worth a try. Marc James Rich wrote: >Hi folks, > >I have a strange thing happening. My rsync mirror of slackware.com has >"ghost files" in it, i.e. files that don't exist yet most file operations >still find them. Here is an example using 'ls': > >root@universe:/home/ftp/pub/slackware-current/slackware/xap# ls >/bin/ls: mozilla-1.4.1-i486-1.tgz: No such file or directory >/bin/ls: mozilla-1.4.1-i486-1.tgz.asc: No such file or directory >/bin/ls: mozilla-1.4.1-i486-1.txt: No such file or directory >/bin/ls: gimp-1.3.23-i486-1.txt: No such file or directory >/bin/ls: mozilla-plugins-1.4.1-noarch-1.tgz: No such file or directory >/bin/ls: mozilla-plugins-1.4.1-noarch-1.tgz.asc: No such file or directory >/bin/ls: mozilla-plugins-1.4.1-noarch-1.txt: No such file or directory > >Notice 'ls' "sees" these files, but they don't actually exist. I don't >know how to delete what doesn't exist, but I would like to get ls to quit >reporting these files (ls isn't the only command, chown does the same >thing). What should I do? > >James Rich > > > > From owner-linux-xfs@oss.sgi.com Wed Feb 4 10:34:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 10:34:47 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14IYVKO016992 for ; Wed, 4 Feb 2004 10:34:31 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i14IYPBP017985 for ; Wed, 4 Feb 2004 10:34:25 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i14IYPMo33654618 for ; Wed, 4 Feb 2004 12:34:25 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AoRqy-0003SW-00 for ; Wed, 04 Feb 2004 12:34:24 -0600 Date: Wed, 4 Feb 2004 12:34:24 -0600 From: Nathan Straz To: XFS mailing list Subject: Re: ghost files Message-ID: <20040204183424.GD8780@sgi.com> Mail-Followup-To: XFS mailing list References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 2006 X-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, Feb 04, 2004 at 10:11:54AM -0700, James Rich wrote: > Notice 'ls' "sees" these files, but they don't actually exist. I'm curious. Does `echo *` show those files? -- 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 Feb 4 10:47:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 10:48:09 -0800 (PST) Received: from universe.chowhouse.com (IDENT:0@universe.chowhouse.com [209.180.91.165]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14IlsKO017757 for ; Wed, 4 Feb 2004 10:47:55 -0800 Received: from universe.chowhouse.com (IDENT:1000@localhost [127.0.0.1]) by universe.chowhouse.com (8.12.10/8.12.10) with ESMTP id i14IlstW003776; Wed, 4 Feb 2004 11:47:54 -0700 Received: from localhost (james@localhost) by universe.chowhouse.com (8.12.10/8.12.10/Submit) with ESMTP id i14IlsEP003773; Wed, 4 Feb 2004 11:47:54 -0700 Date: Wed, 4 Feb 2004 11:47:54 -0700 (MST) From: James Rich To: Nathan Straz cc: XFS mailing list Subject: Re: ghost files In-Reply-To: <20040204183424.GD8780@sgi.com> Message-ID: References: <20040204183424.GD8780@sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2007 X-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@universe.chowhouse.com Precedence: bulk X-list: linux-xfs On Wed, 4 Feb 2004, Nathan Straz wrote: > On Wed, Feb 04, 2004 at 10:11:54AM -0700, James Rich wrote: > > Notice 'ls' "sees" these files, but they don't actually exist. > > I'm curious. Does `echo *` show those files? I'm sorry, I already ran xfs_repair which fixed things so I can't tell you now. :( Of course, I'm thrilled that xfs_repair worked. James Rich From owner-linux-xfs@oss.sgi.com Wed Feb 4 13:38:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 13:39:01 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14LcjKO029291 for ; Wed, 4 Feb 2004 13:38:45 -0800 Received: from arkon-group.com (207.34.136.14 [207.34.136.14]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DAZ23010; Wed, 4 Feb 2004 13:34:39 -0800 Message-ID: <4021668E.1010002@arkon-group.com> Date: Wed, 04 Feb 2004 13:39:26 -0800 From: Norman Zhang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "linux-xfs@oss.sgi.com" Subject: ACL and Quota Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2008 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Hi, I'm using XFS with Quota on a Samba server. I have mirrored the folders to a different server for high availability. I would like to copy the quota for the XFS partitions to the new server. May I ask where are quota files stored on XFS partitions? Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Feb 4 13:55:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 13:55:21 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14LtJKO030810 for ; Wed, 4 Feb 2004 13:55:19 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i14LtEBP032503 for ; Wed, 4 Feb 2004 13:55:14 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i14LtDLj24786570 for ; Wed, 4 Feb 2004 13:55:13 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i14LtAhI2288287 for ; Thu, 5 Feb 2004 08:55:10 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i14Lt9Um2326754 for linux-xfs@oss.sgi.com; Thu, 5 Feb 2004 08:55:09 +1100 (EST) Date: Thu, 5 Feb 2004 08:55:09 +1100 (EST) From: Nathan Scott Message-Id: <200402042155.i14Lt9Um2326754@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.2 X-archive-position: 2009 X-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 Feb 3 23:10:36 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166139a drivers/ide/ide-generic.c - 1.1 Makefile - 1.5 arch/i386/defconfig - 1.3 arch/ppc/boot/simple/embed_config.c - 1.2 arch/ppc64/defconfig - 1.2 arch/ppc64/kernel/asm-offsets.c - 1.3 arch/ppc64/kernel/head.S - 1.3 arch/ppc64/kernel/iSeries_VpdInfo.c - 1.3 arch/ppc64/kernel/pacaData.c - 1.2 arch/ppc64/kernel/ppc_ksyms.c - 1.3 arch/ppc64/kernel/proc_ppc64.c - 1.3 arch/ppc64/kernel/process.c - 1.3 arch/ppc64/kernel/prom.c - 1.3 arch/ppc64/kernel/rtas_flash.c - 1.3 arch/ppc64/kernel/setup.c - 1.3 arch/ppc64/kernel/signal.c - 1.3 arch/ppc64/kernel/signal32.c - 1.3 arch/ppc64/kernel/stab.c - 1.2 arch/ppc64/kernel/sys_ppc32.c - 1.3 arch/ppc64/mm/hugetlbpage.c - 1.4 arch/ppc64/xmon/start.c - 1.2 arch/s390/Makefile - 1.2 arch/s390/defconfig - 1.3 arch/s390/kernel/compat_linux.c - 1.3 arch/s390/kernel/s390_ksyms.c - 1.2 arch/s390/mm/init.c - 1.2 arch/sparc/kernel/traps.c - 1.3 arch/sparc/mm/fault.c - 1.4 arch/sparc/mm/srmmu.c - 1.4 arch/sparc64/kernel/power.c - 1.3 drivers/acpi/dispatcher/dsmthdat.c - 1.3 drivers/block/ll_rw_blk.c - 1.4 drivers/ide/Kconfig - 1.4 drivers/ide/Makefile - 1.3 drivers/ide/ide-probe.c - 1.2 drivers/ide/ide-proc.c - 1.2 drivers/ide/ide.c - 1.4 drivers/ide/legacy/Makefile - 1.2 drivers/ide/pci/Makefile - 1.3 drivers/ide/pci/cmd640.c - 1.3 drivers/ide/ppc/Makefile - 1.2 drivers/ide/setup-pci.c - 1.3 drivers/ieee1394/highlevel.c - 1.4 drivers/ieee1394/sbp2.c - 1.4 drivers/ieee1394/sbp2.h - 1.2 drivers/net/sk98lin/h/skversion.h - 1.3 drivers/net/sk98lin/skge.c - 1.3 drivers/net/tg3.c - 1.3 drivers/pci/probe.c - 1.4 drivers/s390/char/sclp.c - 1.2 drivers/s390/char/sclp_con.c - 1.3 drivers/s390/char/sclp_rw.c - 1.3 drivers/s390/char/sclp_tty.c - 1.3 drivers/s390/cio/device.c - 1.3 drivers/s390/net/ctctty.c - 1.3 drivers/usb/host/ehci-hub.c - 1.2 fs/compat_ioctl.c - 1.4 include/asm-ppc/todc.h - 1.2 include/asm-ppc64/bugs.h - 1.2 include/asm-ppc64/cputable.h - 1.3 include/asm-ppc64/hvcall.h - 1.3 include/asm-ppc64/mmu.h - 1.3 include/asm-ppc64/mmu_context.h - 1.3 include/asm-ppc64/paca.h - 1.3 include/asm-ppc64/percpu.h - 1.2 include/asm-ppc64/pgtable.h - 1.3 include/asm-ppc64/ppc_asm.h - 1.3 include/asm-ppc64/processor.h - 1.3 include/asm-ppc64/ptrace-common.h - 1.2 include/asm-ppc64/serial.h - 1.2 include/asm-s390/atomic.h - 1.2 include/asm-s390/bitops.h - 1.3 include/asm-s390/byteorder.h - 1.3 include/asm-s390/checksum.h - 1.3 include/asm-s390/div64.h - 1.2 include/asm-s390/pgtable.h - 1.3 include/asm-s390/processor.h - 1.2 include/asm-s390/rwsem.h - 1.2 include/asm-s390/semaphore.h - 1.2 include/asm-s390/spinlock.h - 1.3 include/asm-s390/system.h - 1.2 include/asm-s390/timex.h - 1.2 include/asm-s390/tlbflush.h - 1.3 include/asm-s390/uaccess.h - 1.3 include/asm-sparc/highmem.h - 1.3 include/asm-sparc/pgtsrmmu.h - 1.3 include/linux/compat_ioctl.h - 1.4 include/linux/ide.h - 1.4 include/linux/proc_fs.h - 1.4 kernel/exit.c - 1.4 lib/vsprintf.c - 1.2 net/ipv4/ip_output.c - 1.3 drivers/md/raid6x86.h - 1.2 arch/ppc64/mm/hash_low.S - 1.2 arch/ppc64/kernel/viopath.c - 1.2 arch/ppc64/kernel/lparcfg.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 4 15:16:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 15:16:32 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i14NGDKO002447 for ; Wed, 4 Feb 2004 15:16:14 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i14NG4sq000682 for ; Wed, 4 Feb 2004 17:16:06 -0600 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 KAA07216; Thu, 5 Feb 2004 10:15:57 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i14NFtUc2405643; Thu, 5 Feb 2004 10:15:56 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i14NFSqt000994; Thu, 5 Feb 2004 10:15:29 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i14NFRrY000992; Thu, 5 Feb 2004 10:15:27 +1100 Date: Thu, 5 Feb 2004 10:15:27 +1100 From: Nathan Scott To: Norman Zhang Cc: linux-xfs@oss.sgi.com Subject: Re: ACL and Quota Message-ID: <20040204231527.GB836@frodo> References: <4021668E.1010002@arkon-group.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4021668E.1010002@arkon-group.com> User-Agent: Mutt/1.5.3i X-archive-position: 2010 X-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, Feb 04, 2004 at 01:39:26PM -0800, Norman Zhang wrote: > Hi, > > I'm using XFS with Quota on a Samba server. I have mirrored the folders > to a different server for high availability. I would like to copy the > quota for the XFS partitions to the new server. May I ask where are > quota files stored on XFS partitions? Nowhere that they can directly accessed. If the new server is running XFS, you should just mount with quota enabled, and copy away. If its not XFS, you'll want to dump the quota info to a file and restore it using setquota -- see xfsdq(8) and xfsrq(8) in the xfsdump package which will do that for you. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 4 16:08:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 16:09:08 -0800 (PST) Received: from mail.arkon-group.com (mail.arkon-group.com [207.34.136.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1508rKO009228 for ; Wed, 4 Feb 2004 16:08:56 -0800 Received: from arkon-group.com (207.34.136.14 [207.34.136.14]) by mail.arkon-group.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DAZ230GZ; Wed, 4 Feb 2004 16:04:47 -0800 Message-ID: <402189BF.7070900@arkon-group.com> Date: Wed, 04 Feb 2004 16:09:35 -0800 From: Norman Zhang User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: ACL and Quota References: <4021668E.1010002@arkon-group.com> <20040204231527.GB836@frodo> In-Reply-To: <20040204231527.GB836@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2011 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nzhang@arkon-group.com Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > On Wed, Feb 04, 2004 at 01:39:26PM -0800, Norman Zhang wrote: > >>I'm using XFS with Quota on a Samba server. I have mirrored the folders >>to a different server for high availability. I would like to copy the >>quota for the XFS partitions to the new server. May I ask where are >>quota files stored on XFS partitions? > > Nowhere that they can directly accessed. If the new server is > running XFS, you should just mount with quota enabled, and copy My new server is already running XFS and quota. I rsync'd files over but quota is not reserved. I had to manually enter the quota restrictions in. May I ask what do you mean by copy away? > away. If its not XFS, you'll want to dump the quota info to a > file and restore it using setquota -- see xfsdq(8) and xfsrq(8) > in the xfsdump package which will do that for you. Thanks. I will try xfsdq and xfsrq. Regards, Norman From owner-linux-xfs@oss.sgi.com Wed Feb 4 16:22:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 16:22:24 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i150MMKO012806 for ; Wed, 4 Feb 2004 16:22:22 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i150MFsq029542 for ; Wed, 4 Feb 2004 18:22:16 -0600 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 LAA08132; Thu, 5 Feb 2004 11:22:12 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i150MBUc3954234; Thu, 5 Feb 2004 11:22:11 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i150Ljqt001205; Thu, 5 Feb 2004 11:21:45 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i150Lj4t001203; Thu, 5 Feb 2004 11:21:45 +1100 Date: Thu, 5 Feb 2004 11:21:45 +1100 From: Nathan Scott To: Norman Zhang Cc: linux-xfs@oss.sgi.com Subject: Re: ACL and Quota Message-ID: <20040205002145.GD836@frodo> References: <4021668E.1010002@arkon-group.com> <20040204231527.GB836@frodo> <402189BF.7070900@arkon-group.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <402189BF.7070900@arkon-group.com> User-Agent: Mutt/1.5.3i X-archive-position: 2012 X-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, Feb 04, 2004 at 04:09:35PM -0800, Norman Zhang wrote: > Nathan Scott wrote: > >On Wed, Feb 04, 2004 at 01:39:26PM -0800, Norman Zhang wrote: > > > >>I'm using XFS with Quota on a Samba server. I have mirrored the folders > >>to a different server for high availability. I would like to copy the > >>quota for the XFS partitions to the new server. May I ask where are > >>quota files stored on XFS partitions? > > > >Nowhere that they can directly accessed. If the new server is > >running XFS, you should just mount with quota enabled, and copy > > My new server is already running XFS and quota. I rsync'd files over but > quota is not reserved. I had to manually enter the quota restrictions > in. May I ask what do you mean by copy away? Sorry, I misunderstood - you want the limits preserved, not just the usage info (which is done automatically). > Thanks. I will try xfsdq and xfsrq. Yes, those should get you the limits copied across. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 4 18:30:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 18:30:21 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i152UJKO021612 for ; Wed, 4 Feb 2004 18:30:19 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i152UCsq022771 for ; Wed, 4 Feb 2004 20:30:13 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i152QIjq009303 for ; Thu, 5 Feb 2004 13:26:18 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i152QHs2009280 for linux-xfs@oss.sgi.com; Thu, 5 Feb 2004 13:26:17 +1100 Date: Thu, 5 Feb 2004 13:26:17 +1100 From: FSG QA Message-Id: <200402050226.i152QHs2009280@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 2013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix ag-wipe so that it runs on IRIX (getopt reorders args in glibc). Date: Wed Feb 4 18:29:06 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166225a xfstests/tools/ag-wipe - 1.4 From owner-linux-xfs@oss.sgi.com Wed Feb 4 19:20:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Feb 2004 19:20:41 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i153KTKO023609 for ; Wed, 4 Feb 2004 19:20:29 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i153KMsq025497 for ; Wed, 4 Feb 2004 21:20:23 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i153GSTa004424 for ; Thu, 5 Feb 2004 14:16:29 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i153GSDd004423 for linux-xfs@oss.sgi.com; Thu, 5 Feb 2004 14:16:28 +1100 Date: Thu, 5 Feb 2004 14:16:28 +1100 From: FSG QA Message-Id: <200402050316.i153GSDd004423@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 2014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Several minor updates, and Chris Pascoe's test case at the end for detecting incorrect unwritten extent related zeroes at EOF. -- nathans Update copyright dates auto-generated for new QA scripts. Date: Wed Feb 4 18:55:06 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166227a xfstests/new - 1.10 Jacks program for testing multiple concurrent reader scalability. Date: Wed Feb 4 18:59:08 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166228a xfstests/src/scaleread.c - 1.1 xfstests/src/scaleread.sh - 1.1 Test for detecting unwritten extent related corruption reading+writing under memory pressure and swap. Date: Wed Feb 4 19:02:12 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166229a xfstests/084 - 1.1 xfstests/084.out - 1.1 xfstests/src/resvtest.c - 1.1 xfstests/group - 1.47 xfstests/src/Makefile - 1.20 From owner-linux-xfs@oss.sgi.com Thu Feb 5 04:31:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 04:32:19 -0800 (PST) Received: from smtp.cistron-office.nl (mail@10fwd.cistron-office.nl [62.216.29.197]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15CVlKO005136 for ; Thu, 5 Feb 2004 04:31:48 -0800 Received: from traveler.cistron-office.nl ([62.216.29.67] helo=traveler) by smtp.cistron-office.nl with esmtp (Exim 3.35 #1 (Debian)) id 1AoieT-0000tN-00; Thu, 05 Feb 2004 13:30:37 +0100 Date: Thu, 5 Feb 2004 13:30:37 +0100 From: Miquel van Smoorenburg To: Christoph Hellwig Cc: Steve Lord , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040205123037.GW3166@traveler.cistron.net> References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> <401FAC70.8070104@xfs.org> <20040204181709.A21093@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040204181709.A21093@infradead.org> (from hch@infradead.org on Wed, Feb 04, 2004 at 19:17:09 +0100) X-Mailer: Balsa 2.0.16 Lines: 22 X-archive-position: 2015 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: miquels@cistron.net Precedence: bulk X-list: linux-xfs On 2004.02.04 19:17, Christoph Hellwig wrote: > Here's a new diff, that should get rid of all the warnings except for > O_DIRECT. I've also addressed the comments from Dave and Steve. This patch appears to work fine, but mkdir() still warns about i_size_write() : i_size_write() called without i_sem Call Trace: [] i_size_write_check+0x61/0x63 [] validate_fields+0xbf/0xdc [xfs] [] linvfs_mknod+0x22c/0x41d [xfs] [] alloc_skb+0x47/0xe0 [] e1000_alloc_rx_buffers+0x57/0xf2 [] e1000_clean_rx_irq+0x104/0x43a [] xfs_dir2_lookup+0x14c/0x14e [xfs] [] xfs_dir_lookup_int+0x4c/0x12b [xfs] [] linvfs_mkdir+0x2a/0x2e [xfs] [] vfs_mkdir+0x8d/0x104 [] sys_mkdir+0xb7/0xf7 [] syscall_call+0x7/0xb Mike. From owner-linux-xfs@oss.sgi.com Thu Feb 5 04:33:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 04:33:27 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15CXHKO005305 for ; Thu, 5 Feb 2004 04:33:18 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Aoigy-0008Io-GL; Thu, 05 Feb 2004 12:33:12 +0000 Date: Thu, 5 Feb 2004 12:33:12 +0000 From: Christoph Hellwig To: Miquel van Smoorenburg Cc: Christoph Hellwig , Steve Lord , Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: 2.6.2-rc2 nfsd+xfs spins in i_size_read() Message-ID: <20040205123312.A31904@infradead.org> References: <20040129063009.GD2474@frodo> <20040128222521.75a7d74f.akpm@osdl.org> <20040129063009.GD2474@frodo> <20040129232033.GA10541@cistron.nl> <20040204000315.A12127@infradead.org> <401FAC70.8070104@xfs.org> <20040204181709.A21093@infradead.org> <20040205123037.GW3166@traveler.cistron.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040205123037.GW3166@traveler.cistron.net>; from miquels@cistron.net on Thu, Feb 05, 2004 at 01:30:37PM +0100 X-archive-position: 2016 X-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 Thu, Feb 05, 2004 at 01:30:37PM +0100, Miquel van Smoorenburg wrote: > On 2004.02.04 19:17, Christoph Hellwig wrote: > > Here's a new diff, that should get rid of all the warnings except for > > O_DIRECT. I've also addressed the comments from Dave and Steve. > > This patch appears to work fine, but mkdir() still warns about i_size_write() : Well, this one is harmless as the i_size write is on the newly created inode which isn't on the hash yet. Andrew, do you plan to keep the debugging check? If yes I could cludge around it, but I'd prefer not to. From owner-linux-xfs@oss.sgi.com Thu Feb 5 14:13:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 14:13:48 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15MDlKO001676 for ; Thu, 5 Feb 2004 14:13:47 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i15MDeV9011086 for ; Thu, 5 Feb 2004 14:13:41 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i15MDahI2565903; Fri, 6 Feb 2004 09:13:36 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i15MDJOA2561298; Fri, 6 Feb 2004 09:13:19 +1100 (EST) Date: Fri, 6 Feb 2004 09:13:19 +1100 (EST) From: Nathan Scott Message-Id: <200402052213.i15MDJOA2561298@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 907218 - fix compile warning X-archive-position: 2017 X-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 compile warning, ensure _pagebuf_lookup_pages return value is inited. Date: Thu Feb 5 14:10:44 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166301a linux-2.6/xfs_buf.c - 1.146 linux-2.4/xfs_buf.c - 1.165 From owner-linux-xfs@oss.sgi.com Thu Feb 5 14:59:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 14:59:28 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15MxEKO003847 for ; Thu, 5 Feb 2004 14:59:14 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i15Mx4va010827 for ; Thu, 5 Feb 2004 16:59:08 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i15Mx3hI2577796 for ; Fri, 6 Feb 2004 09:59:03 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i15Mx3ni1451430 for linux-xfs@oss.sgi.com; Fri, 6 Feb 2004 09:59:03 +1100 (EST) Date: Fri, 6 Feb 2004 09:59:03 +1100 (EST) From: Nathan Scott Message-Id: <200402052259.i15Mx3ni1451430@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.25-rc1 X-archive-position: 2018 X-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 Feb 5 14:57:48 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:166306a net/sched/sch_hfsc.c - 1.1 include/asm-sparc64/sections.h - 1.1 CREDITS - 1.4 Documentation/Configure.help - 1.8 Makefile - 1.7 arch/sparc64/kernel/head.S - 1.4 arch/sparc64/kernel/ioctl32.c - 1.2 arch/sparc64/kernel/setup.c - 1.2 arch/sparc64/mm/init.c - 1.3 crypto/sha256.c - 1.2 crypto/sha512.c - 1.2 drivers/atm/idt77252.c - 1.2 drivers/char/agp/agpgart_be.c - 1.3 drivers/char/amd76x_pm.c - 1.2 drivers/char/tipar.c - 1.2 drivers/char/vac-serial.c - 1.2 drivers/ieee1394/csr.c - 1.2 drivers/isdn/hisax/amd7930_fn.c - 1.2 drivers/isdn/hisax/amd7930_fn.h - 1.2 drivers/net/e100/e100.h - 1.2 drivers/net/e100/e100_config.c - 1.2 drivers/net/e100/e100_config.h - 1.2 drivers/net/e100/e100_eeprom.c - 1.2 drivers/net/e100/e100_main.c - 1.2 drivers/net/e100/e100_phy.c - 1.2 drivers/net/e100/e100_phy.h - 1.2 drivers/net/e100/e100_test.c - 1.2 drivers/net/e100/e100_ucode.h - 1.2 drivers/net/irda/act200l.c - 1.2 drivers/net/irda/irda-usb.c - 1.2 drivers/net/irda/ma600.c - 1.2 drivers/net/irda/smc-ircc.c - 1.2 drivers/net/sk98lin/h/skversion.h - 1.2 drivers/net/sk98lin/skge.c - 1.2 drivers/net/tg3.c - 1.3 drivers/net/wan/8253x/crc32dcl.h - 1.2 drivers/scsi/aha1542.c - 1.2 drivers/scsi/cpqfcTSi2c.c - 1.2 drivers/sound/ac97_plugin_ad1980.c - 1.2 fs/binfmt_elf.c - 1.2 fs/intermezzo/file.c - 1.2 fs/namespace.c - 1.2 fs/ntfs/fs.c - 1.2 include/linux/inetdevice.h - 1.2 include/linux/list.h - 1.2 include/linux/netfilter_ipv4/ip_conntrack.h - 1.2 include/linux/pkt_sched.h - 1.2 include/linux/sysctl.h - 1.3 include/net/pkt_sched.h - 1.2 mm/filemap.c - 1.3 net/atm/clip.c - 1.2 net/decnet/dn_neigh.c - 1.2 net/ipv4/devinet.c - 1.2 net/ipv4/igmp.c - 1.4 net/ipv4/netfilter/ip_conntrack_standalone.c - 1.2 net/ipv4/netfilter/ip_nat_standalone.c - 1.2 net/ipv4/netfilter/ipt_conntrack.c - 1.2 net/ipv4/netfilter/ipt_helper.c - 1.2 net/ipv4/netfilter/ipt_limit.c - 1.2 net/ipv4/netfilter/ipt_state.c - 1.2 net/sched/Config.in - 1.2 drivers/net/irda/via-ircc.c - 1.3 drivers/usb/gadget/file_storage.c - 1.2 From owner-linux-xfs@oss.sgi.com Thu Feb 5 15:08:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 15:08:29 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15N8CKO004422 for ; Thu, 5 Feb 2004 15:08:13 -0800 Received: from port-212-202-171-182.reverse.qdsl-home.de ([212.202.171.182] helo=hro.bluespice.org) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1Aosar-0003HG-00; Fri, 06 Feb 2004 00:07:33 +0100 Received: from localhost ([127.0.0.1] helo=bluespice.dyndns.org) by hro.bluespice.org with esmtp (Exim 4.30) id 1Aosb2-0002qO-5N; Fri, 06 Feb 2004 00:07:44 +0100 Received: from port-212-202-171-182.reverse.qdsl-home.de ([212.202.171.182]) (proxying for 192.168.0.1) (SquirrelMail authenticated user ij); by bluespice.dyndns.org with HTTP; Fri, 6 Feb 2004 00:07:44 +0100 (CET) Message-ID: <7665.212.202.171.182.1076022464.squirrel@212.202.171.182> In-Reply-To: <20040204072816.GA24743@2004.bluespice.org> References: <20040204072816.GA24743@2004.bluespice.org> Date: Fri, 6 Feb 2004 00:07:44 +0100 (CET) Subject: Re: XFS problem with 2.6.2-rc2 From: "Ingo Juergensmann" To: "Ingo Juergensmann" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 2019 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ij@2004.bluespice.org Precedence: bulk X-list: linux-xfs Ingo Juergensmann said: > It happened today during the daily cron runs of updatedb f.e., but happened > as well during "normal" activity when using the machine. > When I run xfs_repair several times, the errors are mostly fixed, although > many files usually get moved to lost+found. Some addition to that: # xfs_repair -V xfs_repair version 2.6.3 # xfs_repair -n -l /dev/hda8 /dev/hdc1 . . . would junk entry "LC_MESSAGES" entry "LC_MESSAGES" in shortform directory inode 50331874 points to free inode 54526141 would junk entry "LC_MESSAGES" entry "copyright" in shortform directory inode 33554667 points to free inode 33554708 would junk entry "copyright" fatal error -- malloc failed in longform_dir2_entry_check (2382892308 bytes) I think I have no memory problem: # cat /proc/meminfo MemTotal: 644752 kB MemFree: 63796 kB Buffers: 21992 kB Cached: 278172 kB SwapCached: 0 kB Active: 524244 kB Inactive: 3180 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 644752 kB LowFree: 63796 kB SwapTotal: 1394604 kB SwapFree: 1394604 kB Dirty: 436 kB Writeback: 0 kB Mapped: 279680 kB Slab: 44488 kB Committed_AS: 474984 kB PageTables: 2016 kB VmallocTotal: 384988 kB VmallocUsed: 19448 kB VmallocChunk: 365456 kB memtest86 run a whole night as well with no reported error. So, this is supposed to be a bug within the userland tools, namely xfs_repair. Allocating 2 GB of memory is not very, uhm, modest... ;) -- Ciao... // "Such giants are these! Great shoulders bear Ingo \X/ so many. I stand among them." (D. Haynie) From owner-linux-xfs@oss.sgi.com Thu Feb 5 15:08:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 15:08:29 -0800 (PST) Received: from mx02.qsc.de (mx02.qsc.de [213.148.130.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i15N8DKO004423 for ; Thu, 5 Feb 2004 15:08:14 -0800 Received: from port-212-202-171-182.reverse.qdsl-home.de ([212.202.171.182] helo=hro.bluespice.org) by mx02.qsc.de with esmtp (Exim 3.35 #1) id 1Aosav-0003HI-00; Fri, 06 Feb 2004 00:07:37 +0100 Received: from localhost ([127.0.0.1] helo=bluespice.dyndns.org) by hro.bluespice.org with esmtp (Exim 4.30) id 1Aosb5-0002qX-Dj; Fri, 06 Feb 2004 00:07:47 +0100 Received: from port-212-202-171-182.reverse.qdsl-home.de ([212.202.171.182]) (proxying for 192.168.0.1) (SquirrelMail authenticated user ij); by bluespice.dyndns.org with HTTP; Fri, 6 Feb 2004 00:07:47 +0100 (CET) Message-ID: <7671.212.202.171.182.1076022467.squirrel@212.202.171.182> Date: Fri, 6 Feb 2004 00:07:47 +0100 (CET) Subject: Re: XFS problem with 2.6.2-rc2 From: "Ingo Juergensmann" To: "Ingo Juergensmann" Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.5.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 2020 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ij@2004.bluespice.org Precedence: bulk X-list: linux-xfs Ingo Juergensmann said: > It happened today during the daily cron runs of updatedb f.e., but happened > as well during "normal" activity when using the machine. > When I run xfs_repair several times, the errors are mostly fixed, although > many files usually get moved to lost+found. Some addition to that: # xfs_repair -V xfs_repair version 2.6.3 # xfs_repair -n -l /dev/hda8 /dev/hdc1 . . . would junk entry "LC_MESSAGES" entry "LC_MESSAGES" in shortform directory inode 50331874 points to free inode 54526141 would junk entry "LC_MESSAGES" entry "copyright" in shortform directory inode 33554667 points to free inode 33554708 would junk entry "copyright" fatal error -- malloc failed in longform_dir2_entry_check (2382892308 bytes) I think I have no memory problem: # cat /proc/meminfo MemTotal: 644752 kB MemFree: 63796 kB Buffers: 21992 kB Cached: 278172 kB SwapCached: 0 kB Active: 524244 kB Inactive: 3180 kB HighTotal: 0 kB HighFree: 0 kB LowTotal: 644752 kB LowFree: 63796 kB SwapTotal: 1394604 kB SwapFree: 1394604 kB Dirty: 436 kB Writeback: 0 kB Mapped: 279680 kB Slab: 44488 kB Committed_AS: 474984 kB PageTables: 2016 kB VmallocTotal: 384988 kB VmallocUsed: 19448 kB VmallocChunk: 365456 kB memtest86 run a whole night as well with no reported error. So, this is supposed to be a bug within the userland tools, namely xfs_repair. Allocating 2 GB of memory is not very, uhm, modest... ;) -- Ciao... // "Such giants are these! Great shoulders bear Ingo \X/ so many. I stand among them." (D. Haynie) From owner-linux-xfs@oss.sgi.com Thu Feb 5 19:55:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 19:55:44 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i163tVKO017441 for ; Thu, 5 Feb 2004 19:55:32 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i163tQva012475 for ; Thu, 5 Feb 2004 21:55:26 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i163tOtH24652611 for ; Thu, 5 Feb 2004 19:55:25 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i163tJhI2721643; Fri, 6 Feb 2004 14:55:19 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i163tIW62111374; Fri, 6 Feb 2004 14:55:18 +1100 (EST) Date: Fri, 6 Feb 2004 14:55:18 +1100 (EST) From: Nathan Scott Message-Id: <200402060355.i163tIW62111374@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 907984 - fix unwritten extents bug X-archive-position: 2021 X-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 data loss when writing into unwritten extents while memory is being reclaimed. Date: Thu Feb 5 19:54:01 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166324a linux-2.6/xfs_aops.c - 1.59 linux-2.4/xfs_aops.c - 1.68 From owner-linux-xfs@oss.sgi.com Thu Feb 5 20:27:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 20:27:44 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i164RgKO021488 for ; Thu, 5 Feb 2004 20:27:43 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i164Rbva020290 for ; Thu, 5 Feb 2004 22:27:37 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i164RZtH25100846 for ; Thu, 5 Feb 2004 20:27:36 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i164RWhI2761820; Fri, 6 Feb 2004 15:27:32 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i164RVX42774692; Fri, 6 Feb 2004 15:27:31 +1100 (EST) Date: Fri, 6 Feb 2004 15:27:31 +1100 (EST) From: Nathan Scott Message-Id: <200402060427.i164RVX42774692@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 909060 - sync up source trees X-archive-position: 2022 X-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 with external trees, fixing the build after support source renames. Date: Thu Feb 5 20:26:12 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166330a xfs.h - 1.44 xfs_types.h - 1.73 support/uuid.c - 1.16 support/Makefile - 1.20 support/ktrace.h - 1.11 Makefile-linux-2.6 - 1.185 linux-2.6/xfs_linux.h - 1.116 linux-2.4/xfs_linux.h - 1.128 linux-2.4/Makefile - 1.202 linux-2.4/kmem.c - 1.31 linux-2.6/time.h - 1.14 From owner-linux-xfs@oss.sgi.com Thu Feb 5 22:00:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 22:00:44 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1660eKO024777 for ; Thu, 5 Feb 2004 22:00:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1661a2F014975 for ; Thu, 5 Feb 2004 22:01:36 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1660Yer33497240; Fri, 6 Feb 2004 00:00:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1660Y0n2226995; Fri, 6 Feb 2004 00:00:34 -0600 (CST) Date: Fri, 6 Feb 2004 00:00:34 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ingo Juergensmann cc: linux-xfs@oss.sgi.com Subject: Re: XFS problem with 2.6.2-rc2 In-Reply-To: <7665.212.202.171.182.1076022464.squirrel@212.202.171.182> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2023 X-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 Fri, 6 Feb 2004, Ingo Juergensmann wrote: > fatal error -- malloc failed in longform_dir2_entry_check (2382892308 bytes) ... > memtest86 run a whole night as well with no reported error. So, this is > supposed to be a bug within the userland tools, namely xfs_repair. Allocating > 2 GB of memory is not very, uhm, modest... ;) It would be interesting to rebuild xfs_repair with an edit to phase6.c, to print out the inode number (ip->i_ino) and ip->i_d.di_size to see why it's allocating so much... with the inode number in hand we could take a closer look at the inode in xfs_db. Just an idea... Did you have some very large files on this filesystem? It looks like the size it wants to allocate is relative to the number of bytes in the file... -Eric From owner-linux-xfs@oss.sgi.com Thu Feb 5 22:16:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 05 Feb 2004 22:16:50 -0800 (PST) Received: from mail.mnsu.edu (Mail.MNSU.EDU [134.29.1.12]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i166GaKO025471 for ; Thu, 5 Feb 2004 22:16:36 -0800 Received: from mnsu.edu (j3gum-5.MavNet.MNSU.EDU [134.29.64.3]) by mail.mnsu.edu (8.12.10/8.12.10) with ESMTP id i166Fm4P016218 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 6 Feb 2004 00:15:48 -0600 Message-ID: <40233114.9080507@mnsu.edu> Date: Fri, 06 Feb 2004 00:15:48 -0600 From: "Jeffrey E. Hundstad" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: Ingo Juergensmann , linux-xfs@oss.sgi.com Subject: Re: XFS problem with 2.6.2-rc2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2024 X-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 Keep in mind my recent personal experience. I tested my memory with memtest86 for two days with the extended option and found no errors. I compiled the kernel and found a SIG-11 that happens at different places every compile. ...I switched the memory and the compiles and memtest86 both worked successfully. ...in other words... it could really still be memory. -- jeffrey hundstad Eric Sandeen wrote: >On Fri, 6 Feb 2004, Ingo Juergensmann wrote: > > > >>memtest86 run a whole night as well with no reported error. So, this is >>supposed to be a bug within the userland tools, namely xfs_repair. Allocating >>2 GB of memory is not very, uhm, modest... ;) >> >> > > > From owner-linux-xfs@oss.sgi.com Fri Feb 6 08:37:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Feb 2004 08:37:12 -0800 (PST) Received: from provone.provsol.net (provone.provsol.net [66.83.239.66]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16Gb9KO001940 for ; Fri, 6 Feb 2004 08:37:09 -0800 Received: from localhost (localhost [127.0.0.1]) by provone.provsol.net (Postfix) with ESMTP id 5696F204292 for ; Fri, 6 Feb 2004 10:37:08 -0600 (CST) Received: from provone.provsol.net ([192.168.20.254]) by localhost (provone.provsol.net [192.168.20.254]) (amavisd-new, port 10024) with ESMTP id 15838-06 for ; Fri, 6 Feb 2004 10:37:06 -0600 (CST) Received: from serria.provsol.int (serria.provsol.int [192.168.20.22]) by provone.provsol.net (Postfix) with ESMTP id BE529204267 for ; Fri, 6 Feb 2004 10:37:06 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by serria.provsol.int (Postfix) with ESMTP id AF3F0A019CD for ; Fri, 6 Feb 2004 10:37:06 -0600 (CST) Received: from provident-solutions.com (cosby.provsol.int [192.168.20.35]) by serria.provsol.int (Postfix) with ESMTP id 4C5B7A019C4 for ; Fri, 6 Feb 2004 10:37:06 -0600 (CST) Message-ID: <4023C2B2.8030403@provident-solutions.com> Date: Fri, 06 Feb 2004 10:37:06 -0600 From: "Vernon A. Fort" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Corrupt File - Maybe Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS snapshot-20020300 X-Virus-Scanned: by amavisd-new at provident-solutions.com X-archive-position: 2025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: vfort@provident-solutions.com Precedence: bulk X-list: linux-xfs I am seeing what appears to be corrupt file in my cyrus-imap store. I'm really not sure if this is a cyrus or xfs related issue. The file 'name' is a set of un-printable chars with the content like: 370cf94637038545 1 1027956129 6743 1043134392 1:13309,13314:13315,13323,13347 370cf94637038545 1 1027956129 6743 1037201874 1:10682 370cf94637038545 1 1027956129 6743 1042863011 1:13309,13314:13315,13323,13347 xfs release 1.1 in kernel version 2.4.18-4. I know I need to update the box/xfs version but I also need to get rid of these files. Any pointers? Vernon From owner-linux-xfs@oss.sgi.com Fri Feb 6 11:43:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Feb 2004 11:43:27 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i16Jh5KO010085 for ; Fri, 6 Feb 2004 11:43:11 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e34.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i16JgxOH487344; Fri, 6 Feb 2004 14:42:59 -0500 Received: from d03nm800.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i16JgwbP113852; Fri, 6 Feb 2004 12:42:59 -0700 Subject: DMAPI: DM attribute/region space allocation To: roehrich@sgi.com Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 Message-ID: From: James A Goodwin Date: Fri, 6 Feb 2004 13:42:50 -0600 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 6.0.2CF2HF133 | November 14, 2003) at 02/06/2004 12:42:58 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1450 X-archive-position: 2026 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jagoodwi@us.ibm.com Precedence: bulk X-list: linux-xfs Dean, We have a problem when managing an XFS filesystem using the DMAPI. When we copy data from an XFS file to our archive, we cover the file with a DMAPI region to inform us of read, write, and truncate events. However, if the filesystem is full, we cannot establish this region, and we don't have a good way to recover. To fix the problem, we plan to preallocate a DM region to each file when it is created. This region would not be set to generate any I/O events but would serve only to preallocate storage. We could later modify the region to generate I/O events. If we couldn't create the region due to space constraints, we could just abort the file create. I have two questions. First, will this approach work? Second, will the pre-allocated region also preallocate space that could be used by DM attributes? I'm guessing that it will allocate one block, stick the region in there, and have lots of extra space for other extended attributes (i.e., DM attributes). I'm hoping that it will be enough to ensure that I can create, modify, and remove some number of DM attributes without having to worry about space shortages, but I have no idea how much space I'll have to play with. Any ideas or pointers you could give would be appreciated. Thanks, -James Goodwin Software Engineer IBM Business Consulting Services jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Feb 7 14:47:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Feb 2004 14:47:09 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i17Ml6KO015483 for ; Sat, 7 Feb 2004 14:47:07 -0800 Received: (qmail 4579 invoked by uid 65534); 7 Feb 2004 22:47:00 -0000 Received: from dialin-145-254-044-053.arcor-ip.net (EHLO omnibook) (145.254.44.53) by mail.gmx.net (mp004) with SMTP; 07 Feb 2004 23:47:00 +0100 X-Authenticated: #144508 Received: from bbowe by omnibook with local (Exim 3.35 #1 (Debian)) id 1ApbIJ-0002rL-00 for ; Sat, 07 Feb 2004 23:51:23 +0100 Date: Sat, 7 Feb 2004 23:51:23 +0100 From: Bastian Bowe To: linux-xfs@oss.sgi.com Subject: data recovery Message-ID: <20040207225123.GB10903@omnibook> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-archive-position: 2027 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Bastian-Bowe@STUD-LG.fhnon.de Precedence: bulk X-list: linux-xfs Hello, I lost all data of a huge xfs formatted partition. I used cfdisk from a boot cd to delete some partitions. After that I've created some new. The names of the devicenames changed. E.g. /dev/hda9 got /dev/hda8 or so. I left the huge xfs formatted partition alone. Unfortunately I did a big mistake: I didn't reboot before formatting the other partitions. I formatted them with reiserfs. After that I realised what I did. I rebooted and found out that the xfs disk isn't mountable anymore as a xfs disk. It is possible to mount it as reiserfs. The system was confused and so mkfs.reiserfs had old partition info and wrote to the xfs partition. I tried to use xfs_repair but it didn't find a superblock and exited after 20 minutes or so. I would be very thankful if any of you could give me a pointer to some sort of software or method to recover some of my data. Because mkfs.reiserfs only needed some seconds, I think most of my data it is still physically there. But most of the metadata has probably gone. BTW: I've read http://oss.sgi.com/projects/xfs/faq.html#undelete but I still want to be sure that I now can reformat my partition. Kind regards -- Bastian Bowe Sent using Debian GNU/Linux - http://www.debian.org From owner-linux-xfs@oss.sgi.com Sun Feb 8 15:54:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Feb 2004 15:54:32 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i18NrwKO007202 for ; Sun, 8 Feb 2004 15:53:58 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i18NrogI006712 for ; Sun, 8 Feb 2004 17:53:51 -0600 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 KAA15104; Mon, 9 Feb 2004 10:53:47 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i18NrjUc4010740; Mon, 9 Feb 2004 10:53:46 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i18NrDUe001174; Mon, 9 Feb 2004 10:53:14 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i18NrCnn001172; Mon, 9 Feb 2004 10:53:12 +1100 Date: Mon, 9 Feb 2004 10:53:12 +1100 From: Nathan Scott To: James A Goodwin Cc: roehrich@sgi.com, linux-xfs@oss.sgi.com Subject: Re: DMAPI: DM attribute/region space allocation Message-ID: <20040208235312.GF815@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 2028 X-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, Feb 06, 2004 at 01:42:50PM -0600, James A Goodwin wrote: > Dean, I think Deans away for a few days, let me try to answer... (and get overruled by Dean when he returns ;) > We have a problem when managing an XFS filesystem using the DMAPI. When we > copy data from an XFS file to our archive, we cover the file with a DMAPI > region to inform us of read, write, and truncate events. However, if the > filesystem is full, we cannot establish this region, and we don't have a > good way to recover. > > To fix the problem, we plan to preallocate a DM region to each file when it > is created. This region would not be set to generate any I/O events but > would serve only to preallocate storage. We could later modify the region > to generate I/O events. If we couldn't create the region due to space > constraints, we could just abort the file create. > I have two questions. First, will this approach work? Seems like a valid approach to me. > Second, will the > pre-allocated region also preallocate space that could be used by DM > attributes? No - preallocated space is for file data only. > I'm guessing that it will allocate one block, stick the region > in there, and have lots of extra space for other extended attributes (i.e., > DM attributes). I'm hoping that it will be enough to ensure that I can > create, modify, and remove some number of DM attributes without having to > worry about space shortages, but I have no idea how much space I'll have to > play with. I believe SGIs HSM uses the XFS RESBLKS interface to reserve a set amount of filesystem space, which is only available when allocating extended attribute space for the root namespace (where the DMAPI attributes reside). HTH. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 8 16:12:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Feb 2004 16:12:44 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i190CHKO008419 for ; Sun, 8 Feb 2004 16:12:17 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i18NDEON017824 for ; Sun, 8 Feb 2004 15:13:17 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i18NC2hI5944559 for ; Mon, 9 Feb 2004 10:12:03 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i18NC2XN5950572 for linux-xfs@oss.sgi.com; Mon, 9 Feb 2004 10:12:02 +1100 (EST) Date: Mon, 9 Feb 2004 10:12:02 +1100 (EST) From: Nathan Scott Message-Id: <200402082312.i18NC2XN5950572@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.3-rc1 X-archive-position: 2029 X-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 Feb 8 15:06:13 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166394a drivers/scsi/qla2xxx/ql6312_fw.c - 1.1 drivers/scsi/qla2xxx/ql6312.c - 1.1 drivers/scsi/qla2xxx/ql2322_fw.c - 1.1 drivers/scsi/qla2xxx/ql2322.c - 1.1 drivers/scsi/qla2xxx/ql6322.c - 1.1 drivers/scsi/qla2xxx/ql6322_fw.c - 1.1 drivers/video/fbsysfs.c - 1.1 drivers/net/wireless/atmel_pci.c - 1.1 include/asm-arm/arch-integrator/cm.h - 1.1 include/asm-parisc/compat_rt_sigframe.h - 1.1 include/asm-parisc/compat_signal.h - 1.1 include/asm-parisc/compat_ucontext.h - 1.1 include/asm-ppc/pmac_low_i2c.h - 1.1 drivers/macintosh/therm_windtunnel.c - 1.1 Documentation/sound/alsa/Joystick.txt - 1.1 drivers/macintosh/therm_pm72.h - 1.1 drivers/macintosh/therm_pm72.c - 1.1 drivers/macintosh/therm_adt7467.c - 1.1 drivers/macintosh/Kconfig - 1.1 include/asm-ppc64/hvconsole.h - 1.1 drivers/char/generic_nvram.c - 1.1 drivers/block/paride/Transition-notes - 1.1 include/sound/tea575x-tuner.h - 1.1 net/sched/sch_hfsc.c - 1.1 sound/i2c/other/tea575x-tuner.c - 1.1 sound/synth/emux/emux_hwdep.c - 1.1 arch/ppc64/kernel/hvconsole.c - 1.1 arch/ppc/syslib/open_pic2.c - 1.1 arch/ppc/platforms/pmac_low_i2c.c - 1.1 arch/ppc/kernel/smp-tbsync.c - 1.1 arch/ppc/kernel/cpu_setup_power4.S - 1.1 sound/pci/ac97/ac97_pcm.c - 1.1 arch/parisc/configs/c3000_defconfig - 1.1 arch/parisc/configs/a500_defconfig - 1.1 sound/pci/bt87x.c - 1.1 arch/arm/mach-integrator/integrator_cp.c - 1.1 sound/pci/ice1712/prodigy.c - 1.1 sound/pci/ice1712/prodigy.h - 1.1 CREDITS - 1.4 Documentation/Changes - 1.3 Documentation/DocBook/deviceiobook.tmpl - 1.2 Documentation/SubmittingPatches - 1.3 Documentation/as-iosched.txt - 1.2 Documentation/i386/zero-page.txt - 1.4 Documentation/networking/8139too.txt - 1.2 Documentation/networking/ethertap.txt - 1.2 Documentation/networking/ip-sysctl.txt - 1.4 Documentation/scsi/AM53C974.txt - 1.2 Documentation/scsi/BusLogic.txt - 1.3 Documentation/scsi/scsi_mid_low_api.txt - 1.2 Documentation/sound/alsa/ALSA-Configuration.txt - 1.2 Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl - 1.3 Documentation/sound/alsa/OSS-Emulation.txt - 1.2 Documentation/sound/alsa/SB-Live-mixer.txt - 1.2 Documentation/sysctl/kernel.txt - 1.3 Makefile - 1.6 arch/alpha/defconfig - 1.2 arch/alpha/oprofile/common.c - 1.2 arch/arm/Kconfig - 1.2 arch/arm/common/amba.c - 1.2 arch/arm/configs/footbridge_defconfig - 1.2 arch/arm/configs/iq80321_defconfig - 1.2 arch/arm/kernel/calls.S - 1.3 arch/arm/kernel/process.c - 1.3 arch/arm/kernel/vmlinux.lds.S - 1.2 arch/arm/mach-integrator/Kconfig - 1.2 arch/arm/mach-integrator/Makefile - 1.2 arch/arm/mach-integrator/core.c - 1.2 arch/arm/mach-integrator/cpu.c - 1.3 arch/arm/mach-integrator/impd1.c - 1.2 arch/arm/mach-integrator/integrator_ap.c - 1.3 arch/arm/mach-integrator/leds.c - 1.2 arch/arm/mach-pxa/lubbock.c - 1.3 arch/arm/mach-sa1100/assabet.c - 1.2 arch/arm/mach-sa1100/neponset.c - 1.2 arch/arm26/kernel/process.c - 1.2 arch/h8300/lib/checksum.c - 1.2 arch/h8300/platform/h8300h/ints.c - 1.3 arch/h8300/platform/h8s/ints.c - 1.3 arch/i386/boot/compressed/misc.c - 1.2 arch/i386/boot/setup.S - 1.3 arch/i386/defconfig - 1.4 arch/i386/kernel/acpi/boot.c - 1.4 arch/i386/kernel/cpuid.c - 1.2 arch/i386/kernel/edd.c - 1.2 arch/i386/kernel/i386_ksyms.c - 1.2 arch/i386/kernel/i387.c - 1.2 arch/i386/kernel/mpparse.c - 1.4 arch/i386/kernel/msr.c - 1.2 arch/i386/kernel/process.c - 1.3 arch/i386/kernel/setup.c - 1.4 arch/i386/kernel/smpboot.c - 1.2 arch/i386/kernel/timers/timer_tsc.c - 1.3 arch/i386/mach-default/topology.c - 1.2 arch/i386/mach-es7000/topology.c - 1.2 arch/ia64/defconfig - 1.3 arch/ia64/kernel/acpi.c - 1.4 arch/ia64/kernel/unwind.c - 1.3 arch/ia64/lib/io.c - 1.3 arch/ia64/mm/discontig.c - 1.3 arch/ia64/mm/numa.c - 1.3 arch/ia64/sn/io/hwgfs/hcl.c - 1.3 arch/ia64/sn/io/hwgfs/hcl_util.c - 1.3 arch/ia64/sn/io/io.c - 1.3 arch/ia64/sn/io/machvec/pci_bus_cvlink.c - 1.3 arch/ia64/sn/io/machvec/pci_dma.c - 1.3 arch/ia64/sn/io/platform_init/sgi_io_init.c - 1.3 arch/ia64/sn/io/sn2/klconflib.c - 1.3 arch/ia64/sn/io/sn2/klgraph.c - 1.3 arch/ia64/sn/io/sn2/ml_iograph.c - 1.3 arch/ia64/sn/io/sn2/module.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_ate.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_config.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_dvr.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_error.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_hints.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_intr.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_rrb.c - 1.3 arch/ia64/sn/io/sn2/pcibr/pcibr_slot.c - 1.3 arch/ia64/sn/io/sn2/pciio.c - 1.3 arch/ia64/sn/io/sn2/pic.c - 1.3 arch/ia64/sn/io/sn2/shuberror.c - 1.3 arch/ia64/sn/io/sn2/xbow.c - 1.4 arch/ia64/sn/io/sn2/xtalk.c - 1.3 arch/ia64/sn/io/xswitch.c - 1.3 arch/ia64/sn/kernel/bte.c - 1.3 arch/ia64/sn/kernel/irq.c - 1.3 arch/ia64/sn/kernel/mca.c - 1.3 arch/ia64/sn/kernel/probe.c - 1.3 arch/ia64/sn/kernel/setup.c - 1.3 arch/ia64/sn/kernel/sn2/io.c - 1.2 arch/ia64/sn/kernel/sn2/prominfo_proc.c - 1.2 arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.4 arch/ia64/sn/kernel/sn2/sn_proc_fs.c - 1.3 arch/mips/defconfig-lasat200 - 1.2 arch/parisc/hpux/fs.c - 1.2 arch/parisc/hpux/ioctl.c - 1.2 arch/parisc/hpux/sys_hpux.c - 1.2 arch/parisc/kernel/asm-offsets.c - 1.2 arch/parisc/kernel/drivers.c - 1.3 arch/parisc/kernel/firmware.c - 1.3 arch/parisc/kernel/head.S - 1.3 arch/parisc/kernel/head64.S - 1.3 arch/parisc/kernel/hpmc.S - 1.2 arch/parisc/kernel/init_task.c - 1.2 arch/parisc/kernel/inventory.c - 1.3 arch/parisc/kernel/pacache.S - 1.3 arch/parisc/kernel/parisc_ksyms.c - 1.3 arch/parisc/kernel/pci-dma.c - 1.2 arch/parisc/kernel/pci.c - 1.2 arch/parisc/kernel/pdc_chassis.c - 1.3 arch/parisc/kernel/pdc_cons.c - 1.3 arch/parisc/kernel/perf_asm.S - 1.2 arch/parisc/kernel/perf_images.h - 1.2 arch/parisc/kernel/process.c - 1.3 arch/parisc/kernel/ptrace.c - 1.2 arch/parisc/kernel/signal32.c - 1.3 arch/parisc/kernel/sys32.h - 1.2 arch/parisc/kernel/sys_parisc.c - 1.4 arch/parisc/kernel/syscall_table.S - 1.3 arch/parisc/kernel/unaligned.c - 1.3 arch/parisc/kernel/vmlinux.lds.S - 1.2 arch/parisc/lib/lusercopy.S - 1.3 arch/parisc/math-emu/cnv_float.h - 1.2 arch/parisc/math-emu/dbl_float.h - 1.2 arch/parisc/math-emu/decode_exc.c - 1.2 arch/parisc/math-emu/denormal.c - 1.2 arch/parisc/math-emu/dfadd.c - 1.2 arch/parisc/math-emu/dfcmp.c - 1.2 arch/parisc/math-emu/dfdiv.c - 1.2 arch/parisc/math-emu/dfmpy.c - 1.2 arch/parisc/math-emu/dfrem.c - 1.2 arch/parisc/math-emu/dfsqrt.c - 1.2 arch/parisc/math-emu/dfsub.c - 1.2 arch/parisc/math-emu/driver.c - 1.2 arch/parisc/math-emu/fcnvff.c - 1.2 arch/parisc/math-emu/fcnvfu.c - 1.2 arch/parisc/math-emu/fcnvfut.c - 1.2 arch/parisc/math-emu/fcnvfx.c - 1.2 arch/parisc/math-emu/fcnvfxt.c - 1.2 arch/parisc/math-emu/fcnvuf.c - 1.2 arch/parisc/math-emu/fcnvxf.c - 1.2 arch/parisc/math-emu/float.h - 1.2 arch/parisc/math-emu/fmpyfadd.c - 1.2 arch/parisc/math-emu/fpbits.h - 1.2 arch/parisc/math-emu/fpu.h - 1.2 arch/parisc/math-emu/fpudispatch.c - 1.2 arch/parisc/math-emu/frnd.c - 1.2 arch/parisc/math-emu/hppa.h - 1.2 arch/parisc/math-emu/math-emu.h - 1.2 arch/parisc/math-emu/sfadd.c - 1.2 arch/parisc/math-emu/sfcmp.c - 1.2 arch/parisc/math-emu/sfdiv.c - 1.2 arch/parisc/math-emu/sfmpy.c - 1.2 arch/parisc/math-emu/sfrem.c - 1.2 arch/parisc/math-emu/sfsqrt.c - 1.2 arch/parisc/math-emu/sfsub.c - 1.2 arch/parisc/math-emu/sgl_float.h - 1.2 arch/parisc/mm/kmap.c - 1.2 arch/ppc/Kconfig - 1.3 arch/ppc/configs/common_defconfig - 1.2 arch/ppc/configs/pmac_defconfig - 1.2 arch/ppc/defconfig - 1.2 arch/ppc/kernel/Makefile - 1.3 arch/ppc/kernel/cpu_setup_6xx.S - 1.2 arch/ppc/kernel/head.S - 1.2 arch/ppc/kernel/idle_power4.S - 1.2 arch/ppc/kernel/misc.S - 1.3 arch/ppc/kernel/pci.c - 1.2 arch/ppc/kernel/ppc_ksyms.c - 1.4 arch/ppc/kernel/setup.c - 1.3 arch/ppc/kernel/smp.c - 1.2 arch/ppc/mm/hashtable.S - 1.2 arch/ppc/mm/init.c - 1.2 arch/ppc/mm/pgtable.c - 1.2 arch/ppc/mm/ppc_mmu.c - 1.2 arch/ppc/mm/tlb.c - 1.2 arch/ppc/platforms/Makefile - 1.2 arch/ppc/platforms/mcpn765_setup.c - 1.2 arch/ppc/platforms/pmac_backlight.c - 1.2 arch/ppc/platforms/pmac_cpufreq.c - 1.2 arch/ppc/platforms/pmac_feature.c - 1.2 arch/ppc/platforms/pmac_nvram.c - 1.2 arch/ppc/platforms/pmac_pci.c - 1.2 arch/ppc/platforms/pmac_pic.c - 1.2 arch/ppc/platforms/pmac_setup.c - 1.2 arch/ppc/platforms/pmac_smp.c - 1.2 arch/ppc/platforms/pmac_time.c - 1.2 arch/ppc/platforms/sandpoint.c - 1.2 arch/ppc/syslib/Makefile - 1.2 arch/ppc/syslib/gen550_dbg.c - 1.2 arch/ppc/syslib/gen550_kgdb.c - 1.2 arch/ppc/syslib/of_device.c - 1.2 arch/ppc/syslib/open_pic.c - 1.2 arch/ppc/syslib/prom.c - 1.2 arch/ppc/syslib/prom_init.c - 1.2 arch/ppc64/Kconfig - 1.3 arch/ppc64/kernel/Makefile - 1.3 arch/ppc64/kernel/head.S - 1.4 arch/ppc64/kernel/idle.c - 1.3 arch/ppc64/kernel/pSeries_hvCall.S - 1.3 arch/ppc64/kernel/pSeries_lpar.c - 1.3 arch/ppc64/kernel/pSeries_pci.c - 1.3 arch/ppc64/kernel/proc_ppc64.c - 1.4 arch/ppc64/kernel/prom.c - 1.4 arch/ppc64/kernel/rtas-proc.c - 1.4 arch/ppc64/kernel/setup.c - 1.4 arch/ppc64/kernel/smp.c - 1.3 arch/ppc64/kernel/stab.c - 1.3 arch/ppc64/kernel/time.c - 1.3 arch/ppc64/mm/numa.c - 1.3 arch/ppc64/xmon/start.c - 1.3 arch/ppc64/xmon/xmon.c - 1.3 arch/sparc/kernel/Makefile - 1.2 arch/sparc/kernel/sparc_ksyms.c - 1.2 arch/sparc64/defconfig - 1.4 arch/sparc64/kernel/head.S - 1.4 arch/um/kernel/um_arch.c - 1.2 arch/x86_64/defconfig - 1.4 arch/x86_64/ia32/sys_ia32.c - 1.4 arch/x86_64/kernel/aperture.c - 1.2 arch/x86_64/kernel/entry.S - 1.3 arch/x86_64/kernel/nmi.c - 1.2 arch/x86_64/kernel/pci-gart.c - 1.4 arch/x86_64/kernel/suspend_asm.S - 1.2 arch/x86_64/kernel/sys_x86_64.c - 1.3 arch/x86_64/lib/csum-partial.c - 1.2 arch/x86_64/mm/fault.c - 1.4 arch/x86_64/mm/init.c - 1.2 crypto/sha256.c - 1.3 crypto/sha512.c - 1.2 drivers/Kconfig - 1.3 drivers/acpi/ac.c - 1.3 drivers/acpi/asus_acpi.c - 1.3 drivers/acpi/battery.c - 1.3 drivers/acpi/bus.c - 1.3 drivers/acpi/button.c - 1.3 drivers/acpi/ec.c - 1.3 drivers/acpi/fan.c - 1.3 drivers/acpi/osl.c - 1.4 drivers/acpi/pci_link.c - 1.3 drivers/acpi/pci_root.c - 1.3 drivers/acpi/power.c - 1.3 drivers/acpi/processor.c - 1.3 drivers/acpi/scan.c - 1.3 drivers/acpi/thermal.c - 1.3 drivers/atm/atmtcp.c - 1.2 drivers/atm/eni.c - 1.2 drivers/atm/fore200e.c - 1.2 drivers/atm/he.c - 1.3 drivers/atm/idt77105.c - 1.2 drivers/atm/idt77252.c - 1.2 drivers/atm/iphase.c - 1.2 drivers/atm/suni.c - 1.2 drivers/atm/uPD98402.c - 1.2 drivers/atm/zatm.c - 1.2 drivers/base/Makefile - 1.3 drivers/base/memblk.c - 1.2 drivers/block/cciss.c - 1.2 drivers/block/floppy.c - 1.4 drivers/block/genhd.c - 1.3 drivers/block/paride/bpck6.c - 1.2 drivers/block/paride/frpw.c - 1.2 drivers/block/paride/paride.c - 1.2 drivers/block/paride/paride.h - 1.2 drivers/block/paride/pd.c - 1.2 drivers/block/ps2esdi.c - 1.2 drivers/block/scsi_ioctl.c - 1.2 drivers/block/swim3.c - 1.2 drivers/cdrom/cdrom.c - 1.3 drivers/char/Kconfig - 1.3 drivers/char/Makefile - 1.3 drivers/char/drm/radeon_state.c - 1.2 drivers/char/dz.c - 1.2 drivers/char/hvc_console.c - 1.2 drivers/char/istallion.c - 1.2 drivers/char/keyboard.c - 1.4 drivers/char/moxa.c - 1.2 drivers/char/mxser.c - 1.2 drivers/char/selection.c - 1.2 drivers/char/sn_serial.c - 1.3 drivers/char/sonypi.h - 1.2 drivers/char/specialix.c - 1.2 drivers/char/tty_io.c - 1.3 drivers/char/vt.c - 1.3 drivers/char/vt_ioctl.c - 1.3 drivers/i2c/busses/i2c-keywest.c - 1.3 drivers/i2c/busses/i2c-keywest.h - 1.2 drivers/i2c/chips/it87.c - 1.4 drivers/ide/Kconfig - 1.5 drivers/ide/ide-cd.c - 1.4 drivers/ide/ide-disk.c - 1.3 drivers/ide/ide-dma.c - 1.3 drivers/ide/ide-floppy.c - 1.2 drivers/ide/ide-iops.c - 1.3 drivers/ide/ide-taskfile.c - 1.3 drivers/ide/ide-tcq.c - 1.2 drivers/ide/ide.c - 1.5 drivers/ide/pci/sc1200.c - 1.2 drivers/ide/pci/triflex.c - 1.2 drivers/ide/pci/triflex.h - 1.2 drivers/ide/ppc/pmac.c - 1.2 drivers/ieee1394/highlevel.c - 1.5 drivers/input/evdev.c - 1.3 drivers/input/joystick/db9.c - 1.2 drivers/input/joystick/gamecon.c - 1.2 drivers/input/joystick/turbografx.c - 1.2 drivers/input/serio/parkbd.c - 1.2 drivers/isdn/hardware/eicon/divasmain.c - 1.2 drivers/isdn/hisax/hisax_hfcpci.c - 1.2 drivers/macintosh/Makefile - 1.2 drivers/macintosh/adb.c - 1.2 drivers/macintosh/adbhid.c - 1.3 drivers/macintosh/macio_asic.c - 1.2 drivers/macintosh/mediabay.c - 1.2 drivers/macintosh/via-pmu.c - 1.2 drivers/md/Makefile - 1.3 drivers/md/linear.c - 1.3 drivers/md/md.c - 1.3 drivers/md/multipath.c - 1.3 drivers/md/raid0.c - 1.3 drivers/md/raid1.c - 1.3 drivers/md/raid5.c - 1.4 drivers/media/dvb/frontends/ves1820.c - 1.3 drivers/media/video/Kconfig - 1.3 drivers/media/video/bw-qcam.c - 1.2 drivers/media/video/dpc7146.c - 1.2 drivers/media/video/hexium_gemini.c - 1.2 drivers/media/video/hexium_orion.c - 1.2 drivers/media/video/meye.c - 1.2 drivers/media/video/meye.h - 1.2 drivers/media/video/msp3400.c - 1.3 drivers/media/video/mxb.c - 1.2 drivers/media/video/saa7134/saa7134-cards.c - 1.3 drivers/media/video/saa7134/saa7134-tvaudio.c - 1.3 drivers/media/video/saa7134/saa7134.h - 1.3 drivers/media/video/tda9887.c - 1.3 drivers/media/video/tuner.c - 1.3 drivers/media/video/tvaudio.c - 1.3 drivers/media/video/tvmixer.c - 1.3 drivers/message/fusion/mptbase.c - 1.3 drivers/message/fusion/mptbase.h - 1.4 drivers/message/fusion/mptscsih.c - 1.4 drivers/message/fusion/mptscsih.h - 1.3 drivers/mtd/chips/cfi_cmdset_0001.c - 1.2 drivers/mtd/chips/cfi_cmdset_0020.c - 1.2 drivers/mtd/maps/elan-104nc.c - 1.2 drivers/mtd/maps/sbc_gxx.c - 1.2 drivers/net/3c501.c - 1.2 drivers/net/3c501.h - 1.2 drivers/net/3c503.c - 1.2 drivers/net/3c505.c - 1.2 drivers/net/3c507.c - 1.2 drivers/net/3c515.c - 1.2 drivers/net/3c523.c - 1.2 drivers/net/3c527.c - 1.3 drivers/net/8139too.c - 1.3 drivers/net/82596.c - 1.2 drivers/net/Kconfig - 1.3 drivers/net/Makefile - 1.3 drivers/net/Space.c - 1.3 drivers/net/a2065.c - 1.2 drivers/net/ac3200.c - 1.2 drivers/net/acenic.c - 1.2 drivers/net/apne.c - 1.2 drivers/net/appletalk/ltpc.c - 1.2 drivers/net/ariadne.c - 1.2 drivers/net/arm/am79c961a.c - 1.2 drivers/net/arm/ether00.c - 1.2 drivers/net/arm/ether1.c - 1.2 drivers/net/arm/ether3.c - 1.2 drivers/net/arm/etherh.c - 1.2 drivers/net/at1700.c - 1.2 drivers/net/atari_bionet.c - 1.2 drivers/net/atari_pamsnet.c - 1.2 drivers/net/atarilance.c - 1.2 drivers/net/atp.c - 1.2 drivers/net/au1000_eth.c - 1.2 drivers/net/bagetlance.c - 1.2 drivers/net/bmac.c - 1.2 drivers/net/cs89x0.c - 1.3 drivers/net/de600.c - 1.2 drivers/net/de600.h - 1.2 drivers/net/de620.c - 1.2 drivers/net/declance.c - 1.2 drivers/net/defxx.c - 1.2 drivers/net/depca.c - 1.2 drivers/net/dl2k.c - 1.2 drivers/net/dummy.c - 1.3 drivers/net/e100/e100_main.c - 1.3 drivers/net/e1000/e1000.h - 1.2 drivers/net/e1000/e1000_ethtool.c - 1.2 drivers/net/e1000/e1000_hw.c - 1.2 drivers/net/e1000/e1000_hw.h - 1.2 drivers/net/e1000/e1000_main.c - 1.2 drivers/net/e1000/e1000_osdep.h - 1.2 drivers/net/e1000/e1000_param.c - 1.2 drivers/net/e2100.c - 1.2 drivers/net/eepro.c - 1.2 drivers/net/eexpress.c - 1.2 drivers/net/eql.c - 1.2 drivers/net/es3210.c - 1.2 drivers/net/eth16i.c - 1.2 drivers/net/ethertap.c - 1.2 drivers/net/ewrk3.c - 1.2 drivers/net/fc/iph5526.c - 1.2 drivers/net/fc/iph5526_scsi.h - 1.2 drivers/net/fealnx.c - 1.2 drivers/net/fmv18x.c - 1.2 drivers/net/gt96100eth.c - 1.2 drivers/net/hamradio/6pack.c - 1.2 drivers/net/hamradio/baycom_epp.c - 1.2 drivers/net/hamradio/baycom_par.c - 1.2 drivers/net/hamradio/bpqether.c - 1.3 drivers/net/hamradio/hdlcdrv.c - 1.2 drivers/net/hamradio/mkiss.c - 1.2 drivers/net/hamradio/mkiss.h - 1.2 drivers/net/hamradio/scc.c - 1.3 drivers/net/hamradio/yam.c - 1.2 drivers/net/hp-plus.c - 1.2 drivers/net/hp.c - 1.2 drivers/net/hp100.c - 1.2 drivers/net/hplance.c - 1.2 drivers/net/hydra.c - 1.2 drivers/net/jazzsonic.c - 1.2 drivers/net/lance.c - 1.2 drivers/net/lasi_82596.c - 1.2 drivers/net/lne390.c - 1.2 drivers/net/mac8390.c - 1.2 drivers/net/mac89x0.c - 1.2 drivers/net/mace.c - 1.2 drivers/net/macmace.c - 1.2 drivers/net/macsonic.c - 1.2 drivers/net/mvme147.c - 1.2 drivers/net/ne.c - 1.2 drivers/net/ne2.c - 1.2 drivers/net/ne2k-pci.c - 1.3 drivers/net/ne2k_cbus.c - 1.2 drivers/net/ne2k_cbus.h - 1.2 drivers/net/ni5010.c - 1.2 drivers/net/ni52.c - 1.2 drivers/net/ni65.c - 1.2 drivers/net/ns83820.c - 1.2 drivers/net/oaknet.c - 1.2 drivers/net/pci-skeleton.c - 1.2 drivers/net/pcmcia/3c574_cs.c - 1.4 drivers/net/pcmcia/3c589_cs.c - 1.3 drivers/net/pcmcia/fmvj18x_cs.c - 1.3 drivers/net/pcmcia/nmclan_cs.c - 1.3 drivers/net/pcmcia/smc91c92_cs.c - 1.3 drivers/net/pcmcia/xirc2ps_cs.c - 1.3 drivers/net/plip.c - 1.2 drivers/net/ppp_deflate.c - 1.2 drivers/net/pppoe.c - 1.4 drivers/net/saa9730.c - 1.2 drivers/net/sb1250-mac.c - 1.2 drivers/net/seeq8005.c - 1.2 drivers/net/sgiseeq.c - 1.2 drivers/net/shaper.c - 1.2 drivers/net/sk98lin/h/lm80.h - 1.2 drivers/net/sk98lin/h/skaddr.h - 1.2 drivers/net/sk98lin/h/skcsum.h - 1.3 drivers/net/sk98lin/h/skdebug.h - 1.2 drivers/net/sk98lin/h/skdrv1st.h - 1.3 drivers/net/sk98lin/h/skdrv2nd.h - 1.3 drivers/net/sk98lin/h/skerror.h - 1.2 drivers/net/sk98lin/h/skgedrv.h - 1.2 drivers/net/sk98lin/h/skgehw.h - 1.3 drivers/net/sk98lin/h/skgehwt.h - 1.3 drivers/net/sk98lin/h/skgei2c.h - 1.3 drivers/net/sk98lin/h/skgeinit.h - 1.3 drivers/net/sk98lin/h/skgepnm2.h - 1.2 drivers/net/sk98lin/h/skgepnmi.h - 1.3 drivers/net/sk98lin/h/skgesirq.h - 1.2 drivers/net/sk98lin/h/ski2c.h - 1.3 drivers/net/sk98lin/h/skqueue.h - 1.3 drivers/net/sk98lin/h/skrlmt.h - 1.2 drivers/net/sk98lin/h/sktimer.h - 1.3 drivers/net/sk98lin/h/sktypes.h - 1.3 drivers/net/sk98lin/h/skversion.h - 1.4 drivers/net/sk98lin/h/skvpd.h - 1.2 drivers/net/sk98lin/h/xmac_ii.h - 1.3 drivers/net/sk98lin/skaddr.c - 1.2 drivers/net/sk98lin/skcsum.c - 1.3 drivers/net/sk98lin/skdim.c - 1.3 drivers/net/sk98lin/skge.c - 1.4 drivers/net/sk98lin/skgehwt.c - 1.3 drivers/net/sk98lin/skgeinit.c - 1.3 drivers/net/sk98lin/skgemib.c - 1.3 drivers/net/sk98lin/skgepnmi.c - 1.3 drivers/net/sk98lin/skgesirq.c - 1.3 drivers/net/sk98lin/ski2c.c - 1.3 drivers/net/sk98lin/sklm80.c - 1.3 drivers/net/sk98lin/skproc.c - 1.3 drivers/net/sk98lin/skqueue.c - 1.3 drivers/net/sk98lin/skrlmt.c - 1.2 drivers/net/sk98lin/sktimer.c - 1.3 drivers/net/sk98lin/skvpd.c - 1.2 drivers/net/sk98lin/skxmac2.c - 1.3 drivers/net/sk_g16.c - 1.2 drivers/net/sk_mca.c - 1.2 drivers/net/sk_mca.h - 1.2 drivers/net/smc-ultra.c - 1.2 drivers/net/smc-ultra32.c - 1.2 drivers/net/smc9194.c - 1.2 drivers/net/stnic.c - 1.3 drivers/net/sun3_82586.c - 1.2 drivers/net/sun3lance.c - 1.2 drivers/net/sundance.c - 1.2 drivers/net/sungem.c - 1.2 drivers/net/sungem.h - 1.2 drivers/net/sungem_phy.c - 1.2 drivers/net/tc35815.c - 1.2 drivers/net/tg3.c - 1.4 drivers/net/tokenring/3c359.c - 1.2 drivers/net/tokenring/abyss.c - 1.2 drivers/net/tokenring/madgemc.c - 1.2 drivers/net/tokenring/proteon.c - 1.2 drivers/net/tokenring/skisa.c - 1.2 drivers/net/tokenring/smctr.c - 1.3 drivers/net/tokenring/tmspci.c - 1.2 drivers/net/tulip/Kconfig - 1.2 drivers/net/tulip/de2104x.c - 1.2 drivers/net/tulip/dmfe.c - 1.2 drivers/net/tulip/interrupt.c - 1.2 drivers/net/tulip/tulip.h - 1.2 drivers/net/tulip/tulip_core.c - 1.2 drivers/net/tulip/winbond-840.c - 1.2 drivers/net/tulip/xircom_tulip_cb.c - 1.2 drivers/net/tun.c - 1.2 drivers/net/typhoon-firmware.h - 1.2 drivers/net/typhoon.c - 1.3 drivers/net/typhoon.h - 1.2 drivers/net/wan/lmc/lmc_debug.h - 1.2 drivers/net/wan/lmc/lmc_main.c - 1.2 drivers/net/wan/lmc/lmc_var.h - 1.2 drivers/net/wan/x25_asy.c - 1.2 drivers/net/wd.c - 1.2 drivers/net/wireless/Kconfig - 1.3 drivers/net/wireless/Makefile - 1.2 drivers/net/wireless/airo.c - 1.3 drivers/net/wireless/arlan-main.c - 1.2 drivers/net/wireless/arlan.h - 1.2 drivers/net/wireless/atmel.c - 1.4 drivers/net/wireless/atmel_cs.c - 1.3 drivers/net/wireless/strip.c - 1.2 drivers/net/wireless/wavelan.c - 1.2 drivers/net/wireless/wavelan.p.h - 1.2 drivers/net/wireless/wavelan_cs.c - 1.3 drivers/net/wireless/wavelan_cs.p.h - 1.2 drivers/net/yellowfin.c - 1.2 drivers/net/znet.c - 1.2 drivers/net/zorro8390.c - 1.2 drivers/oprofile/cpu_buffer.c - 1.2 drivers/parisc/Kconfig - 1.3 drivers/parisc/ccio-dma.c - 1.3 drivers/parisc/dino.c - 1.3 drivers/parisc/eisa_eeprom.c - 1.2 drivers/parisc/iosapic.c - 1.2 drivers/parisc/iosapic_private.h - 1.2 drivers/parisc/lba_pci.c - 1.2 drivers/parisc/led.c - 1.3 drivers/parisc/sba_iommu.c - 1.2 drivers/parisc/superio.c - 1.3 drivers/parport/daisy.c - 1.2 drivers/parport/parport_gsc.c - 1.2 drivers/parport/parport_pc.c - 1.2 drivers/parport/share.c - 1.2 drivers/pci/probe.c - 1.5 drivers/pcmcia/bulkmem.c - 1.2 drivers/pnp/pnpbios/core.c - 1.2 drivers/scsi/53c700.h - 1.2 drivers/scsi/AM53C974.c - 1.2 drivers/scsi/AM53C974.h - 1.2 drivers/scsi/BusLogic.c - 1.3 drivers/scsi/BusLogic.h - 1.2 drivers/scsi/FlashPoint.c - 1.2 drivers/scsi/Kconfig - 1.4 drivers/scsi/Makefile - 1.3 drivers/scsi/advansys.c - 1.2 drivers/scsi/aha152x.c - 1.4 drivers/scsi/aha152x.h - 1.2 drivers/scsi/aha1542.c - 1.3 drivers/scsi/atp870u.c - 1.3 drivers/scsi/gdth.c - 1.2 drivers/scsi/imm.c - 1.2 drivers/scsi/imm.h - 1.2 drivers/scsi/libata-core.c - 1.3 drivers/scsi/mac53c94.c - 1.2 drivers/scsi/mac_NCR5380.c - 1.2 drivers/scsi/mesh.c - 1.2 drivers/scsi/osst.c - 1.3 drivers/scsi/pcmcia/aha152x_stub.c - 1.3 drivers/scsi/ppa.c - 1.2 drivers/scsi/ppa.h - 1.2 drivers/scsi/qlogicfc.c - 1.2 drivers/scsi/qlogicfc.h - 1.2 drivers/scsi/qlogicfc_asm.c - 1.2 drivers/scsi/scsi_lib.c - 1.2 drivers/scsi/sd.c - 1.2 drivers/scsi/sg.c - 1.3 drivers/scsi/sr.c - 1.3 drivers/scsi/st.c - 1.3 drivers/serial/mux.c - 1.2 drivers/serial/pmac_zilog.c - 1.2 drivers/usb/class/audio.c - 1.2 drivers/usb/gadget/ether.c - 1.4 drivers/video/Kconfig - 1.3 drivers/video/Makefile - 1.3 drivers/video/cfbimgblt.c - 1.2 drivers/video/console/Makefile - 1.3 drivers/video/console/fbcon.c - 1.3 drivers/video/console/sticore.c - 1.2 drivers/video/fbcmap.c - 1.2 drivers/video/fbmem.c - 1.3 drivers/video/i810/i810_accel.c - 1.2 drivers/video/logo/Makefile - 1.3 drivers/video/neofb.c - 1.2 drivers/video/riva/fbdev.c - 1.2 drivers/video/sis/300vtbl.h - 1.2 drivers/video/sis/310vtbl.h - 1.2 drivers/video/sis/init.c - 1.2 drivers/video/sis/init.h - 1.2 drivers/video/sis/init301.c - 1.3 drivers/video/sis/init301.h - 1.2 drivers/video/sis/initdef.h - 1.2 drivers/video/sis/oem300.h - 1.2 drivers/video/sis/oem310.h - 1.2 drivers/video/sis/osdef.h - 1.2 drivers/video/sis/sis_accel.c - 1.2 drivers/video/sis/sis_accel.h - 1.2 drivers/video/sis/sis_main.c - 1.2 drivers/video/sis/sis_main.h - 1.2 drivers/video/sis/vgatypes.h - 1.2 drivers/video/sis/vstruct.h - 1.2 drivers/video/stifb.c - 1.2 drivers/video/vga16fb.c - 1.2 drivers/video/vgastate.c - 1.2 fs/Makefile - 1.2 fs/binfmt_elf.c - 1.4 fs/bio.c - 1.3 fs/compat_ioctl.c - 1.5 fs/dcache.c - 1.3 fs/eventpoll.c - 1.3 fs/ext2/namei.c - 1.2 fs/ext2/xattr.c - 1.2 fs/ext3/namei.c - 1.2 fs/ext3/xattr.c - 1.2 fs/freevxfs/vxfs.h - 1.2 fs/freevxfs/vxfs_bmap.c - 1.2 fs/freevxfs/vxfs_dir.h - 1.2 fs/freevxfs/vxfs_extern.h - 1.2 fs/freevxfs/vxfs_fshead.c - 1.2 fs/freevxfs/vxfs_fshead.h - 1.2 fs/freevxfs/vxfs_immed.c - 1.2 fs/freevxfs/vxfs_inode.c - 1.2 fs/freevxfs/vxfs_inode.h - 1.2 fs/freevxfs/vxfs_lookup.c - 1.2 fs/freevxfs/vxfs_olt.c - 1.2 fs/freevxfs/vxfs_olt.h - 1.2 fs/freevxfs/vxfs_subr.c - 1.2 fs/freevxfs/vxfs_super.c - 1.3 fs/fs-writeback.c - 1.3 fs/hfs/file_hdr.c - 1.2 fs/hugetlbfs/inode.c - 1.3 fs/intermezzo/cache.c - 1.2 fs/intermezzo/intermezzo_fs.h - 1.3 fs/intermezzo/presto.c - 1.3 fs/intermezzo/sysctl.c - 1.2 fs/libfs.c - 1.3 fs/namei.c - 1.2 fs/namespace.c - 1.2 fs/ncpfs/dir.c - 1.2 fs/ncpfs/inode.c - 1.2 fs/ncpfs/ncplib_kernel.h - 1.2 fs/ntfs/ntfs.h - 1.2 fs/partitions/check.c - 1.2 fs/proc/base.c - 1.4 fs/proc/proc_misc.c - 1.4 fs/readdir.c - 1.2 fs/reiserfs/prints.c - 1.2 fs/ufs/super.c - 1.2 fs/xattr.c - 1.2 include/asm-alpha/byteorder.h - 1.2 include/asm-alpha/io.h - 1.2 include/asm-alpha/mmzone.h - 1.2 include/asm-alpha/pci.h - 1.2 include/asm-alpha/topology.h - 1.3 include/asm-arm/arch-ebsa110/io.h - 1.2 include/asm-arm/arch-integrator/irqs.h - 1.2 include/asm-arm/arch-integrator/system.h - 1.2 include/asm-arm/arch-integrator/time.h - 1.2 include/asm-arm/current.h - 1.2 include/asm-arm/hardware/amba.h - 1.2 include/asm-arm/hardware/sa1111.h - 1.2 include/asm-arm/io.h - 1.2 include/asm-arm/pci.h - 1.2 include/asm-arm/semaphore.h - 1.2 include/asm-arm/thread_info.h - 1.3 include/asm-arm/unistd.h - 1.3 include/asm-arm26/current.h - 1.2 include/asm-arm26/io.h - 1.2 include/asm-arm26/pci.h - 1.2 include/asm-arm26/thread_info.h - 1.2 include/asm-cris/io.h - 1.2 include/asm-generic/pci.h - 1.2 include/asm-generic/topology.h - 1.2 include/asm-h8300/bitops.h - 1.3 include/asm-h8300/io.h - 1.2 include/asm-h8300/pci.h - 1.2 include/asm-i386/acpi.h - 1.3 include/asm-i386/apic.h - 1.2 include/asm-i386/edd.h - 1.2 include/asm-i386/hw_irq.h - 1.3 include/asm-i386/io.h - 1.2 include/asm-i386/memblk.h - 1.2 include/asm-i386/mmzone.h - 1.2 include/asm-i386/pci.h - 1.2 include/asm-i386/setup.h - 1.3 include/asm-i386/string.h - 1.3 include/asm-i386/topology.h - 1.2 include/asm-i386/unistd.h - 1.2 include/asm-ia64/io.h - 1.2 include/asm-ia64/machvec.h - 1.3 include/asm-ia64/machvec_init.h - 1.2 include/asm-ia64/machvec_sn2.h - 1.3 include/asm-ia64/mmzone.h - 1.3 include/asm-ia64/numa.h - 1.5 include/asm-ia64/pci.h - 1.2 include/asm-ia64/sn/addrs.h - 1.3 include/asm-ia64/sn/alenlist.h - 1.3 include/asm-ia64/sn/arch.h - 1.3 include/asm-ia64/sn/bte.h - 1.3 include/asm-ia64/sn/clksupport.h - 1.3 include/asm-ia64/sn/driver.h - 1.3 include/asm-ia64/sn/hcl.h - 1.3 include/asm-ia64/sn/hcl_util.h - 1.3 include/asm-ia64/sn/hwgfs.h - 1.3 include/asm-ia64/sn/iograph.h - 1.3 include/asm-ia64/sn/klconfig.h - 1.3 include/asm-ia64/sn/kldir.h - 1.2 include/asm-ia64/sn/module.h - 1.3 include/asm-ia64/sn/nodepda.h - 1.3 include/asm-ia64/sn/pci/bridge.h - 1.3 include/asm-ia64/sn/pci/pci_bus_cvlink.h - 1.3 include/asm-ia64/sn/pci/pcibr.h - 1.3 include/asm-ia64/sn/pci/pcibr_private.h - 1.3 include/asm-ia64/sn/pci/pciio.h - 1.3 include/asm-ia64/sn/pci/pciio_private.h - 1.3 include/asm-ia64/sn/pci/pic.h - 1.3 include/asm-ia64/sn/pda.h - 1.3 include/asm-ia64/sn/pio.h - 1.3 include/asm-ia64/sn/sgi.h - 1.3 include/asm-ia64/sn/sn2/arch.h - 1.3 include/asm-ia64/sn/sn2/intr.h - 1.3 include/asm-ia64/sn/sn2/io.h - 1.2 include/asm-ia64/sn/sn2/shubio.h - 1.3 include/asm-ia64/sn/sn2/sn_private.h - 1.3 include/asm-ia64/sn/sn_cpuid.h - 1.2 include/asm-ia64/sn/sn_private.h - 1.3 include/asm-ia64/sn/types.h - 1.2 include/asm-ia64/sn/vector.h - 1.3 include/asm-ia64/sn/xtalk/xbow.h - 1.3 include/asm-ia64/sn/xtalk/xtalk.h - 1.3 include/asm-ia64/sn/xtalk/xwidget.h - 1.3 include/asm-ia64/topology.h - 1.2 include/asm-m68k/io.h - 1.3 include/asm-m68k/pci.h - 1.3 include/asm-m68k/virtconvert.h - 1.3 include/asm-m68knommu/io.h - 1.2 include/asm-m68knommu/pci.h - 1.2 include/asm-mips/io.h - 1.2 include/asm-mips/mmzone.h - 1.2 include/asm-mips/pci.h - 1.3 include/asm-parisc/cache.h - 1.2 include/asm-parisc/compat.h - 1.2 include/asm-parisc/io.h - 1.2 include/asm-parisc/pci.h - 1.2 include/asm-parisc/pdc.h - 1.2 include/asm-parisc/posix_types.h - 1.2 include/asm-parisc/rt_sigframe.h - 1.2 include/asm-parisc/siginfo.h - 1.2 include/asm-parisc/superio.h - 1.2 include/asm-parisc/uaccess.h - 1.3 include/asm-ppc/delay.h - 1.2 include/asm-ppc/io.h - 1.2 include/asm-ppc/keylargo.h - 1.2 include/asm-ppc/kgdb.h - 1.2 include/asm-ppc/machdep.h - 1.2 include/asm-ppc/macio.h - 1.2 include/asm-ppc/nvram.h - 1.2 include/asm-ppc/open_pic.h - 1.2 include/asm-ppc/param.h - 1.2 include/asm-ppc/pci.h - 1.3 include/asm-ppc/pgtable.h - 1.3 include/asm-ppc/pmac_feature.h - 1.2 include/asm-ppc/reg.h - 1.2 include/asm-ppc/uninorth.h - 1.2 include/asm-ppc64/eeh.h - 1.2 include/asm-ppc64/hvcall.h - 1.4 include/asm-ppc64/io.h - 1.3 include/asm-ppc64/mmzone.h - 1.2 include/asm-ppc64/paca.h - 1.4 include/asm-ppc64/pci.h - 1.3 include/asm-ppc64/topology.h - 1.3 include/asm-s390/io.h - 1.2 include/asm-sh/io.h - 1.3 include/asm-sh/pci.h - 1.3 include/asm-sparc/btfixup.h - 1.2 include/asm-sparc/io.h - 1.2 include/asm-sparc/pci.h - 1.2 include/asm-sparc/pgtable.h - 1.2 include/asm-sparc64/io.h - 1.3 include/asm-sparc64/pci.h - 1.2 include/asm-um/pci.h - 1.2 include/asm-v850/io.h - 1.2 include/asm-v850/pci.h - 1.2 include/asm-x86_64/apic.h - 1.2 include/asm-x86_64/hw_irq.h - 1.4 include/asm-x86_64/io.h - 1.3 include/asm-x86_64/pci.h - 1.2 include/asm-x86_64/topology.h - 1.2 include/linux/bio.h - 1.4 include/linux/bitmap.h - 1.3 include/linux/blkdev.h - 1.4 include/linux/cdrom.h - 1.3 include/linux/console.h - 1.3 include/linux/cpu.h - 1.3 include/linux/cpumask.h - 1.4 include/linux/efi.h - 1.4 include/linux/elevator.h - 1.2 include/linux/fb.h - 1.2 include/linux/fsfilter.h - 1.2 include/linux/hugetlb.h - 1.3 include/linux/ide.h - 1.5 include/linux/if_vlan.h - 1.2 include/linux/in6.h - 1.2 include/linux/inetdevice.h - 1.2 include/linux/init_task.h - 1.2 include/linux/input.h - 1.4 include/linux/ioport.h - 1.2 include/linux/irq_cpustat.h - 1.2 include/linux/kernel.h - 1.4 include/linux/memblk.h - 1.2 include/linux/mm.h - 1.4 include/linux/mmzone.h - 1.4 include/linux/netdevice.h - 1.4 include/linux/netfilter_ipv4/ip_conntrack_core.h - 1.2 include/linux/parport.h - 1.2 include/linux/parport_pc.h - 1.2 include/linux/pci_ids.h - 1.4 include/linux/percpu.h - 1.2 include/linux/pkt_sched.h - 1.2 include/linux/raid/md_k.h - 1.3 include/linux/reiserfs_fs.h - 1.3 include/linux/scc.h - 1.2 include/linux/sched.h - 1.4 include/linux/sctp.h - 1.3 include/linux/selection.h - 1.2 include/linux/string.h - 1.2 include/linux/suspend.h - 1.2 include/linux/sysctl.h - 1.4 include/linux/tcp.h - 1.3 include/linux/time.h - 1.2 include/net/arp.h - 1.2 include/net/irda/irlmp_frame.h - 1.2 include/net/irda/timer.h - 1.3 include/net/pkt_sched.h - 1.2 include/net/sctp/structs.h - 1.3 include/net/tcp.h - 1.3 include/pcmcia/mem_op.h - 1.2 include/sound/ac97_codec.h - 1.2 include/sound/asequencer.h - 1.2 include/sound/asound.h - 1.2 include/sound/asound_fm.h - 1.2 include/sound/core.h - 1.3 include/sound/cs46xx.h - 1.2 include/sound/emu10k1.h - 1.2 include/sound/emu8000.h - 1.2 include/sound/emux_synth.h - 1.2 include/sound/hdsp.h - 1.2 include/sound/i2c.h - 1.2 include/sound/info.h - 1.2 include/sound/initval.h - 1.2 include/sound/minors.h - 1.2 include/sound/pcm.h - 1.2 include/sound/pcm_oss.h - 1.2 include/sound/sb.h - 1.2 include/sound/seq_kernel.h - 1.2 include/sound/sfnt_info.h - 1.2 include/sound/sndmagic.h - 1.2 include/sound/soundfont.h - 1.2 include/sound/sscape_ioctl.h - 1.2 include/sound/trident.h - 1.2 include/sound/version.h - 1.2 include/sound/ymfpci.h - 1.2 include/video/sisfb.h - 1.2 init/do_mounts_rd.c - 1.2 init/main.c - 1.5 kernel/cpu.c - 1.3 kernel/fork.c - 1.4 kernel/futex.c - 1.4 kernel/module.c - 1.4 kernel/posix-timers.c - 1.3 kernel/power/console.c - 1.2 kernel/power/swsusp.c - 1.3 kernel/printk.c - 1.4 kernel/resource.c - 1.2 kernel/sched.c - 1.5 kernel/sys.c - 1.4 kernel/sysctl.c - 1.3 lib/Makefile - 1.4 lib/crc32.c - 1.2 lib/gen_crc32table.c - 1.2 lib/string.c - 1.2 lib/vsprintf.c - 1.3 mm/filemap.c - 1.4 mm/memory.c - 1.4 mm/mmap.c - 1.4 mm/mremap.c - 1.4 mm/page_alloc.c - 1.4 mm/vmalloc.c - 1.2 mm/vmscan.c - 1.4 net/8021q/vlan_dev.c - 1.2 net/Kconfig - 1.2 net/appletalk/ddp.c - 1.3 net/atm/clip.c - 1.3 net/atm/common.c - 1.3 net/ax25/af_ax25.c - 1.4 net/core/dev.c - 1.4 net/core/flow.c - 1.3 net/core/sysctl_net_core.c - 1.3 net/core/utils.c - 1.2 net/decnet/Kconfig - 1.2 net/decnet/af_decnet.c - 1.4 net/decnet/dn_neigh.c - 1.2 net/decnet/dn_route.c - 1.2 net/econet/af_econet.c - 1.3 net/ipv4/Kconfig - 1.3 net/ipv4/arp.c - 1.3 net/ipv4/devinet.c - 1.3 net/ipv4/igmp.c - 1.3 net/ipv4/netfilter/ip_conntrack_core.c - 1.2 net/ipv4/netfilter/ip_conntrack_ftp.c - 1.2 net/ipv4/netfilter/ip_conntrack_proto_generic.c - 1.2 net/ipv4/netfilter/ip_conntrack_proto_icmp.c - 1.2 net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.2 net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.2 net/ipv4/netfilter/ip_conntrack_standalone.c - 1.2 net/ipv4/netfilter/ip_conntrack_tftp.c - 1.2 net/ipv4/netfilter/ip_fw_compat.c - 1.2 net/ipv4/netfilter/ip_fw_compat_masq.c - 1.2 net/ipv4/netfilter/ip_fw_compat_redir.c - 1.2 net/ipv4/netfilter/ip_nat_core.c - 1.2 net/ipv4/netfilter/ip_nat_ftp.c - 1.2 net/ipv4/netfilter/ip_nat_helper.c - 1.2 net/ipv4/netfilter/ip_nat_proto_icmp.c - 1.2 net/ipv4/netfilter/ip_nat_proto_tcp.c - 1.2 net/ipv4/netfilter/ip_nat_proto_udp.c - 1.2 net/ipv4/netfilter/ip_nat_proto_unknown.c - 1.2 net/ipv4/netfilter/ip_nat_rule.c - 1.2 net/ipv4/netfilter/ip_nat_standalone.c - 1.2 net/ipv4/netfilter/ip_nat_tftp.c - 1.2 net/ipv4/netfilter/ip_queue.c - 1.2 net/ipv4/netfilter/ip_tables.c - 1.3 net/ipv4/netfilter/ipt_CLASSIFY.c - 1.2 net/ipv4/netfilter/ipt_DSCP.c - 1.2 net/ipv4/netfilter/ipt_ECN.c - 1.2 net/ipv4/netfilter/ipt_LOG.c - 1.2 net/ipv4/netfilter/ipt_MARK.c - 1.2 net/ipv4/netfilter/ipt_MASQUERADE.c - 1.2 net/ipv4/netfilter/ipt_NETMAP.c - 1.2 net/ipv4/netfilter/ipt_REDIRECT.c - 1.2 net/ipv4/netfilter/ipt_REJECT.c - 1.2 net/ipv4/netfilter/ipt_SAME.c - 1.2 net/ipv4/netfilter/ipt_TCPMSS.c - 1.2 net/ipv4/netfilter/ipt_TOS.c - 1.2 net/ipv4/netfilter/ipt_ULOG.c - 1.2 net/ipv4/netfilter/ipt_ah.c - 1.2 net/ipv4/netfilter/ipt_conntrack.c - 1.2 net/ipv4/netfilter/ipt_dscp.c - 1.2 net/ipv4/netfilter/ipt_ecn.c - 1.2 net/ipv4/netfilter/ipt_esp.c - 1.2 net/ipv4/netfilter/ipt_helper.c - 1.2 net/ipv4/netfilter/ipt_iprange.c - 1.2 net/ipv4/netfilter/ipt_length.c - 1.2 net/ipv4/netfilter/ipt_limit.c - 1.2 net/ipv4/netfilter/ipt_mac.c - 1.2 net/ipv4/netfilter/ipt_mark.c - 1.2 net/ipv4/netfilter/ipt_multiport.c - 1.2 net/ipv4/netfilter/ipt_owner.c - 1.2 net/ipv4/netfilter/ipt_physdev.c - 1.2 net/ipv4/netfilter/ipt_pkttype.c - 1.2 net/ipv4/netfilter/ipt_state.c - 1.2 net/ipv4/netfilter/ipt_tcpmss.c - 1.2 net/ipv4/netfilter/ipt_tos.c - 1.2 net/ipv4/netfilter/ipt_ttl.c - 1.2 net/ipv4/netfilter/iptable_filter.c - 1.2 net/ipv4/netfilter/iptable_mangle.c - 1.2 net/ipv4/sysctl_net_ipv4.c - 1.2 net/ipv4/tcp.c - 1.3 net/ipv4/tcp_input.c - 1.2 net/ipv4/tcp_ipv4.c - 1.2 net/ipv6/addrconf.c - 1.4 net/ipv6/af_inet6.c - 1.3 net/ipv6/anycast.c - 1.3 net/ipv6/exthdrs.c - 1.3 net/ipv6/mcast.c - 1.3 net/ipv6/ndisc.c - 1.4 net/ipv6/netfilter/ip6_queue.c - 1.2 net/ipv6/netfilter/ip6_tables.c - 1.2 net/ipv6/netfilter/ip6t_LOG.c - 1.2 net/ipv6/netfilter/ip6t_MARK.c - 1.2 net/ipv6/netfilter/ip6t_ah.c - 1.2 net/ipv6/netfilter/ip6t_dst.c - 1.2 net/ipv6/netfilter/ip6t_esp.c - 1.2 net/ipv6/netfilter/ip6t_eui64.c - 1.2 net/ipv6/netfilter/ip6t_frag.c - 1.2 net/ipv6/netfilter/ip6t_hbh.c - 1.2 net/ipv6/netfilter/ip6t_hl.c - 1.2 net/ipv6/netfilter/ip6t_ipv6header.c - 1.2 net/ipv6/netfilter/ip6t_length.c - 1.2 net/ipv6/netfilter/ip6t_limit.c - 1.2 net/ipv6/netfilter/ip6t_mac.c - 1.2 net/ipv6/netfilter/ip6t_mark.c - 1.2 net/ipv6/netfilter/ip6t_multiport.c - 1.2 net/ipv6/netfilter/ip6t_owner.c - 1.2 net/ipv6/netfilter/ip6t_rt.c - 1.2 net/ipv6/netfilter/ip6table_filter.c - 1.2 net/ipv6/netfilter/ip6table_mangle.c - 1.2 net/ipv6/raw.c - 1.3 net/ipv6/udp.c - 1.3 net/ipx/af_ipx.c - 1.3 net/irda/af_irda.c - 1.3 net/key/af_key.c - 1.3 net/llc/llc_conn.c - 1.2 net/netlink/af_netlink.c - 1.3 net/netrom/af_netrom.c - 1.4 net/packet/af_packet.c - 1.4 net/rose/af_rose.c - 1.4 net/sched/Kconfig - 1.2 net/wanrouter/wanmain.c - 1.2 net/x25/af_x25.c - 1.3 net/xfrm/xfrm_policy.c - 1.4 scripts/Lindent - 1.2 scripts/Makefile.lib - 1.2 scripts/kconfig/mconf.c - 1.4 scripts/kconfig/menu.c - 1.2 scripts/lxdialog/checklist.c - 1.2 scripts/modpost.c - 1.4 security/commoncap.c - 1.3 security/selinux/ss/services.c - 1.3 security/selinux/ss/sidtab.c - 1.3 sound/core/Makefile - 1.2 sound/core/control.c - 1.2 sound/core/hwdep.c - 1.2 sound/core/info_oss.c - 1.2 sound/core/init.c - 1.2 sound/core/ioctl32/ioctl32.c - 1.2 sound/core/memalloc.c - 1.2 sound/core/memory.c - 1.2 sound/core/misc.c - 1.2 sound/core/oss/mixer_oss.c - 1.2 sound/core/oss/pcm_oss.c - 1.2 sound/core/oss/pcm_plugin.c - 1.2 sound/core/pcm.c - 1.2 sound/core/pcm_lib.c - 1.2 sound/core/pcm_memory.c - 1.2 sound/core/pcm_misc.c - 1.2 sound/core/pcm_native.c - 1.3 sound/core/rawmidi.c - 1.2 sound/core/seq/oss/seq_oss.c - 1.2 sound/core/seq/seq.c - 1.2 sound/core/seq/seq_clientmgr.c - 1.2 sound/core/seq/seq_clientmgr.h - 1.2 sound/core/seq/seq_device.c - 1.2 sound/core/seq/seq_dummy.c - 1.2 sound/core/seq/seq_fifo.c - 1.2 sound/core/seq/seq_fifo.h - 1.2 sound/core/seq/seq_info.c - 1.2 sound/core/seq/seq_info.h - 1.2 sound/core/seq/seq_memory.c - 1.2 sound/core/seq/seq_memory.h - 1.2 sound/core/seq/seq_midi.c - 1.2 sound/core/seq/seq_ports.c - 1.2 sound/core/seq/seq_ports.h - 1.2 sound/core/seq/seq_prioq.c - 1.2 sound/core/seq/seq_prioq.h - 1.2 sound/core/seq/seq_queue.c - 1.2 sound/core/seq/seq_queue.h - 1.2 sound/core/seq/seq_system.c - 1.2 sound/core/seq/seq_system.h - 1.2 sound/core/seq/seq_timer.c - 1.2 sound/core/seq/seq_timer.h - 1.2 sound/core/sound.c - 1.4 sound/core/sound_oss.c - 1.2 sound/core/timer.c - 1.2 sound/drivers/mpu401/mpu401.c - 1.2 sound/drivers/mpu401/mpu401_uart.c - 1.2 sound/drivers/mtpav.c - 1.2 sound/drivers/opl3/opl3_lib.c - 1.2 sound/drivers/opl3/opl3_synth.c - 1.2 sound/drivers/opl4/opl4_lib.c - 1.2 sound/drivers/opl4/opl4_proc.c - 1.2 sound/drivers/serial-u16550.c - 1.2 sound/drivers/vx/vx_core.c - 1.2 sound/drivers/vx/vx_pcm.c - 1.2 sound/i2c/cs8427.c - 1.2 sound/i2c/i2c.c - 1.2 sound/i2c/l3/uda1341.c - 1.2 sound/i2c/other/Makefile - 1.2 sound/i2c/other/ak4xxx-adda.c - 1.2 sound/isa/ad1816a/ad1816a.c - 1.2 sound/isa/ad1816a/ad1816a_lib.c - 1.2 sound/isa/ad1848/ad1848.c - 1.2 sound/isa/ad1848/ad1848_lib.c - 1.2 sound/isa/als100.c - 1.2 sound/isa/azt2320.c - 1.2 sound/isa/cmi8330.c - 1.2 sound/isa/cs423x/cs4231.c - 1.2 sound/isa/cs423x/cs4231_lib.c - 1.2 sound/isa/cs423x/cs4236.c - 1.2 sound/isa/cs423x/pc98.c - 1.2 sound/isa/dt019x.c - 1.2 sound/isa/es1688/es1688.c - 1.2 sound/isa/es1688/es1688_lib.c - 1.2 sound/isa/es18xx.c - 1.2 sound/isa/gus/gus_irq.c - 1.2 sound/isa/gus/gus_main.c - 1.2 sound/isa/gus/gus_mem.c - 1.2 sound/isa/gus/gus_pcm.c - 1.2 sound/isa/gus/gusclassic.c - 1.2 sound/isa/gus/gusextreme.c - 1.2 sound/isa/gus/gusmax.c - 1.2 sound/isa/gus/interwave.c - 1.2 sound/isa/opl3sa2.c - 1.2 sound/isa/opti9xx/opti92x-ad1848.c - 1.2 sound/isa/sb/emu8000.c - 1.2 sound/isa/sb/emu8000_callback.c - 1.2 sound/isa/sb/emu8000_local.h - 1.2 sound/isa/sb/emu8000_patch.c - 1.2 sound/isa/sb/emu8000_synth.c - 1.2 sound/isa/sb/es968.c - 1.2 sound/isa/sb/sb16.c - 1.2 sound/isa/sb/sb16_csp.c - 1.2 sound/isa/sb/sb8.c - 1.2 sound/isa/sb/sb_common.c - 1.2 sound/isa/sgalaxy.c - 1.2 sound/isa/sscape.c - 1.2 sound/isa/wavefront/wavefront.c - 1.2 sound/oss/ac97_codec.c - 1.2 sound/oss/ad1889.c - 1.2 sound/oss/dmasound/dmasound.h - 1.2 sound/oss/dmasound/dmasound_awacs.c - 1.2 sound/oss/dmasound/dmasound_core.c - 1.2 sound/oss/dmasound/tas3001c.c - 1.2 sound/oss/dmasound/tas3001c_tables.c - 1.2 sound/oss/dmasound/tas3004.c - 1.2 sound/oss/dmasound/tas3004_tables.c - 1.2 sound/oss/dmasound/tas_common.c - 1.2 sound/oss/dmasound/tas_common.h - 1.2 sound/oss/dmasound/trans_16.c - 1.2 sound/oss/sb_card.h - 1.2 sound/pci/Kconfig - 1.2 sound/pci/Makefile - 1.2 sound/pci/ac97/Makefile - 1.2 sound/pci/ac97/ac97_codec.c - 1.2 sound/pci/ac97/ac97_local.h - 1.2 sound/pci/ac97/ac97_patch.c - 1.2 sound/pci/ac97/ac97_patch.h - 1.2 sound/pci/ac97/ac97_proc.c - 1.2 sound/pci/ac97/ak4531_codec.c - 1.2 sound/pci/ali5451/ali5451.c - 1.2 sound/pci/als4000.c - 1.2 sound/pci/azt3328.c - 1.2 sound/pci/cmipci.c - 1.2 sound/pci/cs4281.c - 1.2 sound/pci/cs46xx/cs46xx_lib.c - 1.2 sound/pci/cs46xx/dsp_spos_scb_lib.c - 1.2 sound/pci/emu10k1/emu10k1_main.c - 1.2 sound/pci/emu10k1/emu10k1_patch.c - 1.2 sound/pci/emu10k1/emu10k1_synth.c - 1.2 sound/pci/emu10k1/emu10k1_synth_local.h - 1.2 sound/pci/emu10k1/emufx.c - 1.2 sound/pci/emu10k1/emumixer.c - 1.2 sound/pci/emu10k1/emupcm.c - 1.2 sound/pci/emu10k1/emuproc.c - 1.2 sound/pci/emu10k1/memory.c - 1.2 sound/pci/ens1370.c - 1.2 sound/pci/es1938.c - 1.2 sound/pci/es1968.c - 1.2 sound/pci/fm801.c - 1.2 sound/pci/ice1712/Makefile - 1.2 sound/pci/ice1712/ak4xxx.c - 1.2 sound/pci/ice1712/aureon.c - 1.2 sound/pci/ice1712/aureon.h - 1.2 sound/pci/ice1712/delta.c - 1.2 sound/pci/ice1712/delta.h - 1.2 sound/pci/ice1712/ice1712.c - 1.2 sound/pci/ice1712/ice1712.h - 1.2 sound/pci/ice1712/ice1724.c - 1.2 sound/pci/intel8x0.c - 1.3 sound/pci/korg1212/korg1212.c - 1.2 sound/pci/maestro3.c - 1.2 sound/pci/nm256/nm256.c - 1.2 sound/pci/rme32.c - 1.2 sound/pci/rme96.c - 1.2 sound/pci/rme9652/hdsp.c - 1.2 sound/pci/rme9652/rme9652.c - 1.2 sound/pci/sonicvibes.c - 1.2 sound/pci/trident/trident.c - 1.2 sound/pci/trident/trident_main.c - 1.2 sound/pci/via82xx.c - 1.2 sound/pci/vx222/vx222.c - 1.2 sound/pci/ymfpci/ymfpci.c - 1.2 sound/pci/ymfpci/ymfpci_main.c - 1.2 sound/pcmcia/Kconfig - 1.2 sound/pcmcia/vx/vx_entry.c - 1.3 sound/ppc/daca.c - 1.2 sound/ppc/tumbler.c - 1.2 sound/synth/emux/Makefile - 1.2 sound/synth/emux/emux.c - 1.2 sound/synth/emux/emux_seq.c - 1.2 sound/synth/emux/emux_voice.h - 1.2 sound/synth/emux/soundfont.c - 1.2 sound/usb/usbaudio.c - 1.3 sound/usb/usbaudio.h - 1.3 sound/usb/usbmidi.c - 1.2 sound/usb/usbquirks.h - 1.2 include/asm-x86_64/memblk.h - 1.2 lib/mask.c - 1.2 drivers/media/dvb/frontends/dst.c - 1.2 arch/arm/configs/netwinder_defconfig - 1.2 drivers/ide/pci/sgiioc4.c - 1.3 arch/parisc/kernel/signal32.h - 1.2 arch/ia64/configs/sn2_defconfig - 1.3 drivers/scsi/qla2xxx/Kconfig - 1.2 drivers/scsi/qla2xxx/Makefile - 1.2 drivers/scsi/qla2xxx/ql2300.c - 1.2 drivers/scsi/qla2xxx/ql2300_fw.c - 1.2 drivers/scsi/qla2xxx/qla_dbg.c - 1.2 drivers/scsi/qla2xxx/qla_dbg.h - 1.2 drivers/scsi/qla2xxx/qla_def.h - 1.2 drivers/scsi/qla2xxx/qla_gbl.h - 1.2 drivers/scsi/qla2xxx/qla_gs.c - 1.2 drivers/scsi/qla2xxx/qla_init.c - 1.2 drivers/scsi/qla2xxx/qla_iocb.c - 1.2 drivers/scsi/qla2xxx/qla_isr.c - 1.2 drivers/scsi/qla2xxx/qla_mbx.c - 1.2 drivers/scsi/qla2xxx/qla_os.c - 1.2 drivers/scsi/qla2xxx/qla_settings.h - 1.2 drivers/scsi/qla2xxx/qla_sup.c - 1.2 drivers/scsi/qla2xxx/qla_version.h - 1.2 include/asm-ppc64/iSeries/vio.h - 1.2 include/asm-ppc64/vio.h - 1.2 arch/ia64/configs/generic_defconfig - 1.2 drivers/net/forcedeth.c - 1.2 drivers/media/video/saa7134/saa7134-input.c - 1.2 drivers/md/raid6x86.h - 1.3 drivers/md/raid6main.c - 1.2 lib/bitmap.c - 1.2 arch/ia64/sn/io/sn2/pcibr/pcibr_reg.c - 1.2 arch/ppc64/kernel/vio.c - 1.2 arch/ppc64/kernel/lparcfg.c - 1.3 arch/ppc64/kernel/iSeries_htab.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Feb 8 17:39:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Feb 2004 17:39:14 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i191d1KO014183 for ; Sun, 8 Feb 2004 17:39:02 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i191csmI031957 for ; Sun, 8 Feb 2004 17:38:55 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i191YO9A008958 for ; Mon, 9 Feb 2004 12:34:25 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i191YNbG008957 for linux-xfs@oss.sgi.com; Mon, 9 Feb 2004 12:34:23 +1100 Date: Mon, 9 Feb 2004 12:34:23 +1100 From: FSG QA Message-Id: <200402090134.i191YNbG008957@bruce.melbourne.sgi.com> Subject: TAKE - fs/xattr.c X-archive-position: 2030 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix minor breakage in the extended attributes VFS code. -- nathans Date: Sun Feb 8 17:37:36 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166396a fs/xattr.c - 1.3 From owner-linux-xfs@oss.sgi.com Sun Feb 8 18:05:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Feb 2004 18:05:42 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1925RKO015084 for ; Sun, 8 Feb 2004 18:05:27 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1925MmI005655 for ; Sun, 8 Feb 2004 18:05:22 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1925LTr33894020; Sun, 8 Feb 2004 20:05:21 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Aq0nX-0005fC-00; Sun, 08 Feb 2004 20:05:19 -0600 Subject: TAKE 908003 - allow loadable behaviour modules in 2.6 Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Sun, 08 Feb 2004 20:05:19 -0600 X-archive-position: 2031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Sun Feb 8 18:04:38 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166397a fs/xfs/dmapi/Makefile-linux-2.4 - 1.1 - dmapi makefile for Linux 2.4 fs/xfs/quota/Makefile-linux-2.4 - 1.1 - dmapi makefile for Linux 2.4 fs/xfs/quota/Makefile-linux-2.6 - 1.1 - dmapi makefile for Linux 2.6 fs/xfs/dmapi/Makefile-linux-2.6 - 1.1 - dmapi makefile for Linux 2.6 fs/xfs/xfs_vfsops.c - 1.444 - rename dmapi and quota stub operations to avoid nameclash fs/xfs/xfs_mount.h - 1.184 - rename dmapi and quota stub operations to avoid nameclash fs/xfs/xfs_qmops.c - 1.10 - rename quota stub operations to avoid nameclash fs/xfs/xfs_dmops.c - 1.9 - rename dmapi stub operations to avoid nameclash fs/xfs/xfs_quota.h - 1.36 - remove externs for initialization routines fs/xfs/quota/xfs_qm_bhv.c - 1.8 - initialize the quota module here for both 2.4 and 2.6 kernels fs/xfs/quota/Makefile - 1.8 - all real content moved to version-specific makefiles fs/xfs/dmapi/Makefile - 1.24 - all real content moved to version-specific makefiles fs/xfs/Makefile-linux-2.6 - 1.186 - build xfs_dmops.o and xfs_qmops.o unconditionally delegate quota and dmapi source to makefiles in the subdirs fs/xfs/Makefile-linux-2.4 - 1.202 - build xfs_dmops.o and xfs_qmops.o unconditionally fs/xfs/linux-2.6/xfs_vfs.c - 1.52 - load behaviour modules for dmapi and quota if nessecary fs/xfs/linux-2.6/xfs_globals.c - 1.58 - add probe_dmapi and probe_quota sysctls fs/xfs/linux-2.6/xfs_linux.h - 1.117 - add probe_dmapi and probe_quota sysctls fs/xfs/linux-2.6/xfs_super.h - 1.53 - remove quota initialization fs/xfs/linux-2.6/xfs_super.c - 1.295 - remove quota initialization fs/xfs/linux-2.6/xfs_sysctl.c - 1.25 - add probe_dmapi and probe_quota sysctls fs/xfs/linux-2.6/xfs_sysctl.h - 1.19 - add probe_dmapi and probe_quota sysctls fs/xfs/quota/xfs_qm_ksyms.c - 1.3 - remove module initialization from here Modid: 2.6.x-xfs:linux:166397b fs/Kconfig - 1.5 - change XFS_QUOTA and XFS_DMAPI to tristate options From owner-linux-xfs@oss.sgi.com Sun Feb 8 20:08:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Feb 2004 20:09:17 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1948tKO017245 for ; Sun, 8 Feb 2004 20:08:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1949vt8003002 for ; Sun, 8 Feb 2004 20:09:59 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1948hhI6245784; Mon, 9 Feb 2004 15:08:43 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1948gbK6168161; Mon, 9 Feb 2004 15:08:42 +1100 (EST) Date: Mon, 9 Feb 2004 15:08:42 +1100 (EST) From: Nathan Scott Message-Id: <200402090408.i1948gbK6168161@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, agruen@suse.de Subject: TAKE - attr(5) man page X-archive-position: 2032 X-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 Update attr.5 man page to include details of security namespace. Date: Sun Feb 8 20:08:02 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: agruen@suse.de The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166405a attr/man/man5/attr.5 - 1.8 From owner-linux-xfs@oss.sgi.com Mon Feb 9 10:35:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 10:35:49 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19IZEKO004392 for ; Mon, 9 Feb 2004 10:35:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i19IZ9U3026923 for ; Mon, 9 Feb 2004 10:35:09 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i19IZ3CY33800979; Mon, 9 Feb 2004 12:35:03 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i19IZ3kP1352044; Mon, 9 Feb 2004 12:35:03 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i19IZ29i6889939; Mon, 9 Feb 2004 12:35:02 -0600 (CST) Message-Id: <200402091835.i19IZ29i6889939@clink.americas.sgi.com> To: Nathan Scott cc: James A Goodwin , linux-xfs@oss.sgi.com Subject: Re: DMAPI: DM attribute/region space allocation Date: Mon, 09 Feb 2004 12:35:02 -0600 From: Dean Roehrich X-archive-position: 2033 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs >From: Nathan Scott >On Fri, Feb 06, 2004 at 01:42:50PM -0600, James A Goodwin wrote: >> Dean, > >I think Deans away for a few days, let me try to answer... >(and get overruled by Dean when he returns ;) > >> We have a problem when managing an XFS filesystem using the DMAPI. When we >> copy data from an XFS file to our archive, we cover the file with a DMAPI >> region to inform us of read, write, and truncate events. However, if the >> filesystem is full, we cannot establish this region, and we don't have a >> good way to recover. >> >> To fix the problem, we plan to preallocate a DM region to each file when it >> is created. This region would not be set to generate any I/O events but >> would serve only to preallocate storage. We could later modify the region >> to generate I/O events. If we couldn't create the region due to space >> constraints, we could just abort the file create. >> I have two questions. First, will this approach work? > >Seems like a valid approach to me. You need enough space for an XFS transaction. You're not solving anything by having regions preallocated. >> I'm guessing that it will allocate one block, stick the region >> in there, and have lots of extra space for other extended attributes (i.e., >> DM attributes). I'm hoping that it will be enough to ensure that I can >> create, modify, and remove some number of DM attributes without having to >> worry about space shortages, but I have no idea how much space I'll have to >> play with. > >I believe SGIs HSM uses the XFS RESBLKS interface to reserve a set >amount of filesystem space, which is only available when allocating >extended attribute space for the root namespace (where the DMAPI >attributes reside). Yes. Mentioned briefly in the xfs(5) manpage. Dunno if this works, but here's how it might be done... xfs_fsop_resblks_t counts; fd = open(device, ...); counts.resblks = 100; /* experiment with it */ ioctl(fd, XFS_IOC_SET_RESBLKS, &counts); I believe you have to do that everytime you mount the filesystem. Dean From owner-linux-xfs@oss.sgi.com Mon Feb 9 12:54:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 12:55:11 -0800 (PST) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19KsqKO014334 for ; Mon, 9 Feb 2004 12:54:53 -0800 Received: from hpti9.fsl.noaa.gov ([137.75.132.229]) by hptimail01.HPTI.COM over TLS secured channel with Microsoft SMTPSVC(6.0.3790.0); Mon, 9 Feb 2004 15:54:32 -0500 Subject: Re: Data corruption with xfs+nfs+lvm From: Craig Tierney To: Nathan Scott Cc: cattelan@sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <1075482631.3866.9.camel@hpti7.fsl.noaa.gov> References: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> <20040130024343.GC1062@frodo> <1075482631.3866.9.camel@hpti7.fsl.noaa.gov> Content-Type: text/plain Message-Id: <1076360029.5321.53.camel@hpti9.fsl.noaa.gov> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 09 Feb 2004 13:53:49 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2004 20:54:32.0511 (UTC) FILETIME=[EAF7ECF0:01C3EF4E] X-archive-position: 2034 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs On Fri, 2004-01-30 at 10:10, Craig Tierney wrote: > On Thu, 2004-01-29 at 19:43, Nathan Scott wrote: > > On Thu, Jan 29, 2004 at 05:49:07PM -0700, Craig Tierney wrote: > > > I have just discovered that I am having problems with data corruption > > > on my NFS servers and XFS. It happens in several different cases, but > > > all under load. Here are the cases that I have gotten data corruption > > > for reads and writes. Corruption happens on different servers and > > > on different filesystems (some configured with LVM striping, some not). > > > > Can you descibe your test case in more detail? In particular, > > do you have a program/programs that demonstrates the problem? > > That is always a huge help. Or a list of things to run - what > > sort of IO is being done, and what does "under load" mean in > > your context. I wanted to update the situation. I patched the kernel to remove the call to xfs_refcache_purge_some. This improve the situation, but I am still getting data corruption from the model. I tried to cause the problem on the filesystem directly with a serial code. I was not able to cause a problem running 24 cases of the code. I tried running the same set of cases over NFS. I was not able to cause the problem. However, when running the MPI model (several cases simutaneously) I can get differences in the output files. They should be the same. Of course it is the 64 processor code that causes the problem! I could be something else besides the filesystem, but I doubt it at this point. Data are only written from the rank zero process (no parallel IO). I still had some other problems. I had a non-insignificant number of models crash for no reason. I cannot blame that on xfs though. I did have 2 cases where the model got stuck writing data to the filesystem. Things got better without the xfs_refcache_purge_some but I still had differing output and some wedged disk cases. Load would be about 20 concurrent processes doing large reads or writes to the filesystem. Are there any significant differences in the xfs to be in 2.4.25 that I should try (easy to do)? Should I try playing with network settings? Change from gigE to FastEthernet or reduce the number of NFS threads (currently set at 256)? Thanks, Craig From owner-linux-xfs@oss.sgi.com Mon Feb 9 14:52:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 14:52:45 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i19MqIKO021787 for ; Mon, 9 Feb 2004 14:52:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i19Mq7Ik012485 for ; Mon, 9 Feb 2004 16:52:10 -0600 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 JAA14591; Tue, 10 Feb 2004 09:52:01 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i19MpnUc4084345; Tue, 10 Feb 2004 09:51:49 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i19Mp7mY000973; Tue, 10 Feb 2004 09:51:08 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i19MolR6000971; Tue, 10 Feb 2004 09:50:47 +1100 Date: Tue, 10 Feb 2004 09:50:47 +1100 From: Nathan Scott To: James A Goodwin , Dean Roehrich Cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI: DM attribute/region space allocation Message-ID: <20040209225047.GB879@frodo> References: <200402091835.i19IZ29i6889939@clink.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402091835.i19IZ29i6889939@clink.americas.sgi.com> User-Agent: Mutt/1.5.3i X-archive-position: 2035 X-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, Feb 09, 2004 at 12:35:02PM -0600, Dean Roehrich wrote: > >From: Nathan Scott > > > >I believe SGIs HSM uses the XFS RESBLKS interface to reserve a set > >amount of filesystem space, which is only available when allocating > >extended attribute space for the root namespace (where the DMAPI > >attributes reside). > > Yes. Mentioned briefly in the xfs(5) manpage. > > Dunno if this works, but here's how it might be done... > > xfs_fsop_resblks_t counts; > fd = open(device, ...); (not the block device, the ioctl needs to get into XFS.) > counts.resblks = 100; /* experiment with it */ > ioctl(fd, XFS_IOC_SET_RESBLKS, &counts); > > I believe you have to do that everytime you mount the filesystem. Yes; there is also an xfs_io(8) interface for this - just point it at the mount point or a file in the filesystem, and you can get & set this value (and see available reserved space too). I played with making this a more generic interface once, to allow root to have access to an extra chunk of space for allocations, like other fs's do. But I didn't get around to tidying it up, testing it properly, etc (& the patch is long since lost before someone asks for it ;) - but it wasn't too difficult iirc). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 9 17:15:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 17:15:23 -0800 (PST) Received: from gghcwest.com ([65.198.37.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A1F3KO030931 for ; Mon, 9 Feb 2004 17:15:06 -0800 Received: from pc105.gghcwest.com (pc105.gghcwest.com [192.168.168.105]) by gghcwest.com (8.12.10/8.12.9) with ESMTP id i1A1F0XA009859 for ; Mon, 9 Feb 2004 17:15:00 -0800 Subject: Corruption of in-memory data detected. From: "Jeffrey W. Baker" To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1076375702.11238.41.camel@heat> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 09 Feb 2004 17:15:02 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2036 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jwbaker@acm.org Precedence: bulk X-list: linux-xfs We are running a system on 2.4 kernels, previously the XFS 2.4.23, currently the mainline 2.4.25-rc1. We have no additional patches to the kernels. Our storage is a SCSI-SATA RAID controller attached to the host via Adaptec 39320D HBA, driver revision 1.3.10. Our XFS filesystem is a 700GB volume which we use for local databases and also export via NFS. We are able to fairly reliably produce this message (kernel 2.4.23-xfs): xfs_force_shutdown(sd(8,1),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xc0229d9c Filesystem "sd(8,1)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,1) Please umount the filesystem, and rectify the problem(s) There are *no* I/O errors preceeding this message. After rebooting the system, xfs_check shows errors and xfs_repair claims to repair them. Some files turn up in lost+found. We can cause this error fairly reliably. We have also seen this dump from the kernel: Feb 7 06:39:11 prime kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Feb 7 06:39:11 prime kernel: Filesystem "sd(8,1)": XFS internal error xfs_da_do_buf(2) at line 2273 of file xfs_da_btree.c. Caller 0xc01dfa17 Feb 7 06:39:11 prime kernel: f0e4bcb0 c01df425 c0364e3d 00000001 f7626400 c0364d7f 000008e1 c01dfa17 Feb 7 06:39:11 prime kernel: c01dfa17 f0e4bd18 00000000 007fffbf 00000000 00000041 00000003 0100032a Feb 7 06:39:11 prime kernel: 00000018 00000000 0000002d 00000001 00000000 f7626400 f0e4bd34 00000001 Feb 7 06:39:11 prime kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Feb 7 19:19:53 prime kernel: 0x0: 1f 8b 08 08 6e 9b 09 40 00 03 32 33 37 30 36 30 Feb 7 19:19:53 prime kernel: Filesystem "sd(8,1)": XFS internal error xfs_da_do_buf(2) at line 2273 of file xfs_da_btree.c. Caller 0xc01dfa17 Feb 7 19:19:53 prime kernel: f760dcb0 c01df425 c0364e3d 00000001 f7626400 c0364d7f 000008e1 c01dfa17 Feb 7 19:19:53 prime kernel: c01dfa17 f760dd18 00000000 007fffbf 00000000 00000041 00000003 0100032a Feb 7 19:19:53 prime kernel: 00000018 00000000 0000002d 00000001 00000000 f7626400 f760dd34 00000001 Feb 7 19:19:53 prime kernel: Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Which translates to something like (ksymoops, without code line): Trace; c01df425 Trace; c01dfa17 Trace; c01dfa17 Trace; c01dfa17 Trace; c01e67bf Trace; c01e67bf Trace; c01e28e0 Trace; c01e28e0 Trace; c01e20e8 Trace; c01e28e0 Trace; c02192e0 Trace; c02220f9 Trace; c0151b6e Trace; c0152270 Trace; c01523db Trace; c0152270 Trace; c0135065 Trace; c010762f and: Trace; c01df425 Trace; c01dfa17 Trace; c01dfa17 Trace; c01dfa17 Trace; c01e67bf Trace; c01e67bf Trace; c01e28e0 Trace; c01e28e0 Trace; c01e20e8 Trace; c01e28e0 Trace; c02192e0 Trace; c02220f9 Trace; c0286d38 Trace; c0151b6e Trace; c0152270 Trace; c01523db Trace; c0152270 Trace; c0135065 Trace; c010762f To be fair, we have had SCSI errors on this device before, so device corruption is not out of the question. But we've also seen that after repairing the FS and testing again, we can corrupt the filesystem without ever seeing any hardware I/O errors at all. Thus in our investigation to nail down a problem with a SCSI bus we seemed to have narrowed it to a purely software problem. We reproduce the problem by running three parallel postgresql bulk loads (using pg_dump | psql) where both the source and target databases, as well as the transaction logs, are on the XFS in question. In parallel with that, we find -type f | xargs cat > /dev/null, which should exercise the metadata by traversing the entire FS, on which there are several millions of files. It's my impression that the proximate cause of the corruption is the sync writes done by postgresql. I don't have any evidence on that, it just seems that starting a postgresql operation can trigger the problem. I am more than willing to provide as much information as is needed to help diagnose the problem. I can't collect xfs_info right now, as xfs_repair is slogging through a lengthy Phase 5. -jwb From owner-linux-xfs@oss.sgi.com Mon Feb 9 19:12:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 19:12:20 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A3CGKO005377 for ; Mon, 9 Feb 2004 19:12:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1A3CAFW013742 for ; Mon, 9 Feb 2004 19:12:10 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19208 for ; Tue, 10 Feb 2004 14:12:09 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1A3C87a013439 for ; Tue, 10 Feb 2004 14:12:09 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1A3C8rn013437 for linux-xfs@oss.sgi.com; Tue, 10 Feb 2004 14:12:08 +1100 Date: Tue, 10 Feb 2004 14:12:08 +1100 From: Tim Shimmin Message-Id: <200402100312.i1A3C8rn013437@sherman.melbourne.sgi.com> Subject: PARTIAL TAKE 909066 - add goingdown ioctl Apparently-To: X-archive-position: 2037 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Some qa to test out simple replay of the logs by causing file system to shutdown. Date: Mon Feb 9 19:10:49 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166490a xfstests/src/godown.c - 1.1 - Program to call XFS_IOC_GOINGDOWN ioctl. xfstests/085 - 1.1 - Simple log replay test. xfstests/085.out - 1.1 - 085 out file. xfsprogs/include/xfs_fs.h - 1.28 - A copy of the kernel header file - modified for XFS_IOC_GOINGDOWN related macros. xfstests/group - 1.49 - Add 085. xfstests/src/Makefile - 1.22 - Add godown target for the XFS_IOC_GOINGDOWN ioctl call. From owner-linux-xfs@oss.sgi.com Mon Feb 9 19:24:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 19:24:21 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A3OEKO006040 for ; Mon, 9 Feb 2004 19:24:15 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1A31JFW012070 for ; Mon, 9 Feb 2004 19:01:19 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA19080 for ; Tue, 10 Feb 2004 14:01:17 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1A31H7a013336 for ; Tue, 10 Feb 2004 14:01:17 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1A31GEd013334 for linux-xfs@oss.sgi.com; Tue, 10 Feb 2004 14:01:16 +1100 Date: Tue, 10 Feb 2004 14:01:16 +1100 From: Tim Shimmin Message-Id: <200402100301.i1A31GEd013334@sherman.melbourne.sgi.com> Subject: PARTIAL TAKE 909066 - add goingdown ioctl Apparently-To: X-archive-position: 2038 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Add XFS_FS_GOINGDOWN ioctl to xfs. My motivation is for log recovery testing. Date: Mon Feb 9 19:00:00 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:166489a fs/xfs/xfs_fs.h - 1.16 - Add ioctl cmd for XFS_IOC_GOINGDOWN (the macro definition). Add some macros for the ioctl different arguments. fs/xfs/xfs_fsops.h - 1.26 - Prototype for xfs_fs_goingdown() defined in xfs_fsops.c. fs/xfs/xfs_fsops.c - 1.96 - The code to call to do the work for GOINGDOWN ioctl. It does the force_shutdowns. fs/xfs/linux-2.6/xfs_ioctl.c - 1.104 - Simplify returning of some error codes for ioctls and make consistent. Add XFS_IOC_GOINGDOWN as a new cmd ioctl. fs/xfs/linux-2.4/xfs_ioctl.c - 1.105 - Simplify returning of some error codes for ioctls and make consistent. Add XFS_IOC_GOINGDOWN as a new cmd ioctl. From owner-linux-xfs@oss.sgi.com Mon Feb 9 19:34:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 19:34:46 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A3YhKO006649 for ; Mon, 9 Feb 2004 19:34:43 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id i1A3YgUC027856 for ; Mon, 9 Feb 2004 22:34:42 -0500 (EST) Date: Mon, 9 Feb 2004 22:34:42 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: mkfs.xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2039 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, I am creating XFS filesystem on a 750Gb partition, which is made up of 4x250Gb WD disks in RAID-5 + 3ware card. System is RH9.0 with 2.4.23 kernel and xfs patch as of 031010 from the oss.sgi site. I collected all the useful info from the manual and from the list, but would like to make sure if I am doing the correct thing: mkfs.xfs -b size=4k -d su=64k,sw=3 -f -i size=512 -l su=64k,size=32m -L BIG /dev/sda1 The raid-5 stripe size is 64k, fixed. xfstools is 2.6.2, from atrpms site. meta-data=/dev/sda1 isize=512 agcount=32, agsize=5723344 blks = sectsz=512 data = bsize=4096 blocks=183147008, imaxpct=25 = sunit=16 swidth=48 blks, unwritten=1 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=8192, version=2 = sectsz=512 sunit=16 blks realtime =none extsz=65536 blocks=0, rtextents=0 ------------------ hdparm -tT /dev/sda /dev/sda: Timing buffer-cache reads: 128 MB in 0.20 seconds =640.00 MB/sec Timing buffered disk reads: 64 MB in 1.55 seconds = 41.29 MB/sec It is OK, but I am not shocked by the performance. Are there any recommended tests to test the filesystem before starting to populate it with all that 750Gb of data? All the best Gaspar From owner-linux-xfs@oss.sgi.com Mon Feb 9 20:12:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 20:13:06 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A4CnKO008019 for ; Mon, 9 Feb 2004 20:12:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1A4ChIk014841 for ; Mon, 9 Feb 2004 22:12:43 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1A4CfhI6759821 for ; Tue, 10 Feb 2004 15:12:41 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1A4CemC6771353 for linux-xfs@oss.sgi.com; Tue, 10 Feb 2004 15:12:40 +1100 (EST) Date: Tue, 10 Feb 2004 15:12:40 +1100 (EST) From: Nathan Scott Message-Id: <200402100412.i1A4CemC6771353@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.3-rc2 X-archive-position: 2040 X-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: Mon Feb 9 20:11:33 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166493a drivers/pnp/isapnp/Kconfig - 1.1 drivers/pci/msi.h - 1.1 drivers/pnp/pnpbios/Kconfig - 1.1 drivers/i2c/chips/gl518sm.c - 1.1 drivers/i2c/chips/fscher.c - 1.1 drivers/i2c/busses/i2c-hydra.c - 1.1 drivers/base/dmapool.c - 1.1 include/linux/dmapool.h - 1.1 CREDITS - 1.5 Documentation/DMA-API.txt - 1.2 Documentation/cciss.txt - 1.2 Documentation/networking/bonding.txt - 1.2 Documentation/networking/ifenslave.c - 1.2 MAINTAINERS - 1.4 Makefile - 1.7 arch/i386/kernel/acpi/boot.c - 1.5 arch/i386/kernel/cpu/cpufreq/acpi.c - 1.4 arch/i386/pci/irq.c - 1.3 arch/ia64/kernel/acpi.c - 1.5 arch/ia64/kernel/iosapic.c - 1.3 arch/v850/kernel/bug.c - 1.2 arch/v850/kernel/setup.c - 1.2 arch/v850/kernel/v850e_cache.c - 1.2 arch/x86_64/kernel/acpi/boot.c - 1.3 drivers/acpi/asus_acpi.c - 1.4 drivers/acpi/numa.c - 1.2 drivers/acpi/pci_irq.c - 1.3 drivers/acpi/processor.c - 1.4 drivers/acpi/tables.c - 1.3 drivers/acpi/toshiba_acpi.c - 1.3 drivers/base/Makefile - 1.4 drivers/base/class.c - 1.3 drivers/base/core.c - 1.3 drivers/block/cciss.c - 1.3 drivers/block/cciss.h - 1.2 drivers/block/cciss_cmd.h - 1.2 drivers/char/keyboard.c - 1.5 drivers/char/pcmcia/synclink_cs.c - 1.3 drivers/char/synclink.c - 1.2 drivers/char/synclinkmp.c - 1.2 drivers/char/tty_io.c - 1.4 drivers/i2c/busses/Kconfig - 1.4 drivers/i2c/busses/Makefile - 1.3 drivers/i2c/chips/Kconfig - 1.4 drivers/i2c/chips/Makefile - 1.4 drivers/i2c/chips/lm85.c - 1.4 drivers/i2c/i2c-core.c - 1.4 drivers/ide/Makefile - 1.4 drivers/ide/arm/icside.c - 1.3 drivers/ide/arm/rapide.c - 1.2 drivers/ide/ide-cd.c - 1.5 drivers/ide/ide-dma.c - 1.4 drivers/ide/ide.c - 1.6 drivers/ide/pci/aec62xx.c - 1.2 drivers/ide/pci/aec62xx.h - 1.2 drivers/ide/pci/alim15x3.c - 1.2 drivers/ide/pci/alim15x3.h - 1.2 drivers/ide/pci/amd74xx.c - 1.3 drivers/ide/pci/amd74xx.h - 1.2 drivers/ide/pci/cmd64x.c - 1.2 drivers/ide/pci/cmd64x.h - 1.2 drivers/ide/pci/cs5520.c - 1.2 drivers/ide/pci/cs5520.h - 1.2 drivers/ide/pci/cs5530.c - 1.2 drivers/ide/pci/cs5530.h - 1.2 drivers/ide/pci/cy82c693.c - 1.2 drivers/ide/pci/generic.c - 1.2 drivers/ide/pci/hpt34x.c - 1.2 drivers/ide/pci/hpt34x.h - 1.2 drivers/ide/pci/hpt366.c - 1.2 drivers/ide/pci/hpt366.h - 1.2 drivers/ide/pci/it8172.c - 1.2 drivers/ide/pci/ns87415.c - 1.2 drivers/ide/pci/opti621.c - 1.2 drivers/ide/pci/pdc202xx_new.c - 1.3 drivers/ide/pci/pdc202xx_new.h - 1.2 drivers/ide/pci/pdc202xx_old.c - 1.3 drivers/ide/pci/pdc202xx_old.h - 1.2 drivers/ide/pci/piix.c - 1.3 drivers/ide/pci/piix.h - 1.2 drivers/ide/pci/rz1000.c - 1.2 drivers/ide/pci/sc1200.c - 1.3 drivers/ide/pci/sc1200.h - 1.2 drivers/ide/pci/serverworks.c - 1.2 drivers/ide/pci/serverworks.h - 1.2 drivers/ide/pci/siimage.c - 1.3 drivers/ide/pci/siimage.h - 1.2 drivers/ide/pci/sis5513.c - 1.2 drivers/ide/pci/sis5513.h - 1.2 drivers/ide/pci/sl82c105.c - 1.2 drivers/ide/pci/slc90e66.c - 1.2 drivers/ide/pci/slc90e66.h - 1.2 drivers/ide/pci/triflex.c - 1.3 drivers/ide/pci/triflex.h - 1.3 drivers/ide/pci/trm290.c - 1.2 drivers/ide/pci/via82cxxx.c - 1.2 drivers/ide/pci/via82cxxx.h - 1.2 drivers/ieee1394/amdtp.c - 1.3 drivers/ieee1394/dv1394.c - 1.3 drivers/ieee1394/eth1394.c - 1.4 drivers/ieee1394/raw1394.c - 1.4 drivers/ieee1394/video1394.c - 1.4 drivers/input/evdev.c - 1.4 drivers/input/serio/i8042.c - 1.4 drivers/media/dvb/ttusb-dec/ttusb_dec.c - 1.5 drivers/net/3c503.c - 1.3 drivers/net/8390.c - 1.2 drivers/net/8390.h - 1.2 drivers/net/Space.c - 1.4 drivers/net/a2065.c - 1.3 drivers/net/ac3200.c - 1.3 drivers/net/apne.c - 1.3 drivers/net/appletalk/ipddp.c - 1.2 drivers/net/arcnet/arc-rimi.c - 1.2 drivers/net/arcnet/arcnet.c - 1.2 drivers/net/arcnet/com20020-isa.c - 1.2 drivers/net/arcnet/com20020-pci.c - 1.2 drivers/net/arcnet/com20020.c - 1.2 drivers/net/arcnet/com90io.c - 1.2 drivers/net/arcnet/com90xx.c - 1.2 drivers/net/arm/ether1.c - 1.3 drivers/net/arm/etherh.c - 1.3 drivers/net/bonding/bond_3ad.c - 1.2 drivers/net/bonding/bond_3ad.h - 1.2 drivers/net/bonding/bond_alb.c - 1.2 drivers/net/bonding/bond_alb.h - 1.2 drivers/net/bonding/bond_main.c - 1.3 drivers/net/bonding/bonding.h - 1.2 drivers/net/e2100.c - 1.3 drivers/net/es3210.c - 1.3 drivers/net/hamradio/baycom_epp.c - 1.3 drivers/net/hamradio/dmascc.c - 1.2 drivers/net/hp-plus.c - 1.3 drivers/net/hp.c - 1.3 drivers/net/hydra.c - 1.3 drivers/net/ibmlana.c - 1.2 drivers/net/ibmlana.h - 1.2 drivers/net/irda/ali-ircc.c - 1.4 drivers/net/irda/nsc-ircc.c - 1.3 drivers/net/irda/sa1100_ir.c - 1.2 drivers/net/irda/smsc-ircc2.c - 1.3 drivers/net/irda/via-ircc.c - 1.3 drivers/net/irda/w83977af_ir.c - 1.3 drivers/net/ixgb/ixgb_main.c - 1.2 drivers/net/lne390.c - 1.3 drivers/net/lp486e.c - 1.2 drivers/net/mac8390.c - 1.3 drivers/net/macmace.c - 1.3 drivers/net/macsonic.c - 1.3 drivers/net/meth.c - 1.2 drivers/net/mvme147.c - 1.3 drivers/net/ne.c - 1.3 drivers/net/ne2.c - 1.3 drivers/net/ne2k_cbus.c - 1.3 drivers/net/ne3210.c - 1.2 drivers/net/net_init.c - 1.2 drivers/net/ns83820.c - 1.3 drivers/net/oaknet.c - 1.3 drivers/net/pcmcia/3c574_cs.c - 1.5 drivers/net/pcmcia/3c589_cs.c - 1.4 drivers/net/pcmcia/axnet_cs.c - 1.3 drivers/net/pcmcia/com20020_cs.c - 1.3 drivers/net/pcmcia/fmvj18x_cs.c - 1.4 drivers/net/pcmcia/ibmtr_cs.c - 1.3 drivers/net/pcmcia/nmclan_cs.c - 1.4 drivers/net/pcmcia/pcnet_cs.c - 1.4 drivers/net/pcmcia/smc91c92_cs.c - 1.4 drivers/net/pcnet32.c - 1.2 drivers/net/plip.c - 1.3 drivers/net/ppp_generic.c - 1.2 drivers/net/sk98lin/skge.c - 1.5 drivers/net/skfp/skfddi.c - 1.2 drivers/net/smc-mca.c - 1.2 drivers/net/smc-ultra.c - 1.3 drivers/net/smc-ultra32.c - 1.3 drivers/net/stnic.c - 1.4 drivers/net/sun3_82586.c - 1.3 drivers/net/sun3lance.c - 1.3 drivers/net/tokenring/3c359.c - 1.3 drivers/net/tokenring/ibmtr.c - 1.2 drivers/net/tokenring/olympic.c - 1.3 drivers/net/tokenring/tms380tr.c - 1.2 drivers/net/wan/Kconfig - 1.4 drivers/net/wan/cosa.c - 1.2 drivers/net/wan/pc300_tty.c - 1.2 drivers/net/wd.c - 1.3 drivers/net/wireless/airport.c - 1.2 drivers/net/wireless/orinoco_pci.c - 1.3 drivers/net/wireless/orinoco_plx.c - 1.2 drivers/net/wireless/orinoco_tmd.c - 1.2 drivers/net/wireless/ray_cs.c - 1.3 drivers/net/wireless/wl3501_cs.c - 1.3 drivers/net/zorro8390.c - 1.3 drivers/pci/Makefile - 1.3 drivers/pci/hotplug.c - 1.2 drivers/pci/hotplug/acpiphp_core.c - 1.3 drivers/pci/hotplug/acpiphp_glue.c - 1.3 drivers/pci/hotplug/cpqphp_ctrl.c - 1.2 drivers/pci/hotplug/cpqphp_pci.c - 1.2 drivers/pci/hotplug/ibmphp_core.c - 1.2 drivers/pci/hotplug/ibmphp_ebda.c - 1.2 drivers/pci/hotplug/ibmphp_pci.c - 1.2 drivers/pci/hotplug/ibmphp_res.c - 1.2 drivers/pci/pci-driver.c - 1.2 drivers/pci/pci.ids - 1.5 drivers/pci/pool.c - 1.2 drivers/pci/probe.c - 1.6 drivers/pci/remove.c - 1.3 drivers/pnp/Kconfig - 1.3 drivers/pnp/card.c - 1.2 drivers/pnp/isapnp/core.c - 1.2 drivers/pnp/manager.c - 1.2 drivers/pnp/pnpbios/Makefile - 1.2 drivers/pnp/pnpbios/core.c - 1.3 drivers/pnp/pnpbios/pnpbios.h - 1.2 drivers/pnp/pnpbios/rsparser.c - 1.2 drivers/pnp/resource.c - 1.2 drivers/s390/net/qeth.c - 1.3 drivers/scsi/Kconfig - 1.5 drivers/scsi/Makefile - 1.4 drivers/scsi/arm/acornscsi.c - 1.2 drivers/scsi/arm/acornscsi.h - 1.2 drivers/scsi/arm/arxescsi.c - 1.2 drivers/scsi/arm/cumana_2.c - 1.2 drivers/scsi/arm/eesox.c - 1.2 drivers/scsi/arm/powertec.c - 1.2 drivers/scsi/imm.c - 1.3 drivers/scsi/ppa.c - 1.3 drivers/scsi/qlogicfc.c - 1.3 drivers/scsi/qlogicfc.h - 1.3 drivers/scsi/qlogicfc_asm.c - 1.3 drivers/scsi/sg.c - 1.4 drivers/scsi/st.c - 1.4 drivers/serial/8250_pci.c - 1.2 drivers/serial/8250_pnp.c - 1.4 drivers/usb/Makefile - 1.4 drivers/usb/class/cdc-acm.c - 1.3 drivers/usb/core/Makefile - 1.2 drivers/usb/core/hcd.c - 1.3 drivers/usb/core/hcd.h - 1.2 drivers/usb/core/hub.c - 1.4 drivers/usb/core/usb-debug.c - 1.2 drivers/usb/core/usb.c - 1.4 drivers/usb/gadget/ether.c - 1.5 drivers/usb/gadget/net2280.c - 1.3 drivers/usb/host/ehci-hcd.c - 1.3 drivers/usb/host/hc_sl811_rh.c - 1.2 drivers/usb/host/ohci-hcd.c - 1.4 drivers/usb/host/ohci-hub.c - 1.2 drivers/usb/host/ohci-pci.c - 1.2 drivers/usb/host/ohci-q.c - 1.3 drivers/usb/host/ohci-sa1111.c - 1.2 drivers/usb/host/uhci-hcd.c - 1.4 drivers/usb/host/uhci-hcd.h - 1.2 drivers/usb/image/Kconfig - 1.2 drivers/usb/image/Makefile - 1.2 drivers/usb/image/scanner.c - 1.3 drivers/usb/image/scanner.h - 1.3 drivers/usb/input/Kconfig - 1.2 drivers/usb/input/hid-core.c - 1.4 drivers/usb/media/Kconfig - 1.4 drivers/usb/media/dsbr100.c - 1.2 drivers/usb/misc/Kconfig - 1.5 drivers/usb/misc/usbtest.c - 1.2 drivers/usb/misc/uss720.c - 1.2 drivers/usb/net/Kconfig - 1.3 drivers/usb/net/usbnet.c - 1.4 drivers/usb/serial/belkin_sa.c - 1.2 drivers/usb/serial/keyspan.h - 1.2 drivers/usb/serial/kobil_sct.c - 1.3 drivers/usb/serial/visor.c - 1.4 drivers/usb/serial/visor.h - 1.4 drivers/usb/storage/Kconfig - 1.2 drivers/usb/storage/datafab.h - 1.2 drivers/usb/storage/unusual_devs.h - 1.5 drivers/usb/storage/usb.c - 1.3 drivers/video/radeonfb.c - 1.3 fs/char_dev.c - 1.3 fs/dcache.c - 1.4 fs/nfs/dir.c - 1.3 fs/nfs/file.c - 1.3 fs/nfs/idmap.c - 1.2 fs/nfs/inode.c - 1.3 fs/nfs/nfs3proc.c - 1.2 fs/nfs/nfs4proc.c - 1.2 fs/nfs/nfs4renewd.c - 1.2 fs/nfs/nfs4state.c - 1.2 fs/nfs/nfs4xdr.c - 1.2 fs/nfs/proc.c - 1.2 fs/xattr.c - 1.6 include/acpi/processor.h - 1.3 include/asm-alpha/byteorder.h - 1.3 include/asm-ia64/iosapic.h - 1.2 include/asm-sparc/unistd.h - 1.2 include/asm-sparc64/unistd.h - 1.2 include/asm-v850/delay.h - 1.2 include/asm-v850/module.h - 1.2 include/linux/acpi.h - 1.2 include/linux/arcdevice.h - 1.2 include/linux/cdev.h - 1.2 include/linux/com20020.h - 1.2 include/linux/device.h - 1.4 include/linux/i2c-id.h - 1.4 include/linux/ide.h - 1.6 include/linux/if_bonding.h - 1.2 include/linux/input.h - 1.5 include/linux/ipv6.h - 1.4 include/linux/mod_devicetable.h - 1.2 include/linux/netdevice.h - 1.5 include/linux/nfs4.h - 1.2 include/linux/nfs_fs.h - 1.3 include/linux/nfs_fs_sb.h - 1.2 include/linux/nfs_idmap.h - 1.2 include/linux/nfs_page.h - 1.2 include/linux/nfs_xdr.h - 1.2 include/linux/pci.h - 1.4 include/linux/pci_ids.h - 1.5 include/linux/pnp.h - 1.2 include/linux/ptrace.h - 1.2 include/linux/slab.h - 1.2 include/linux/sunrpc/auth.h - 1.2 include/linux/sunrpc/clnt.h - 1.2 include/linux/sunrpc/gss_api.h - 1.2 include/linux/sunrpc/gss_krb5.h - 1.2 include/linux/sunrpc/rpc_pipe_fs.h - 1.2 include/linux/sunrpc/sched.h - 1.3 include/linux/sunrpc/xdr.h - 1.2 include/linux/sunrpc/xprt.h - 1.2 include/linux/sysctl.h - 1.5 include/linux/usb.h - 1.4 include/net/atmclip.h - 1.2 include/net/irda/irlap.h - 1.2 include/net/irda/irlmp.h - 1.2 include/net/sctp/constants.h - 1.3 ipc/util.c - 1.2 ipc/util.h - 1.2 kernel/sysctl.c - 1.4 lib/kobject.c - 1.3 mm/filemap.c - 1.5 mm/slab.c - 1.3 net/atm/clip.c - 1.4 net/bridge/br_if.c - 1.3 net/core/dev.c - 1.5 net/core/net-sysfs.c - 1.2 net/econet/af_econet.c - 1.4 net/ipv4/igmp.c - 1.4 net/ipv4/ipvs/Kconfig - 1.2 net/ipv4/ipvs/ip_vs_xmit.c - 1.2 net/ipv4/netfilter/ipt_REJECT.c - 1.3 net/ipv6/datagram.c - 1.3 net/ipv6/exthdrs.c - 1.4 net/ipv6/ip6_output.c - 1.4 net/ipv6/ipv6_sockglue.c - 1.3 net/ipv6/mcast.c - 1.4 net/ipv6/ndisc.c - 1.5 net/ipv6/netfilter/Kconfig - 1.2 net/irda/af_irda.c - 1.4 net/irda/irlmp.c - 1.2 net/irda/irlmp_event.c - 1.2 net/irda/irsyms.c - 1.2 net/packet/af_packet.c - 1.5 net/sched/Kconfig - 1.3 net/sctp/Kconfig - 1.2 net/sctp/Makefile - 1.2 net/sctp/adler32.c - 1.2 net/sctp/endpointola.c - 1.2 net/sctp/protocol.c - 1.3 net/sunrpc/auth.c - 1.2 net/sunrpc/auth_gss/auth_gss.c - 1.2 net/sunrpc/auth_gss/gss_krb5_crypto.c - 1.2 net/sunrpc/auth_gss/gss_krb5_mech.c - 1.2 net/sunrpc/auth_gss/gss_krb5_seal.c - 1.2 net/sunrpc/auth_gss/gss_krb5_unseal.c - 1.2 net/sunrpc/auth_gss/gss_mech_switch.c - 1.2 net/sunrpc/auth_gss/gss_pseudoflavors.c - 1.2 net/sunrpc/clnt.c - 1.2 net/sunrpc/pmap_clnt.c - 1.2 net/sunrpc/rpc_pipe.c - 1.2 net/sunrpc/sched.c - 1.2 net/sunrpc/sunrpc_syms.c - 1.2 net/sunrpc/xdr.c - 1.2 net/sunrpc/xprt.c - 1.2 net/unix/af_unix.c - 1.3 net/wanrouter/af_wanpipe.c - 1.2 scripts/file2alias.c - 1.2 sound/oss/harmony.c - 1.2 sound/pci/vx222/vx222_ops.c - 1.2 include/linux/pci_msi.h - 1.2 drivers/pci/msi.c - 1.2 drivers/ide/pci/sgiioc4.c - 1.4 drivers/scsi/qla2xxx/Kconfig - 1.3 drivers/scsi/qla2xxx/qla_dbg.c - 1.3 drivers/scsi/qla2xxx/qla_os.c - 1.3 drivers/usb/gadget/pxa2xx_udc.c - 1.2 drivers/usb/gadget/pxa2xx_udc.h - 1.2 lib/bitmap.c - 1.3 drivers/i2c/chips/w83l785ts.c - 1.2 drivers/base/class_simple.c - 1.2 drivers/usb/gadget/file_storage.c - 1.2 drivers/usb/host/ohci-omap.c - 1.2 drivers/ide/ide-generic.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Feb 9 21:35:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 21:35:55 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A5ZkKO014526 for ; Mon, 9 Feb 2004 21:35:47 -0800 Received: from antu (antu [131.142.25.237]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id i1A5Zk1l003267 for ; Tue, 10 Feb 2004 00:35:46 -0500 (EST) Date: Tue, 10 Feb 2004 00:35:46 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: Re: lilo help on RAID-1 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Hi, guys, I got the following warning about lilo use with XFS boot partition. I'd appreciate your thoughts about this issue: """ Your 'fstab' indicates that /boot is XFS. Although I do not use this filesystem, I am led to believe that sector 0, the boot sector, is used as a superblock for the filesystem. Hence, overwriting it will destroy the filesystem. This occurs for NTFS, and used to occur for DOS FAT. If XFS is now fixed, then you may ignore the following: Version 22 RAID-1 codes are not compatible with Version 21. This is detailed in "README.raid1". A compatible mode of operation will have to be used with NTFS & XFS: namely, the configuration file will have to contain: raid-extra-boot = mbr-only This will suppress the writing of the boot record to /dev/md0 (sector 0 of the XFS partition); but will, instead, write the boot records to /dev/hda and /dev/hdc (absolute sector 0 of each disk). 22.5.8 should already have cautioned you about the possible destruction of the XFS filesystem.""" From owner-linux-xfs@oss.sgi.com Mon Feb 9 22:35:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Feb 2004 22:35:40 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1A6ZIKO016620 for ; Mon, 9 Feb 2004 22:35:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1A5wHv1014302 for ; Mon, 9 Feb 2004 21:58:18 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1A5wDhI6872743; Tue, 10 Feb 2004 16:58:13 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1A5wCY66864901; Tue, 10 Feb 2004 16:58:12 +1100 (EST) Date: Tue, 10 Feb 2004 16:58:12 +1100 (EST) From: Nathan Scott Message-Id: <200402100558.i1A5wCY66864901@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 909260 - I/O path tracing X-archive-position: 2042 X-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 Add I/O path tracing code, 'twas useful in diagnosing that last unwritten extent problem and may be useful in other contexts as well. Date: Mon Feb 9 21:51:00 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166497a xfsidbg.c - 1.253 xfs_iomap.c - 1.23 linux-2.6/xfs_lrw.h - 1.42 linux-2.6/xfs_lrw.c - 1.203 linux-2.6/xfs_aops.c - 1.62 linux-2.4/xfs_lrw.h - 1.42 linux-2.4/xfs_lrw.c - 1.212 linux-2.4/xfs_aops.c - 1.70 From owner-linux-xfs@oss.sgi.com Tue Feb 10 02:16:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 02:17:04 -0800 (PST) Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [213.17.226.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AAGQKO027793 for ; Tue, 10 Feb 2004 02:16:33 -0800 Received: by goliath.sylaba.poznan.pl (Postfix, from userid 1003) id 987E595463; Tue, 10 Feb 2004 11:16:15 +0100 (CET) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by goliath.sylaba.poznan.pl (Postfix) with ESMTP id 28A099591C; Tue, 10 Feb 2004 11:16:09 +0100 (CET) Received: from venus.local.navi.pl (venus.local.navi.pl [127.0.0.1]) by venus.local.navi.pl (8.12.5/8.12.5) with ESMTP id i1AAIrFZ002724; Tue, 10 Feb 2004 11:18:53 +0100 Subject: Re: lilo help on RAID-1 (fwd) From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: gbakos@cfa.harvard.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 (1.0.8-10) Date: 10 Feb 2004 11:18:53 +0100 Message-Id: <1076408334.2260.8.camel@venus> Mime-Version: 1.0 X-archive-position: 2043 X-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 Tue, 2004-02-10 at 06:35, Gaspar Bakos wrote: > Hi, guys, > > I got the following warning about lilo use with XFS boot partition. I'd > appreciate your thoughts about this issue: > > """ > Your 'fstab' indicates that /boot is XFS. Although I do not use this > filesystem, I am led to believe that sector 0, the boot sector, is used as > a superblock for the filesystem. Hence, overwriting it will destroy the > filesystem. This occurs for NTFS, and used to occur for DOS FAT. > > If XFS is now fixed, then you may ignore the following: > > Version 22 RAID-1 codes are not compatible with Version 21. This is > detailed in "README.raid1". A compatible mode of operation will have to be > used with NTFS & XFS: namely, the configuration file will have to contain: > > raid-extra-boot = mbr-only > > This will suppress the writing of the boot record to /dev/md0 (sector 0 of > the XFS partition); but will, instead, write the boot records to /dev/hda > and /dev/hdc (absolute sector 0 of each disk). > > 22.5.8 should already have cautioned you about the possible destruction of > the XFS filesystem.""" > Hi, This is well known for long time. At least on this list :) And, AFAIR, it is not fixable. And it is not a bug. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Tue Feb 10 03:39:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 03:40:06 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1ABdcKO032241 for ; Tue, 10 Feb 2004 03:39:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1ABdXSL018393 for ; Tue, 10 Feb 2004 05:39:33 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1ABdVlE33926691; Tue, 10 Feb 2004 05:39:31 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AqWEk-0003xu-00; Tue, 10 Feb 2004 05:39:30 -0600 Subject: TAKE 908684 - make sure i_size_write is called under i_sem Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Tue, 10 Feb 2004 05:39:30 -0600 X-archive-position: 2044 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Feb 10 03:38:38 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166504a fs/xfs/linux-2.6/xfs_vnode.c - 1.121 - Don't update i_size in vn_revalidate fs/xfs/linux-2.6/xfs_iops.c - 1.213 - Update i_size in verify_fields and linvfs_setattr From owner-linux-xfs@oss.sgi.com Tue Feb 10 06:40:38 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 06:40:59 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AEeaKO010391 for ; Tue, 10 Feb 2004 06:40:37 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1AC2Fv1007277 for ; Tue, 10 Feb 2004 04:02:15 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1AC2ElE34020495; Tue, 10 Feb 2004 06:02:14 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AqWai-0004MJ-00; Tue, 10 Feb 2004 06:02:12 -0600 Subject: TAKE 908809 - use generic XFS stats and sysctl infrastructure in pagebuf Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Tue, 10 Feb 2004 06:02:12 -0600 X-archive-position: 2045 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Tue Feb 10 04:01:38 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166505a fs/xfs/linux-2.6/xfs_globals.c - 1.60 - add pagebuf sysctls fs/xfs/linux-2.6/xfs_linux.h - 1.119 - add pagebuf sysctls fs/xfs/linux-2.6/xfs_stats.c - 1.16 - add pagebuf statistics fs/xfs/linux-2.6/xfs_stats.h - 1.11 - add pagebuf statistics fs/xfs/linux-2.6/xfs_sysctl.c - 1.27 - add pagebuf sysctls fs/xfs/linux-2.6/xfs_sysctl.h - 1.21 - add pagebuf sysctls fs/xfs/linux-2.4/xfs_globals.c - 1.70 - add pagebuf sysctls fs/xfs/linux-2.4/xfs_linux.h - 1.129 - add pagebuf sysctls fs/xfs/linux-2.4/xfs_stats.c - 1.19 - add pagebuf statistics fs/xfs/linux-2.4/xfs_stats.h - 1.13 - add pagebuf statistics fs/xfs/linux-2.4/xfs_sysctl.c - 1.35 - add pagebuf sysctls fs/xfs/linux-2.4/xfs_sysctl.h - 1.26 - add pagebuf sysctls fs/xfs/linux-2.6/xfs_buf.c - 1.147 - use generic XFS statistics and sysctl infrastructure fs/xfs/linux-2.4/xfs_buf.c - 1.166 - use generic XFS statistics and sysctl infrastructure Modid: 2.6.x-xfs:linux:166505b Documentation/filesystems/xfs.txt - 1.3 - update for new sysctl locations From owner-linux-xfs@oss.sgi.com Tue Feb 10 11:34:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 11:34:51 -0800 (PST) Received: from danube.rivers.zai.com (zetaATTfw.zai.com [12.47.112.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AJYgKO030602 for ; Tue, 10 Feb 2004 11:34:43 -0800 Received: from danube.rivers.zai.com [127.0.0.1] by danube.rivers.zai.com with XWall v3.27 ; Tue, 10 Feb 2004 14:34:30 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: XFS_DB Problem (Corruption of in-memory data detected.) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 10 Feb 2004 14:34:29 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS_DB Problem (Corruption of in-memory data detected.) Thread-Index: AcPwDObWBnRZ5VMQRwauAnsnvcDnvA== From: "Smith, Andy P." To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1AJYhKO030619 X-archive-position: 2046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: smith-andy@zai.com Precedence: bulk X-list: linux-xfs Hi, I'm seeing problems with XFS 1.3.1 when using the xfs_db tool. I've tried several different combinations of kernels and hardware including: XFS Patched RedHat Kernel RPM (available from SGI directly) 2.4.22 XFS Patched Kernel HP 5i SCSI controllers HP 6400 SCSI controllers Dell Laptop (IDE) The problem occurs in every different combination of the above. It is very easy to produce the problem, the steps I use are: 1) induce moderate to heavy I/O on the XFS partition 2) use the xfs_db tool with a command like any of the following: xfs_db -ir /dev/hdc6 -c frag xfs_db -r /dev/hdc6 -c freesp xfs_db -ir /dev/cciss/c0d0p2 xfs_db> frag xfs_db> freesp I find that if I use the xfs_db commands a few times there is a high probability of partition errors and subsequent shutdown. In particular interactive usage of xfs_db (third example above) seems very prone to causing the problem. Errors like the following will show up in the system logs: kernel: xfs_force_shutdown(ide1(22,6),0x8) called from line 1070 of file xfs_trans.c. Return address = 0xe0e6db2b kernel: Filesystem "ide1(22,6)": Corruption of in-memory data detected. Shutting down filesystem: ide1(22,6) kernel: Please umount the filesystem, and rectify the problem(s) I find that my XFS partitions are generally very stable - however we hit these disks pretty hard and run xfs_fsr in a daily cron job to keep ahead of our fragmentation. I am using xfs_db to monitor fragmentation on the filesystems in question and this is obviously shaking my confidence in proceeding with XFS on our production filesystems. Anyone have any suggestions on steps to take to correct these problems and improve the stability? Thanks! -Andy Smith aps@zai.com From owner-linux-xfs@oss.sgi.com Tue Feb 10 11:37:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 11:37:19 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AJb9KO031243 for ; Tue, 10 Feb 2004 11:37:09 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Aqdgx-0002OY-HX; Tue, 10 Feb 2004 19:37:07 +0000 Date: Tue, 10 Feb 2004 19:37:07 +0000 From: Christoph Hellwig To: "Smith, Andy P." Cc: linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) Message-ID: <20040210193707.A9197@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from smith-andy@zai.com on Tue, Feb 10, 2004 at 02:34:29PM -0500 X-archive-position: 2047 X-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, Feb 10, 2004 at 02:34:29PM -0500, Smith, Andy P. wrote: > Hi, > > I'm seeing problems with XFS 1.3.1 when using the xfs_db tool. I've tried several different combinations of kernels and hardware including: Don't use xfs_db on the blockdevice while the filesystem is mounted currently. I'm looking into this issue curretnly but it's not easy to fix. On Linux 2.6 you'll even get a panic for that currently. From owner-linux-xfs@oss.sgi.com Tue Feb 10 13:01:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 13:02:07 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AL1jKO008813 for ; Tue, 10 Feb 2004 13:01:46 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1AKianq028623 for ; Tue, 10 Feb 2004 12:44:37 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1AKiZlb33993751; Tue, 10 Feb 2004 14:44:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1AKiUoZ074359; Tue, 10 Feb 2004 14:44:30 -0600 (CST) Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) From: Eric Sandeen To: "Smith, Andy P." Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1076445869.3435.31.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 10 Feb 2004 14:44:30 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2048 X-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 Tue, 2004-02-10 at 13:34, Smith, Andy P. wrote: > I find that my XFS partitions are generally very stable - however we > hit these disks pretty hard and run xfs_fsr in a daily cron job to > keep ahead of our fragmentation. I am using xfs_db to monitor > fragmentation on the filesystems in question and this is obviously > shaking my confidence in proceeding with XFS on our production > filesystems. Anyone have any suggestions on steps to take to correct > these problems and improve the stability? Christoph already replied with the "don't do that for now" answer, but I'm curious, do you see bad fragmentation in general? -Eric -- Eric Sandeen [C]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 Feb 10 14:43:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 14:44:06 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AMhsKO016763 for ; Tue, 10 Feb 2004 14:43:55 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Aqgbe-000335-DK; Tue, 10 Feb 2004 22:43:50 +0000 Date: Tue, 10 Feb 2004 22:43:50 +0000 From: Christoph Hellwig To: Jan Derfinak Cc: "Smith, Andy P." , linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) Message-ID: <20040210224350.A11692@infradead.org> References: <20040210193707.A9197@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: ; from ja@mail.upjs.sk on Tue, Feb 10, 2004 at 11:42:16PM +0100 X-archive-position: 2049 X-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, Feb 10, 2004 at 11:42:16PM +0100, Jan Derfinak wrote: > > On Linux 2.6 you'll even get a panic for that currently. > > > > I have used xfs_db in read-only mode on mounted partitions for long time and I > never had problem. I use 2.6 kernel now. What is wrong on read-only > access? The block device and XFS's metadata use the same pages but they don't talk to each other enough, so you can get into cases where a page used by XFS is flushed and the blockdevice code scribbles over the page which will get you inmemory corruption. From owner-linux-xfs@oss.sgi.com Tue Feb 10 14:57:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 14:57:45 -0800 (PST) Received: from alienAngel.upjs.sk (gprs150-111.eurotel.cz [160.218.150.111]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AMvQKO017930 for ; Tue, 10 Feb 2004 14:57:39 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id 06AC41C5; Tue, 10 Feb 2004 23:58:27 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id 044951C4; Tue, 10 Feb 2004 23:58:27 +0100 (CET) Date: Tue, 10 Feb 2004 23:58:26 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Christoph Hellwig Cc: "Smith, Andy P." , linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) In-Reply-To: <20040210224350.A11692@infradead.org> Message-ID: References: <20040210193707.A9197@infradead.org> <20040210224350.A11692@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs On Tue, 10 Feb 2004, Christoph Hellwig wrote: Hi. > > never had problem. I use 2.6 kernel now. What is wrong on read-only > > access? > > The block device and XFS's metadata use the same pages but they don't > talk to each other enough, so you can get into cases where a page used > by XFS is flushed and the blockdevice code scribbles over the page which > will get you inmemory corruption. > Thanks. I suggest to notice this in xfs_db man page. From description of '-r' option isn't clear that it is dangerous. jan -- From owner-linux-xfs@oss.sgi.com Tue Feb 10 15:03:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 15:03:56 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1AN3dKO018691 for ; Tue, 10 Feb 2004 15:03:40 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Aqgun-000378-Jz; Tue, 10 Feb 2004 23:03:37 +0000 Date: Tue, 10 Feb 2004 23:03:37 +0000 From: Christoph Hellwig To: Jan Derfinak Cc: "Smith, Andy P." , linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) Message-ID: <20040210230337.A11971@infradead.org> References: <20040210193707.A9197@infradead.org> <20040210224350.A11692@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: ; from ja@mail.upjs.sk on Tue, Feb 10, 2004 at 11:58:26PM +0100 X-archive-position: 2051 X-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, Feb 10, 2004 at 11:58:26PM +0100, Jan Derfinak wrote: > I suggest to notice this in xfs_db man page. From description of '-r' option > isn't clear that it is dangerous. It's not supposed to be dangerous :) The above is a bug in the XFS/Linux implemenation that needs to be fixed. From owner-linux-xfs@oss.sgi.com Tue Feb 10 16:58:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Feb 2004 16:59:13 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1B0wwKO030029 for ; Tue, 10 Feb 2004 16:58:58 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1B0wpW6022824 for ; Tue, 10 Feb 2004 16:58:52 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1B0sELi001681; Wed, 11 Feb 2004 11:54:14 +1100 Received: (from nathans@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1B0sDXH001680; Wed, 11 Feb 2004 11:54:13 +1100 Date: Wed, 11 Feb 2004 11:54:13 +1100 From: Nathan Scott Message-Id: <200402110054.i1B0sDXH001680@bruce.melbourne.sgi.com> Subject: TAKE 909260 - trivial tidying X-archive-position: 2052 X-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 Use a naming convention here thats more consistent with everything else. Date: Tue Feb 10 16:57:10 PST 2004 Workarea: bruce.melbourne.sgi.com:/source1/ptools/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166562a linux-2.6/xfs_aops.c - 1.63 linux-2.4/xfs_aops.c - 1.71 From owner-linux-xfs@oss.sgi.com Wed Feb 11 01:23:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 01:23:46 -0800 (PST) Received: from alienAngel.upjs.sk (styx.suse.cz [82.208.2.94]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1B9NAKO029309 for ; Wed, 11 Feb 2004 01:23:11 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id 8BF271A5; Tue, 10 Feb 2004 23:42:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id 5E117194; Tue, 10 Feb 2004 23:42:16 +0100 (CET) Date: Tue, 10 Feb 2004 23:42:16 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: Christoph Hellwig Cc: "Smith, Andy P." , linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) In-Reply-To: <20040210193707.A9197@infradead.org> Message-ID: References: <20040210193707.A9197@infradead.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2053 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs On Tue, 10 Feb 2004, Christoph Hellwig wrote: Hi. > On Tue, Feb 10, 2004 at 02:34:29PM -0500, Smith, Andy P. wrote: > > Hi, > > > > I'm seeing problems with XFS 1.3.1 when using the xfs_db tool. I've tried several different combinations of kernels and hardware including: > > Don't use xfs_db on the blockdevice while the filesystem is mounted > currently. I'm looking into this issue curretnly but it's not easy > to fix. > > On Linux 2.6 you'll even get a panic for that currently. > I have used xfs_db in read-only mode on mounted partitions for long time and I never had problem. I use 2.6 kernel now. What is wrong on read-only access? jan -- From owner-linux-xfs@oss.sgi.com Wed Feb 11 05:37:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 05:38:06 -0800 (PST) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BDbdKO014189 for ; Wed, 11 Feb 2004 05:37:40 -0800 Received: from PCB15.fit.vutbr.cz (PCB15.fit.vutbr.cz [147.229.13.165]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id i1BDbXRQ001574; Wed, 11 Feb 2004 14:37:33 +0100 (CET) Received: by PCB15.fit.vutbr.cz (Postfix, from userid 10048) id 58B44E9366; Wed, 11 Feb 2004 14:37:33 +0100 (CET) Date: Wed, 11 Feb 2004 14:37:33 +0100 From: David Jez To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: mkfs.xfs Message-ID: <20040211133733.GA3327@stud.fit.vutbr.cz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) X-archive-position: 2054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dave.jez@seznam.cz Precedence: bulk X-list: linux-xfs On Mon, Feb 09, 2004 at 10:34:42PM -0500, Gaspar Bakos wrote: > Hi, Hi, > I am creating XFS filesystem on a 750Gb partition, which is made up of > 4x250Gb WD disks in RAID-5 + 3ware card. System is RH9.0 with 2.4.23 > kernel and xfs patch as of 031010 from the oss.sgi site. > [...] > hdparm -tT /dev/sda > /dev/sda: > Timing buffer-cache reads: 128 MB in 0.20 seconds =640.00 MB/sec > Timing buffered disk reads: 64 MB in 1.55 seconds = 41.29 MB/sec > > It is OK, but I am not shocked by the performance. sda is one disk from array or whole array? I think this is normal behaviour. Raid 5 isn't raid0 and is quite slow (and realy slow for writting operations)... > Are there any recommended tests to test the filesystem before starting to > populate it with all that 750Gb of data? Stress operations with big files and many small files can help. Try it under filesystem and direct disk access. > > All the best > Gaspar -- ------------------------------------------------------- David "Dave" Jez Brno, CZ, Europe E-mail: dave.jez@seznam.cz PGP key: finger xjezda00@eva.fit.vutbr.cz ---------=[ ~EOF ]=------------------------------------ From owner-linux-xfs@oss.sgi.com Wed Feb 11 06:53:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 06:54:21 -0800 (PST) Received: from danube.rivers.zai.com (zetaATTfw.zai.com [12.47.112.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BErpKO017983 for ; Wed, 11 Feb 2004 06:53:52 -0800 Received: from danube.rivers.zai.com [127.0.0.1] by danube.rivers.zai.com with XWall v3.27 ; Wed, 11 Feb 2004 09:53:39 -0500 Subject: RE: XFS_DB Problem (Corruption of in-memory data detected.) MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Date: Wed, 11 Feb 2004 09:53:39 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS_DB Problem (Corruption of in-memory data detected.) Thread-Index: AcPwKcrtMoaYGsNXRDWshzD52dw1MwAhA6Z8 From: "Smith, Andy P." To: "Jan Derfinak" , "Christoph Hellwig" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1BErqKO018005 X-archive-position: 2055 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: smith-andy@zai.com Precedence: bulk X-list: linux-xfs Jan, In case you're curious I encountered this problem most frequently (and reproduced it most easily) by using xfs_db interactively whilst performing a lot of I/O (mostly writes) on the same partition. It was much harder to reproduce the problem when running a one-off command like 'xfs_db -r /dev/sda1 -c frag' or similar. However I did find that I could cause it eventually if I ran that type of command repeatedly in a loop. I found xfs_db to be a useful tool so hopefully this will get fixed soon! :-) Cheers, -Andy -----Original Message----- From: Jan Derfinak [mailto:ja@mail.upjs.sk] Sent: Tue 2/10/2004 5:58 PM To: Christoph Hellwig Cc: Smith, Andy P.; linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) On Tue, 10 Feb 2004, Christoph Hellwig wrote: Hi. > > never had problem. I use 2.6 kernel now. What is wrong on read-only > > access? > > The block device and XFS's metadata use the same pages but they don't > talk to each other enough, so you can get into cases where a page used > by XFS is flushed and the blockdevice code scribbles over the page which > will get you inmemory corruption. > Thanks. I suggest to notice this in xfs_db man page. From description of '-r' option isn't clear that it is dangerous. jan -- From owner-linux-xfs@oss.sgi.com Wed Feb 11 06:59:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 06:59:45 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BExYKO018772 for ; Wed, 11 Feb 2004 06:59:35 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Aqvps-0005Ad-4z; Wed, 11 Feb 2004 14:59:32 +0000 Date: Wed, 11 Feb 2004 14:59:32 +0000 From: Christoph Hellwig To: "Smith, Andy P." Cc: Jan Derfinak , linux-xfs@oss.sgi.com Subject: Re: XFS_DB Problem (Corruption of in-memory data detected.) Message-ID: <20040211145931.A19863@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from smith-andy@zai.com on Wed, Feb 11, 2004 at 09:53:39AM -0500 X-archive-position: 2056 X-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, Feb 11, 2004 at 09:53:39AM -0500, Smith, Andy P. wrote: > Jan, > > In case you're curious I encountered this problem most frequently (and reproduced it most easily) by using xfs_db interactively whilst performing a lot of I/O (mostly writes) on the same partition. Yes, this is exactly the expected patter - if you don't actually write to the filesystems the overwriting caused by the blockdevice doesn't matter. From owner-linux-xfs@oss.sgi.com Wed Feb 11 10:37:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 10:37:46 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BIb8KO002474 for ; Wed, 11 Feb 2004 10:37:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1BIb2sM026888 for ; Wed, 11 Feb 2004 12:37:02 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1BIb2e134001544; Wed, 11 Feb 2004 12:37:02 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1BIb1kP1498670; Wed, 11 Feb 2004 12:37:01 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i1BIb09i8169144; Wed, 11 Feb 2004 12:37:01 -0600 (CST) Message-Id: <200402111837.i1BIb09i8169144@clink.americas.sgi.com> To: Mike Montour cc: linux-xfs@oss.sgi.com Subject: Re: dm_write_invis() blocking problem Date: Wed, 11 Feb 2004 12:37:00 -0600 From: Dean Roehrich X-archive-position: 2057 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs >From: Mike Montour >I am developing an application using XFS/DMAPI on Linux 2.4. > >My application registers for DM_EVENT_READ and DM_EVENT_WRITE events >on a file, then calls dm_punch_hole() on that file. The event handlers >use dm_write_invis() to re-populate the file data on demand (including >re-populating all of the original file data before allowing the >first write operation to continue). > >This works fine for READ events. However, whenever I get a WRITE >event, the call to dm_write_invis() blocks my program. If I kill >(ctrl-C) the application that triggered the WRITE event, then the >dm_write_invis() call returns successfully and my program continues. Hmm, I guess I'd better dust off my email folders once in a while. Sorry to respond so late. I'm currently testing the following patch, which should alleviate the hang. The problem is that a thread was able to get into the dmapi queues while holding a resource (i_sem, in this case). Dean =========================================================================== dmapi/dmapi_xfs.c =========================================================================== --- /usr/tmp/TmpDir.4852600-0/dmapi/dmapi_xfs.c_1.28 Wed Feb 4 16:21:21 2004 +++ dmapi/dmapi_xfs.c Wed Feb 4 15:38:34 2004 @@ -136,6 +136,7 @@ bhv_desc_t *bdp; xfs_inode_t *ip; uint16_t dmstate; + struct inode *inode = LINVFS_GET_IP(vp); XFS_BHV_LOOKUP(vp, bdp); ip = XFS_BHVTOI(bdp); @@ -143,8 +144,24 @@ dmstate = ip->i_iocore.io_dmstate; if (locktype) xfs_rwunlock(bdp, *locktype); + + if (flags & DM_FLAGS_ISEM) + up(&inode->i_sem); +#ifdef DM_FLAGS_IALLOCSEM + else if (flags & DM_FLAGS_IALLOCSEM) + do_up_read(&inode->i_alloc_sem); +#endif + error = dm_send_data_event(event, vp, DM_RIGHT_NULL, offset, length, flags); + + if (flags & DM_FLAGS_ISEM) + down(&inode->i_sem); +#ifdef DM_FLAGS_IALLOCSEM + else if (flags & DM_FLAGS_IALLOCSEM) + do_down_read(&inode->i_alloc_sem); +#endif + if (locktype) xfs_rwlock(bdp, *locktype); } while (!error && (ip->i_iocore.io_dmstate != dmstate)); =========================================================================== linux-2.4/xfs_lrw.c =========================================================================== --- /usr/tmp/TmpDir.4852600-0/linux-2.4/xfs_lrw.c_1.211 Wed Feb 4 16:21:21 2004 +++ linux-2.4/xfs_lrw.c Wed Feb 4 15:11:19 2004 @@ -311,9 +311,10 @@ !(ioflags & IO_INVIS)) { int error; vrwlock_t locktype = VRWLOCK_READ; + int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG(ioflags); error = XFS_SEND_DATA(mp, DM_EVENT_READ, BHV_TO_VNODE(bdp), *offset, size, - FILP_DELAY_FLAG(file), &locktype); + dmflags, &locktype); if (error) { if (!(ioflags & IO_ISLOCKED)) xfs_iunlock(ip, XFS_IOLOCK_SHARED); @@ -649,11 +650,12 @@ if ((DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS) && !eventsent)) { loff_t savedsize = *offset; + int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG(ioflags); xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, *offset, size, - FILP_DELAY_FLAG(file), &locktype); + dmflags, &locktype); if (error) { if (iolock) xfs_iunlock(xip, iolock); return -error; =========================================================================== linux-2.6/xfs_lrw.c =========================================================================== --- /usr/tmp/TmpDir.4852600-0/linux-2.6/xfs_lrw.c_1.202 Wed Feb 4 16:21:21 2004 +++ linux-2.6/xfs_lrw.c Wed Feb 4 15:11:19 2004 @@ -738,11 +738,12 @@ if ((DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS) && !eventsent)) { loff_t savedsize = *offset; + int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG(ioflags); xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, *offset, size, - FILP_DELAY_FLAG(file), &locktype); + dmflags, &locktype); if (error) { if (iolock) xfs_iunlock(xip, iolock); return -error; =========================================================================== xfs_dmapi.h =========================================================================== --- /usr/tmp/TmpDir.4852600-0/xfs_dmapi.h_1.43 Wed Feb 4 16:21:21 2004 +++ xfs_dmapi.h Wed Feb 4 16:15:03 2004 @@ -165,6 +165,24 @@ #define DM_FLAGS_NDELAY 0x001 /* return EAGAIN after dm_pending() */ #define DM_FLAGS_UNWANTED 0x002 /* event not in fsys dm_eventset_t */ +#define DM_FLAGS_ISEM 0x004 /* thread holds i_sem */ +#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) +#if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,21) +/* i_alloc_sem was added in 2.4.22-pre1 */ +#define DM_FLAGS_IALLOCSEM 0x010 /* thread holds i_alloc_sem */ +#endif +#endif + +/* + * Based on IO_ISDIRECT, decide which i_ flag is set. + */ +#ifdef DM_FLAGS_IALLOCSEM +#define DM_SEM_FLAG(ioflags) (((ioflags) & IO_ISDIRECT) ? \ + DM_FLAGS_IALLOCSEM : DM_FLAGS_ISEM) +#else +#define DM_SEM_FLAG(ioflags) (((ioflags) & IO_ISDIRECT) ? \ + 0 : DM_FLAGS_ISEM) +#endif /* * Macros to turn caller specified delay/block flags into From owner-linux-xfs@oss.sgi.com Wed Feb 11 12:14:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 12:15:21 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BKEwKO009775 for ; Wed, 11 Feb 2004 12:14:59 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1BKErsM021207 for ; Wed, 11 Feb 2004 14:14:53 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1BKEqe134065781; Wed, 11 Feb 2004 14:14:52 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ar0l1-0007AN-00; Wed, 11 Feb 2004 14:14:51 -0600 Subject: TAKE 908003 - Fix dmapi for Linux 2.6 Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Wed, 11 Feb 2004 14:14:51 -0600 X-archive-position: 2058 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Feb 11 12:14:31 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166613a fs/xfs/dmapi/dmapi_xfs.c - 1.29 - abstract out a little code for Linux 2.4 vs 2.6 fs/xfs/dmapi/dmapi_sysent.c - 1.26 - add Linux 2.6 ifdefs fs/xfs/dmapi/dmapi_register.c - 1.32 - add Linux 2.6 ifdefs From owner-linux-xfs@oss.sgi.com Wed Feb 11 14:11:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 14:12:01 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BMBaKO028950 for ; Wed, 11 Feb 2004 14:11:37 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1BMATjq011013 for ; Wed, 11 Feb 2004 14:10:30 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1BM96hI7678048 for ; Thu, 12 Feb 2004 09:09:06 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1BM95TB2846328 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 09:09:05 +1100 (EST) Date: Thu, 12 Feb 2004 09:09:05 +1100 (EST) From: Nathan Scott Message-Id: <200402112209.i1BM95TB2846328@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 908809 - 2.6 docs tweak X-archive-position: 2059 X-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 Yank a reference to the removed pagebuf trace sysctl/procfs entry. Date: Wed Feb 11 14:07:50 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166621a fs/Kconfig - 1.6 From owner-linux-xfs@oss.sgi.com Wed Feb 11 14:25:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 14:25:55 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BMPlKO032084 for ; Wed, 11 Feb 2004 14:25:48 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1BMPfsM027658 for ; Wed, 11 Feb 2004 16:25:41 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1BMPdhI6988500 for ; Thu, 12 Feb 2004 09:25:39 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1BMPcqf7718701 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 09:25:38 +1100 (EST) Date: Thu, 12 Feb 2004 09:25:38 +1100 (EST) From: Nathan Scott Message-Id: <200402112225.i1BMPcqf7718701@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.25-rc2 X-archive-position: 2060 X-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: Wed Feb 11 14:25:03 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:166623a MAINTAINERS - 1.5 Makefile - 1.8 arch/sparc64/lib/VIScopy.S - 1.2 drivers/acpi/asus_acpi.c - 1.3 drivers/acpi/dispatcher/dsmthdat.c - 1.3 drivers/acpi/pci_irq.c - 1.2 drivers/acpi/toshiba_acpi.c - 1.3 drivers/char/hvc_console.c - 1.2 drivers/char/tty_io.c - 1.2 drivers/isdn/hisax/amd7930_fn.c - 1.3 drivers/pcmcia/yenta.c - 1.2 drivers/video/sstfb.c - 1.2 fs/inode.c - 1.3 fs/jfs/jfs_logmgr.c - 1.3 fs/jfs/jfs_txnmgr.c - 1.2 fs/jfs/namei.c - 1.2 include/linux/sysctl.h - 1.4 lib/vsprintf.c - 1.2 net/ipv4/devinet.c - 1.3 net/socket.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Feb 11 15:15:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 15:16:08 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1BNFoKO011789 for ; Wed, 11 Feb 2004 15:15:51 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1BNFj6Z009483 for ; Wed, 11 Feb 2004 17:15:45 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1BNFiLB34063181; Wed, 11 Feb 2004 17:15:44 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ar3a3-0000uj-00; Wed, 11 Feb 2004 17:15:43 -0600 Subject: TAKE 908684 - Remove a superflous i_size_write Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Wed, 11 Feb 2004 17:15:43 -0600 X-archive-position: 2061 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Wed Feb 11 15:15:26 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166629a fs/xfs/linux-2.6/xfs_iops.c - 1.214 - vmtruncate() does the i_size_write for use From owner-linux-xfs@oss.sgi.com Wed Feb 11 16:30:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 16:30:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1C0U5KO027179 for ; Wed, 11 Feb 2004 16:30:05 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1C0U5ZO027178 for linux-xfs@oss.sgi.com; Wed, 11 Feb 2004 16:30:05 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1C0U4KS027156 for ; Wed, 11 Feb 2004 16:30:04 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1BNu5pw018920; Wed, 11 Feb 2004 15:56:05 -0800 Date: Wed, 11 Feb 2004 15:56:05 -0800 Message-Id: <200402112356.i1BNu5pw018920@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 driver@jpl.nasa.gov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |driver@jpl.nasa.gov ------- Additional Comments From driver@jpl.nasa.gov 2004-11-02 15:56 PDT ------- I got this error as well on a mandrake kernel. The kernel that had the problem started when we switched to 2.4.19-37mdkenterprise. Since this is a production server we reverted back to vmlinuz-2.4.19-36mdkenterprise. If we get the error again I'll try to send in more data.... Feb 8 21:02:06 micro kernel: xfs_inotobp: xfs_imap() returned an error 22 on sd(8,5). Returning error. Feb 8 21:02:06 micro kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd(8,5). Returning error. Feb 8 21:02:06 micro kernel: xfs_inactive: xfs_ifree() returned an error = 22 on sd(8,5) Feb 8 21:02:06 micro kernel: xfs_force_shutdown(sd(8,5),0x1) called from line 1952 of file xfs_vnodeops.c. Return address = 0xf88bacb3 Feb 8 21:02:06 micro kernel: I/O Error Detected. Shutting down filesystem: sd(8,5) Feb 8 21:02:06 micro kernel: Please umount the filesystem, and rectify the problem(s) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 11 19:37:02 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 19:37:26 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1C3b1KO026235 for ; Wed, 11 Feb 2004 19:37:02 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1C3as6Z016020 for ; Wed, 11 Feb 2004 21:36:55 -0600 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA00978 for ; Thu, 12 Feb 2004 14:36:53 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1C3ar7a017421 for ; Thu, 12 Feb 2004 14:36:53 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1C3arQm017419 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 14:36:53 +1100 Date: Thu, 12 Feb 2004 14:36:53 +1100 From: Tim Shimmin Message-Id: <200402120336.i1C3arQm017419@sherman.melbourne.sgi.com> Subject: PARTIAL TAKE 907752 - update some log QA Apparently-To: X-archive-position: 2063 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Simplify and hopefully make more repeatable log/logprint QA testing. While in QA get 063 working again with common.dump mod. --Tim Date: Wed Feb 11 19:30:50 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166651a xfstests/018.trans_inode - 1.1 - moved from 018.noquota.trans_inode. filtered logprint output for trans_inode xfstests/018.op - 1.1 - moved from 018.noquota.op. Some filtered operation output. xfstests/082.trans_inode - 1.1 - Moved from 082.noquota.trans_inode. New filtering. xfstests/082.trans_buf - 1.1 - Moved from 082.noquota.trans_buf. New filtering. xfstests/018.trans_buf - 1.1 - moved from 018.noquota.trans_buf. filtered logprint output for trans_bufs xfstests/082.op - 1.1 - Moved from 082.noquota.op. New filtering. xfstests/018 - 1.27 - Get rid of unnecessary noquota suffix in name. xfstests/common.dump - 1.46 - Move the XFS_XFLAG_* file attr flags out of the ea config code since they are NOT EAs and put them in a separate _mk_fillconfig_xattr() function. TODO: need to update the config processing in common.dump to call xfs_io to set the xattr flags via the ioctl. Also need to write a new QA test to make the calls into here. xfstests/group - 1.50 - Add a log group and add some log tests to the auto group. xfstests/018.out - 1.6 xfstests/018.noquota.op - 1.3 xfstests/018.noquota.trans_inode - 1.3 xfstests/018.noquota.trans_buf - 1.3 - Get rid of unnecessary noquota suffix in name. xfstests/082 - 1.2 - Get rid of noquota suffix. Formatting changes. Take out the _notrun call now. xfstests/common.log - 1.3 - Fix up the filtering so that it can handle flushing out of data and flushing out of iclogs at different times still allow repeatable comparisons. xfstests/082.out - 1.2 - Get rid of noquota suffix. xfstests/081.ugquota.trans_inode - 1.2 - Update for new filtering from common.log used to get repeatability. xfstests/082.noquota.trans_inode - 1.2 xfstests/082.noquota.op - 1.2 xfstests/082.noquota.trans_buf - 1.2 - Get rid of noquota suffix. xfstests/085 - 1.2 - Don't need common.log as we don't do logprint filtering - just check for clean or dirty log. From owner-linux-xfs@oss.sgi.com Wed Feb 11 20:30:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Feb 2004 20:30:09 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1C4U6KO006574 for ; Wed, 11 Feb 2004 20:30:06 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1C4U6vD006573 for linux-xfs@oss.sgi.com; Wed, 11 Feb 2004 20:30:06 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1C4U4KS006557 for ; Wed, 11 Feb 2004 20:30:04 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1C4Fepa000707; Wed, 11 Feb 2004 20:15:40 -0800 Date: Wed, 11 Feb 2004 20:15:40 -0800 Message-Id: <200402120415.i1C4Fepa000707@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From sandeen@sgi.com 2004-11-02 20:15 PDT ------- If you are fairly certain that you see it in one kernel and not the other, and you have the source for both handy, could you put the diff of fs/xfs between the two somewhere? not sure how big it might be... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 12 01:47:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 01:47:51 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1C9lOKO028482 for ; Thu, 12 Feb 2004 01:47:25 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1C9lIvm001239 for ; Thu, 12 Feb 2004 03:47:18 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1C9lHKP33932075; Thu, 12 Feb 2004 03:47:17 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1ArDRD-0004Jv-00; Thu, 12 Feb 2004 03:47:15 -0600 Subject: TAKE 909442 - Fix up daemon names Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Thu, 12 Feb 2004 03:47:15 -0600 X-archive-position: 2065 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Feb 12 01:46:51 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166665a fs/xfs/linux-2.6/xfs_super.c - 1.296 - name the synch thread xfssyncd, as in 2.4 fs/xfs/linux-2.6/xfs_buf.c - 1.148 - rename pagebufd to xfsbufd fs/xfs/linux-2.4/xfs_buf.c - 1.167 - rename pagebufd to xfsbufd From owner-linux-xfs@oss.sgi.com Thu Feb 12 07:55:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 07:55:45 -0800 (PST) Received: from server7.nfra.nl (server7.nfra.nl [192.87.1.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1CFtYKO000951 for ; Thu, 12 Feb 2004 07:55:36 -0800 Received: from wop10.nfra.nl [195.169.63.130] by server7.nfra.nl; Thu, 12 Feb 2004 16:56:06 +0100 Date: Thu, 12 Feb 2004 15:55:10 +0000 (UTC) From: Ramesh K X-X-Sender: kram@wop10.nfra.nl To: Nathan Scott cc: Steve Lord , Subject: Re: problems with real-time option. In-Reply-To: <20030826220532.GA769@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kram@astron.nl Precedence: bulk X-list: linux-xfs Hello, I'm trying to use realtime subvolumes under Linux (SuSE 8.1, running kernel 2.4.19-64GB-SMP (I know it is very old!!) The hardware: I'm using a 3ware RAID controller, and am using RAID level 0 (all eight 120GByte disks together are seen as one disk of 960 GByte device). Now I want to use this entire 960 GBytes for my realtime data, and want to place metadata on ramdisk. When I try: dop93:> mkfs -t xfs -f -d unwritten=0 -r rtdev=/dev/sda1 /dev/ram1, I get warnings on block size of ramdisk. And when I try to mount the device with: mount -t xfs -o rtdev /dev/sda1 - the call never returns. Am I doing something very gross? Thanks. -Ramesh > On Tue, Aug 26, 2003 at 07:10:02AM -0500, Steve Lord wrote: > > On Tue, 2003-08-26 at 05:29, K Ramesh wrote: > > > > > > Hi, > > > I'm trying to create a real-time subvolume in my Linux System, running > > > SuSE 8.1 (Kernel: 2.4.19-64GB-SMP) on a dual-xeon PC. The system has a 3ware > > > ATA-Raid controller. > > > > > > When I try to create a real-time subvolume, this what I get: > > > > > > wop18:~ # mkfs -t xfs -f -r rtdev=/dev/sda6 /dev/sda5 > > > meta-data=/dev/sda5 isize=256 agcount=49, agsize=1048576 blks > > > data = bsize=4096 blocks=51201147, imaxpct=25 > > > = sunit=0 swidth=0 blks, unwritten=0 > > > naming =version 2 bsize=4096 > > > log =internal log bsize=4096 blocks=6250, version=1 > > > = sunit=0 blks > > > realtime =/dev/sda6 extsz=65536 blocks=183237382, > > > rtextents=11452336 > > > XFS: This FS has an RT subvol - specify -o rtdev on mount > > > mkfs.xfs: real-time device init failed > > > mkfs.xfs: filesystem failed to initialize > > Get a new xfsprogs while you're at it, that'll resolve this error. > > > ... > > Your kernel is almost that old ;-) Realtime should be working in recent > > kernels, be aware you need to use O_DIRECT to write to realtime > > subvolumes. > > cheers. > > -- > Nathan > > ************************************************************************** Ramesh K (Mo/Tu): Radiosterrenwacht Westerbork, Schattenburg 1, 9433 TA Zwiggelte. ph: +31-(0)593-598755 fax:+31-(0)593-592486 (We/Th/Fr): Stitching Astron, Oude Hoogeveensedijk 4, 7991 PD Dwingeloo. ph: +31-(0)521-595255 fax:+31-(0)521-597332 ************************************************************************** From owner-linux-xfs@oss.sgi.com Thu Feb 12 09:09:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 09:09:28 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1CH96KO011116 for ; Thu, 12 Feb 2004 09:09:06 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1CGx5ZL023130 for ; Thu, 12 Feb 2004 08:59:05 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1CGvcOa34122671 for ; Thu, 12 Feb 2004 10:57:38 -0600 (CST) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1ArK9i-0006n0-00 for ; Thu, 12 Feb 2004 10:57:38 -0600 Date: Thu, 12 Feb 2004 10:57:37 -0600 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: Re: problems with real-time option. Message-ID: <20040212165737.GC22230@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20030826220532.GA769@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 2067 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nstraz@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Feb 12, 2004 at 03:55:10PM +0000, Ramesh K wrote: > I'm trying to use realtime subvolumes under Linux (SuSE 8.1, running > kernel 2.4.19-64GB-SMP (I know it is very old!!) > The hardware: I'm using a 3ware RAID controller, and am using RAID level > 0 (all eight 120GByte disks together are seen as one disk of 960 GByte device). > Now I want to use this entire 960 GBytes for my realtime data, and want > to place metadata on ramdisk. ... > Am I doing something very gross? Thanks. So when you reboot the system or it crashes you lose all of your data. I'd call that gross, but I don't know how much your data is worth. -- 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 Thu Feb 12 13:30:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 13:30:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1CLUBKO026304 for ; Thu, 12 Feb 2004 13:30:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1CLUBMG026301 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 13:30:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1CLU7KY026255 for ; Thu, 12 Feb 2004 13:30:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1CLRCJb026140; Thu, 12 Feb 2004 13:27:12 -0800 Date: Thu, 12 Feb 2004 13:27:12 -0800 Message-Id: <200402122127.i1CLRCJb026140@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From driver@jpl.nasa.gov 2004-12-02 13:27 PDT ------- more info: [root@micro log]# xfs_info / meta-data=/ isize=256 agcount=8, agsize=223905 blks data = bsize=4096 blocks=1791239, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 The machine is a dual Pentium4 XEON 1.7Ghz w1GB/ram, this error is reproducable with both highmem and no-highmem kernels. Have not tried a uni-proc kernel. We never has this error untill we upgraded the kernel from 2.4.19-36mdkenterprise to 2.4.19-37mdkenterprise. But now all kernels have this problem. I'll try to get a diff between the 2 kernel sources and post it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 12 13:30:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 13:30:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1CLUBKO026305 for ; Thu, 12 Feb 2004 13:30:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1CLUBM1026300 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 13:30:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1CLU7KS026255 for ; Thu, 12 Feb 2004 13:30:08 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1CLLhPN026054; Thu, 12 Feb 2004 13:21:43 -0800 Date: Thu, 12 Feb 2004 13:21:43 -0800 Message-Id: <200402122121.i1CLLhPN026054@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From driver@jpl.nasa.gov 2004-12-02 13:21 PDT ------- BTW, this is the log of what happens when xfsdump is ran: Feb 12 11:18:36 micro kernel: xfs_inotobp: xfs_imap() returned an error 22 on sd(8,5). Returning error. Feb 12 11:18:36 micro kernel: xfs_iunlink_remove: xfs_inotobp() returned an error 22 on sd(8,5). Returning error. Feb 12 11:18:36 micro kernel: xfs_inactive: xfs_ifree() returned an error = 22 on sd(8,5) Feb 12 11:18:36 micro kernel: xfs_force_shutdown(sd(8,5),0x1) called from line 1952 of file xfs_vnodeops.c. Return address = 0xfc8bbcb3 Feb 12 11:18:36 micro kernel: I/O Error Detected. Shutting down filesystem: sd(8,5) Feb 12 11:18:36 micro kernel: Please umount the filesystem, and rectify the problem(s) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 12 13:30:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 13:30:26 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1CLUBKO026306 for ; Thu, 12 Feb 2004 13:30:11 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1CLUBK2026303 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 13:30:11 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1CLU7Ke026255 for ; Thu, 12 Feb 2004 13:30:09 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1CLJM9O025998; Thu, 12 Feb 2004 13:19:22 -0800 Date: Thu, 12 Feb 2004 13:19:22 -0800 Message-Id: <200402122119.i1CLJM9O025998@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From driver@jpl.nasa.gov 2004-12-02 13:19 PDT ------- I got the error on the old kernel as well. I can reproduce easily with xfsdump. Here is the output of xfsdump: xfsdump: using file dump (drive_simple) strategy xfsdump: version 3.0 - Running single-threaded xfsdump: WARNING: no session label specified xfsdump: level 0 dump of micro.jpl.nasa.gov:/ xfsdump: dump date: Thu Feb 12 11:18:21 2004 xfsdump: session id: d0d6ffd2-60bd-4c96-9a69-6ae71f242f00 xfsdump: session label: "" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: WARNING: failed to get bulkstat information for inode 29360279 xfsdump: WARNING: failed to get bulkstat information for inode 29360289 xfsdump: WARNING: failed to get bulkstat information for inode 29360295 xfsdump: syssgi( SGI_FS_BULKSTAT ) on fsroot failed: Input/output error xfsdump: Dump Status: ERROR I ran badblocks on this disk (read-only) and it found no errors with the disk. I didn't have time to-do a read-write test nor can I destroy data on the partition. I ran xfs repair and got this: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... zero_log: head block 3029 tail block 3029 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 data fork in regular inode 3523176 claims used block 223904 xfs_repair: dinode.c:2429: process_dinode_int: Assertion `err == 0' failed. Let me know what else I can do? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 12 14:01:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 14:01:34 -0800 (PST) Received: from bycast.com (bycast.com [207.61.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1CM1TKO027967 for ; Thu, 12 Feb 2004 14:01:29 -0800 Received: from bycast.com (24.87.12.250) by bycast.com with ESMTP (Eudora Internet Mail Server 3.0); Thu, 12 Feb 2004 14:02:07 -0700 Message-ID: <402BF7B5.2040109@bycast.com> Date: Thu, 12 Feb 2004 14:01:25 -0800 From: Mike Montour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: dm_write_invis() blocking problem References: <200402111837.i1BIb09i8169144@clink.americas.sgi.com> In-Reply-To: <200402111837.i1BIb09i8169144@clink.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: linux-xfs Dean Roehrich wrote: > I'm currently testing the following patch, which should alleviate the > hang. > >The problem is that a thread was able to get into the dmapi queues while >holding a resource (i_sem, in this case). > >Dean > > Thank you for the patch. It fixes my DM_EVENT_WRITE problem. However, I can trigger a similar situation by calling dm_write_invis() while processing a TRUNCATE event. A co-worker has been helping me test this using KDB, and I've attached his notes. Also, when the patch is applied to a current checkout of the SGI CVS tree (pserver:cvs@oss.sgi.com:/cvs), there is a link failure: fs/fs.o: In function `xfs_dm_send_data_event': fs/fs.o(.text+0xac8fb): undefined reference to `do_up_read' fs/fs.o(.text+0xac94b): undefined reference to `do_down_read' make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/local/tmp/linux-2.4-xfs' make: *** [vmlinux] Error 2 I worked around this by pasting two lines from linux-2.4/xfs_file.c into dmapi/dmapi_xfs.c: #define do_down_read(x) down_read(x) #define do_up_read(x) up_read(x) -Mike From owner-linux-xfs@oss.sgi.com Thu Feb 12 14:06:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 14:06:07 -0800 (PST) Received: from bycast.com (bycast.com [207.61.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1CM64KO028435 for ; Thu, 12 Feb 2004 14:06:04 -0800 Received: from bycast.com (24.87.12.250) by bycast.com with ESMTP (Eudora Internet Mail Server 3.0); Thu, 12 Feb 2004 14:06:45 -0700 Message-ID: <402BF8CA.7060306@bycast.com> Date: Thu, 12 Feb 2004 14:06:02 -0800 From: Mike Montour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: dm_write_invis() blocking problem References: <200402111837.i1BIb09i8169144@clink.americas.sgi.com> <402BF7B5.2040109@bycast.com> In-Reply-To: <402BF7B5.2040109@bycast.com> Content-Type: multipart/mixed; boundary="------------050606020005080709000607" X-archive-position: 2070 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------050606020005080709000607 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Mike Montour wrote: (attachment that should've been on my previous msg) --------------050606020005080709000607 Content-Type: text/plain; name="kerndeb2.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kerndeb2.txt" dmapi test program linux:~ # ./dmapi_test SGI DMAPI (XDSM) API, Release 1.0. Waiting for event... Got DM_EVENT_TRUNCATE, de_offset 0, de_length 0 Requesting DM_RIGHT_EXCL Calling dm_write_invis() what the kernel debugger says 0xdf35e000 6215 6096 0 0 D 0xdf35e270 dmapi_test EBP EIP Function (args) 0xdf35fd1c 0xc0117b77 schedule+0x227 (0x1, 0xdf35e000, 0xe42b537c, 0xe42b537c, 0xe42b5374) kernel .text 0xc0100000 0xc0117950 0xc0117c90 0xdf35fd40 0xc0107d1d __down+0x4d (0xe42b5374, 0x0, 0x0) kernel .text 0xc0100000 0xc0107cd0 0xc0107d70 0xdf35fd54 0xc0107e77 __down_failed+0xb (0x6, 0xdf35fd84, 0xdee00044, 0x46, 0xe42b52ec) kernel .text 0xc0100000 0xc0107e6c 0xc0107e80 0xc01f3ff0 .text.lock.xfs_file+0x49 kernel .text 0xc0100000 0xc01f3fa7 0xc01f4020 0xdf35fd94 0xc01f3ecf __linvfs_write+0x9f (0xdf35fde8, 0x804a588, 0x20, 0x64, 0xdf35fde0) kernel .text 0xc0100000 0xc01f3e30 0xc01f3fa7 0xdf35fdb0 0xc01f3e2e linvfs_write_invis+0x2e (0xe42b52ec, 0x2, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc01f3e00 0xc01f3e30 0xdf35fee0 0xc02019af dm_write_invis_rvp+0xbf (0x2a, 0xbffff4f0, 0x18, 0x2a, 0x0) kernel .text 0xc0100000 0xc02018f0 0xc02019d0 0xdf35ff8c 0xc01fec40 dmapi_ioctl+0x170 (0xf639c884, 0xf57b7d24, 0x38, 0xbffff360, 0xf57b7d24) kernel .text 0xc0100000 0xc01fead0 0xc01ff700 0xdf35ffbc 0xc014b387 sys_ioctl+0x217 (0x3, 0x38, 0xbffff360, 0x40018420, 0xbffff634) kernel .text 0xc0100000 0xc014b170 0xc014b3e0 0xc01090eb system_call+0x33 kernel .text 0xc0100000 0xc01090b8 0xc01090f0 the test program simply creates/opens a file with the truncate flag linux:~ #./CreateTruncate /mnt/TESTFILE Open File [/mnt/TESTFILE] with truncate flag what the kernel debugger says Stack traceback for pid 6216 0xdf364000 6216 1848 0 0 S 0xdf364270 CreateTruncate EBP EIP Function (args) 0xdf365c48 0xc0117b77 schedule+0x227 (0x20000, 0x16e7e0, 0x2, 0xdf35fecc, 0x46) kernel .text 0xc0100000 0xc0117950 0xc0117c90 0xdf365c84 0xc011793e schedule_timeout+0x9e (0xf5fd7704, 0xe572fda8, 0xdf364000, 0xe460d0a4, 0x0) kernel .text 0xc0100000 0xc01178a0 0xc0117940 0xdf365cfc 0xc0206932 dm_enqueue+0x222 (0xe572fd84, 0x0, 0xf5fd7704, 0x1, 0x0) kernel .text 0xc0100000 0xc0206710 0xc0206a30 0xdf365d2c 0xc0206aaf dm_enqueue_normal_event+0x7f (0xe26e6b6c, 0xf5fd7704, 0x0, 0xf5fd7704, 0x0) kernel .text 0xc0100000 0xc0206a30 0xc0206ad0 0xdf365d5c 0xc020058d dm_send_data_event+0xfd (0x12, 0xe42b52ec, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0200490 0xc02005c0 0xdf365d9c 0xc0206d0e xfs_dm_send_data_event+0x8e (0x12, 0xe42b52ec, 0x0, 0x0, 0x0) kernel .text 0xc0100000 0xc0206c80 0xc0206d40 0xdf365e20 0xc01e9131 xfs_setattr+0xf41 (0xe42c41e4, 0xdf365e40, 0x0, 0x0, 0xe42b52ec) kernel .text 0xc0100000 0xc01e81f0 0xc01e9190 0xdf365ebc 0xc01f6e58 linvfs_setattr+0x108 (0xeaad7c38, 0xdf365ef8, 0x48, 0xe42b5374, 0xe42b5384) kernel .text 0xc0100000 0xc01f6d50 0xc01f6f10 0xdf365edc 0xc0152f2d notify_change+0xfd (0xeaad7c38, 0xdf365ef8, 0xe42c41c4, 0x0, 0x0) kernel .text 0xc0100000 0xc0152e30 0xc0152fe0 0xdf365f34 0xc013af05 do_truncate+0x75 (0xeaad7c38, 0x0, 0x0, 0xdf365f84, 0x0) kernel .text 0xc0100000 0xc013c010 0xc013c0c0 0xc01090eb system_call+0x33 kernel .text 0xc0100000 0xc01090b8 0xc01090f0 --------------050606020005080709000607-- From owner-linux-xfs@oss.sgi.com Thu Feb 12 14:22:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 14:22:19 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1CMMHKO029082 for ; Thu, 12 Feb 2004 14:22:17 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1CMMCJh021254 for ; Thu, 12 Feb 2004 16:22:12 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1CMMBwZ34131685; Thu, 12 Feb 2004 16:22:11 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1CMMBkP1591921; Thu, 12 Feb 2004 16:22:11 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i1CMMA9i8678930; Thu, 12 Feb 2004 16:22:11 -0600 (CST) Message-Id: <200402122222.i1CMMA9i8678930@clink.americas.sgi.com> To: Mike Montour cc: linux-xfs@oss.sgi.com Subject: Re: dm_write_invis() blocking problem Date: Thu, 12 Feb 2004 16:22:10 -0600 From: Dean Roehrich X-archive-position: 2071 X-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@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs >From: Mike Montour >Dean Roehrich wrote: > >> I'm currently testing the following patch, which should alleviate the >> hang. >> >>The problem is that a thread was able to get into the dmapi queues while >>holding a resource (i_sem, in this case). >> >>Dean >> >> >Thank you for the patch. It fixes my DM_EVENT_WRITE problem. However, >I can trigger a similar situation by calling dm_write_invis() while >processing >a TRUNCATE event. A co-worker has been helping me test this using KDB, >and I've attached his notes. Okay, so do_truncate() is grabbing both i_sem and i_alloc_sem in current 2.4. Thanks >Also, when the patch is applied to a current checkout of the SGI CVS tree >(pserver:cvs@oss.sgi.com:/cvs), there is a link failure: > >fs/fs.o: In function `xfs_dm_send_data_event': >fs/fs.o(.text+0xac8fb): undefined reference to `do_up_read' >fs/fs.o(.text+0xac94b): undefined reference to `do_down_read' sorry, I've been building against 2.4.21 ...don't ask why Dean From owner-linux-xfs@oss.sgi.com Thu Feb 12 16:14:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 16:15:04 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1D0EpKO031943 for ; Thu, 12 Feb 2004 16:14:51 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1D0Ep2G031940 for linux-xfs@oss.sgi.com; Thu, 12 Feb 2004 16:14:51 -0800 Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1D0EnKO031927; Thu, 12 Feb 2004 16:14:49 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1D0Eilr029566; Thu, 12 Feb 2004 18:14:44 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1D0EhwZ34079197; Thu, 12 Feb 2004 18:14:43 -0600 (CST) Received: (from overby@localhost) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) id i1D0EhaR2680960; Thu, 12 Feb 2004 18:14:43 -0600 (CST) Date: Thu, 12 Feb 2004 18:14:43 -0600 (CST) Message-Id: <200402130014.i1D0EhaR2680960@daisy-e236.americas.sgi.com> From: Glen Overby To: bugzilla-daemon@oss.sgi.com Cc: xfs-master@oss.sgi.com Subject: Re: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 In-Reply-To: message from bugzilla-daemon@oss.sgi.com sent 12 February 2004 References: <200402122119.i1CLJM9O025998@oss.sgi.com> X-archive-position: 2072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: overby@sgi.com Precedence: bulk X-list: linux-xfs > data fork in regular inode 3523176 claims used block 223904 > xfs_repair: dinode.c:2429: process_dinode_int: Assertion `err == 0' failed. > > > Let me know what else I can do? Assertions are only enabled on DEBUG compiles, so you must have compiled xfsprogs/repair with -DDEBUG. Turn it off and the assert will be turned off. I believe the problem that was detected will be handled properly by xfs_repair. Glen Overby From owner-linux-xfs@oss.sgi.com Thu Feb 12 16:21:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 16:21:27 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1D0LGKO002857 for ; Thu, 12 Feb 2004 16:21:17 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1D0L8lr031910 for ; Thu, 12 Feb 2004 18:21:09 -0600 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 LAA17386; Fri, 13 Feb 2004 11:21:00 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1D0Kw8n068714; Fri, 13 Feb 2004 11:20:59 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1D0KJPY001307; Fri, 13 Feb 2004 11:20:19 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1D0K9oL001305; Fri, 13 Feb 2004 11:20:09 +1100 Date: Fri, 13 Feb 2004 11:20:09 +1100 From: Nathan Scott To: Ramesh K Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: problems with real-time option. Message-ID: <20040213002009.GC1158@frodo> References: <20030826220532.GA769@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 2073 X-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 Thu, Feb 12, 2004 at 03:55:10PM +0000, Ramesh K wrote: > > Hello, > I'm trying to use realtime subvolumes under Linux (SuSE 8.1, running > kernel 2.4.19-64GB-SMP (I know it is very old!!) You should be aware that realtime support is marked experimental and may not function correctly. That said, Eric made several fixes in this area awhile ago and the last time I tested it, it was looking much more stable. > The hardware: I'm using a 3ware RAID controller, and am using RAID level > 0 (all eight 120GByte disks together are seen as one disk of 960 GByte device). > Now I want to use this entire 960 GBytes for my realtime data, and want > to place metadata on ramdisk. When I try: > dop93:> mkfs -t xfs -f -d unwritten=0 -r rtdev=/dev/sda1 /dev/ram1, > > I get warnings on block size of ramdisk. And when I try to mount the What is the warning? > device with: mount -t xfs -o rtdev /dev/sda1 - the call never returns. > Am I doing something very gross? Thanks. That mount line is incorrect, you need to use something like: mount -t xfs -o rtdev=/dev/sda1 /dev/ram1 /mnt It seems odd to be using a ram disk in this way... cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 12 20:03:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 20:03:49 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1D43jKO010342 for ; Thu, 12 Feb 2004 20:03:45 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1D43alr003833 for ; Thu, 12 Feb 2004 22:03:37 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1D3wr5p018096 for ; Fri, 13 Feb 2004 14:58:53 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1D3wreQ018095 for linux-xfs@oss.sgi.com; Fri, 13 Feb 2004 14:58:53 +1100 Date: Fri, 13 Feb 2004 14:58:53 +1100 From: FSG QA Message-Id: <200402130358.i1D3wreQ018095@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 2074 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Current random routines used by fsstress should now produce this output deterministically. -- nathans Date: Thu Feb 12 20:01:59 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: tes@sgi.com,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166729a xfstests/022.out - 1.7 From owner-linux-xfs@oss.sgi.com Thu Feb 12 20:38:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Feb 2004 20:38:39 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1D4cZKO014184 for ; Thu, 12 Feb 2004 20:38:36 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1D4XQrG032728 for ; Thu, 12 Feb 2004 20:33:30 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA20936 for ; Fri, 13 Feb 2004 15:33:25 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1D4XO7a023337 for ; Fri, 13 Feb 2004 15:33:25 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1D4XO4W023335 for linux-xfs@oss.sgi.com; Fri, 13 Feb 2004 15:33:24 +1100 Date: Fri, 13 Feb 2004 15:33:24 +1100 From: Tim Shimmin Message-Id: <200402130433.i1D4XO4W023335@sherman.melbourne.sgi.com> Subject: PARTIAL TAKE 907752 - XFS log QA Apparently-To: X-archive-position: 2075 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Try to simplify log QA with mnt and mkfs options. Add new test 086 for log replay with v2 logs. Need to write more tests with varying metadata ops. Modid: xfs-cmds:slinx:166654a xfstests/082 - 1.3 - Don't need 2 trap calls - remove 1st one. Date: Thu Feb 12 20:31:25 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166730a xfstests/086.out - 1.1 - output for 086 xfstests/086 - 1.1 - new test to replay v2 logs xfstests/018 - 1.28 - simplify xfstests/034 - 1.10 - put some output to seq.full in lieu of dev/null xfstests/group - 1.51 - Add 086 xfstests/018.out - 1.7 - delete mkfs filtered output xfstests/082 - 1.4 - simplify mkfs,mnt opts xfstests/common.log - 1.4 - simplify mkfs/mnt handling xfstests/082.out - 1.3 - delete mkfs filtered output xfstests/081 - 1.2 - simplify mkfs,mnt opts xfstests/081.out - 1.2 - delete mkfs filtered output xfstests/085.out - 1.2 - oops ... no change From owner-linux-xfs@oss.sgi.com Fri Feb 13 03:09:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 03:09:40 -0800 (PST) Received: from relay-1v.club-internet.fr (relay-1v.club-internet.fr [194.158.96.112]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DB9TKO025176 for ; Fri, 13 Feb 2004 03:09:30 -0800 Received: from Patrick (f03m-9-76.d1.club-internet.fr [212.194.56.76]) by relay-1v.club-internet.fr (Postfix) with SMTP id 7AABC869 for ; Fri, 13 Feb 2004 12:09:28 +0100 (CET) Message-ID: <001001c3f222$965d90b0$0c01a8c0@Patrick> From: "Patrick Vier" To: References: <20030826220532.GA769@frodo> <20040213002009.GC1158@frodo> Subject: Install rh9+xfs from the iso cd downloaded from sgi site Date: Fri, 13 Feb 2004 12:14:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-archive-position: 2076 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: patrick@post-logic.com Precedence: bulk X-list: linux-xfs Hi all, I've a problem to install Linux-xfs with the iso downloaded from the sgi site. 1- installing from linux-xfs (rh9)... install is hang when install pack for grub boot loader... Nota : the test of the distrib is ok. Please help. Some of you have meet this problem ??? Patrick :) From owner-linux-xfs@oss.sgi.com Fri Feb 13 03:29:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 03:30:09 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DBTsKO025726 for ; Fri, 13 Feb 2004 03:29:54 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 932AB1421002; Fri, 13 Feb 2004 06:29:55 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03613-09; Fri, 13 Feb 2004 06:29:52 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 5DF4A1421001; Fri, 13 Feb 2004 06:29:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 3E37F3027618; Fri, 13 Feb 2004 06:29:52 -0500 (EST) Date: Fri, 13 Feb 2004 06:29:51 -0500 (EST) From: Mike Burger To: Patrick Vier Cc: linux-xfs@oss.sgi.com Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site In-Reply-To: <001001c3f222$965d90b0$0c01a8c0@Patrick> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 2077 X-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 On Fri, 13 Feb 2004, Patrick Vier wrote: > Hi all, > > I've a problem to install Linux-xfs with the iso downloaded from the sgi > site. > > 1- installing from linux-xfs (rh9)... install is hang when install pack for > grub boot loader... > Nota : the test of the distrib is ok. > > Please help. > Some of you have meet this problem ??? There's been problems noted, in the past, regarding GRUB. I just stick with LILO on my RH+XFS systems. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Fri Feb 13 04:09:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 04:10:06 -0800 (PST) Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DC9SKO026785 for ; Fri, 13 Feb 2004 04:09:31 -0800 Received: from Patrick (f03m-9-76.d1.club-internet.fr [212.194.56.76]) by relay-3m.club-internet.fr (Postfix) with SMTP id E369CE108; Fri, 13 Feb 2004 13:09:26 +0100 (CET) Message-ID: <000b01c3f22a$f77d7b50$0c01a8c0@Patrick> From: "Patrick Vier" To: "Mike Burger" Cc: References: Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site Date: Fri, 13 Feb 2004 13:14:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-archive-position: 2078 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: patrick@post-logic.com Precedence: bulk X-list: linux-xfs Yes, grub seems not the good boot loader... Actually, i've restarted all the installs. 1- install RH8 with grub, just to check if HW no problem... OK, rh boot normaly. 2- Upgrade RH8 to RH9 (standard) with grub as boot loader... OK rh reboot normaly. 3- Actually, i try to upgrade RH9 to RH9-XFS with the cd rh9+xfs... and with this cd is not possible to upgrade the system... only install from scratch... ... So i will install it with lilo as boot loader... Hope that Linux God be with me... Patrick :) ----- Original Message ----- From: "Mike Burger" To: "Patrick Vier" Cc: Sent: Friday, February 13, 2004 12:29 PM Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site > On Fri, 13 Feb 2004, Patrick Vier wrote: > > > Hi all, > > > > I've a problem to install Linux-xfs with the iso downloaded from the sgi > > site. > > > > 1- installing from linux-xfs (rh9)... install is hang when install pack for > > grub boot loader... > > Nota : the test of the distrib is ok. > > > > Please help. > > Some of you have meet this problem ??? > > There's been problems noted, in the past, regarding GRUB. I just stick > with LILO on my RH+XFS systems. > -- > Mike Burger > http://www.bubbanfriends.org > > Visit the Dog Pound II BBS > telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 > > To be notified of updates to the web site, visit > http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a > message to: > > site-update-request@bubbanfriends.org > > with a message of: > > subscribe > > > From owner-linux-xfs@oss.sgi.com Fri Feb 13 04:19:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 04:19:08 -0800 (PST) Received: from burgers.bubbanfriends.org (IDENT:postfix@12-222-156-122.client.insightBB.com [12.222.156.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DCJ3KO028081 for ; Fri, 13 Feb 2004 04:19:03 -0800 Received: from localhost (unknown [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 25A6C1421002; Fri, 13 Feb 2004 07:19:05 -0500 (EST) Received: from burgers.bubbanfriends.org ([127.0.0.1]) by localhost (burgers.bubbanfriends.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11639-04; Fri, 13 Feb 2004 07:19:02 -0500 (EST) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 0CF7C1421001; Fri, 13 Feb 2004 07:19:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id ECD553027618; Fri, 13 Feb 2004 07:19:01 -0500 (EST) Date: Fri, 13 Feb 2004 07:19:01 -0500 (EST) From: Mike Burger To: Patrick Vier Cc: linux-xfs@oss.sgi.com Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site In-Reply-To: <000b01c3f22a$f77d7b50$0c01a8c0@Patrick> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at bubbanfriends.org X-archive-position: 2079 X-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 On Fri, 13 Feb 2004, Patrick Vier wrote: > Yes, grub seems not the good boot loader... > Actually, i've restarted all the installs. > 1- install RH8 with grub, just to check if HW no problem... OK, rh boot > normaly. > 2- Upgrade RH8 to RH9 (standard) with grub as boot loader... OK rh reboot > normaly. > 3- Actually, i try to upgrade RH9 to RH9-XFS with the cd rh9+xfs... and with > this cd is not possible to upgrade the system... only install from > scratch... > ... So i will install it with lilo as boot loader... Hope that Linux God be > with me... Wasn't possible from the boot diskette, either...even though I issued "linux upgrade" at the initial prompt. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 To be notified of updates to the web site, visit http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a message to: site-update-request@bubbanfriends.org with a message of: subscribe From owner-linux-xfs@oss.sgi.com Fri Feb 13 04:22:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 04:23:15 -0800 (PST) Received: from smtp-out3.xs4all.nl (smtp-out3.xs4all.nl [194.109.24.13]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DCMsKO030623 for ; Fri, 13 Feb 2004 04:22:55 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out3.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1DCMjpA040771; Fri, 13 Feb 2004 13:22:50 +0100 (CET) Message-Id: <4.3.2.7.2.20040213132142.0404e040@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Feb 2004 13:22:45 +0100 To: "Patrick Vier" , "Mike Burger" From: Seth Mos Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site Cc: In-Reply-To: <000b01c3f22a$f77d7b50$0c01a8c0@Patrick> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2080 X-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:14 13-2-2004 +0100, Patrick Vier wrote: >Yes, grub seems not the good boot loader... >Actually, i've restarted all the installs. >1- install RH8 with grub, just to check if HW no problem... OK, rh boot >normaly. >2- Upgrade RH8 to RH9 (standard) with grub as boot loader... OK rh reboot >normaly. >3- Actually, i try to upgrade RH9 to RH9-XFS with the cd rh9+xfs... and with >this cd is not possible to upgrade the system... only install from >scratch... >... So i will install it with lilo as boot loader... Hope that Linux God be >with me... Search the archives. This is a known issue. And I know it's missing from the FAQ. You could also use LILO to work around this. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Fri Feb 13 04:27:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 04:28:12 -0800 (PST) Received: from server7.nfra.nl (server7.nfra.nl [192.87.1.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DCRrKO031057 for ; Fri, 13 Feb 2004 04:27:54 -0800 Received: from wop10.nfra.nl [195.169.63.130] by server7.nfra.nl; Fri, 13 Feb 2004 13:28:39 +0100 Date: Fri, 13 Feb 2004 12:27:43 +0000 (UTC) From: Ramesh K X-X-Sender: kram@wop10.nfra.nl To: linux-xfs@oss.sgi.com Subject: Re: problems with real-time option. In-Reply-To: <20040213002009.GC1158@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kram@astron.nl Precedence: bulk X-list: linux-xfs Hi: Thanks Nathan. I wanted to use ramdisk only to store filenames, and the actual data in realtime subvolume. Thoguht it'll have better performance. However I've now repartioned my disk to have two partitions: one of 100GB and the other of 800GB (/dev/sda1 and /dev/sda2 respectively). I'm using /dev/sda1 as my regular xfs volume (log plus metadata), and configured /dev/sda2 as the realtime subvolume. This is the output of mkfs.xfs: dop93:~ # mkfs -t xfs -f -d unwritten=0 -r rtdev=/dev/sda2 /dev/sda1 meta-data=/dev/sda1 isize=256 agcount=25, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=25601577, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=12500, version=1 = sectsz=512 sunit=0 blks realtime =/dev/sda2 extsz=65536 blocks=208836967, rtextents=13052310 dop93:~ # mount -t xfs -o rtdev=/dev/sda2 /dev/sda1 /mnt It's been good so far. Now how do I determine the amount of free space in my realtime subvolume? Do I need to have the realtime subvolume on another device altogether (instead of another partition) to get better performance? I don't know what version of XFS I'm using (it's not v1.3, but the one packaged with SuSE 8.1). I have new version ( 2.2.1-28) of xfsprogs though. In the mean time I also tried to write a 'realtime' file on the realtime subvolume - but SuSE 8.1 seems to have disabled O_DIRECT and O_LARGEFILE support. Any clues on that? I'm trying hard to get the realtime subvolumes working - hopefully it is more deterministic than the regular buffered I/O. Any info on these lines would be great. Thanks in advance. -Ramesh > On Thu, Feb 12, 2004 at 03:55:10PM +0000, Ramesh K wrote: > > > > Hello, > > I'm trying to use realtime subvolumes under Linux (SuSE 8.1, running > > kernel 2.4.19-64GB-SMP (I know it is very old!!) > > You should be aware that realtime support is marked experimental > and may not function correctly. That said, Eric made several > fixes in this area awhile ago and the last time I tested it, it > was looking much more stable. > > > The hardware: I'm using a 3ware RAID controller, and am using RAID level > > 0 (all eight 120GByte disks together are seen as one disk of 960 GByte device). > > Now I want to use this entire 960 GBytes for my realtime data, and want > > to place metadata on ramdisk. When I try: > > dop93:> mkfs -t xfs -f -d unwritten=0 -r rtdev=/dev/sda1 /dev/ram1, > > > > I get warnings on block size of ramdisk. And when I try to mount the > > What is the warning? > > > device with: mount -t xfs -o rtdev /dev/sda1 - the call never returns. > > Am I doing something very gross? Thanks. > > That mount line is incorrect, you need to use something like: > mount -t xfs -o rtdev=/dev/sda1 /dev/ram1 /mnt > > It seems odd to be using a ram disk in this way... > > cheers. > > -- > Nathan > ************************************************************************** Ramesh K (Mo/Tu): Radiosterrenwacht Westerbork, Schattenburg 1, 9433 TA Zwiggelte. ph: +31-(0)593-598755 fax:+31-(0)593-592486 (We/Th/Fr): Stitching Astron, Oude Hoogeveensedijk 4, 7991 PD Dwingeloo. ph: +31-(0)521-595255 fax:+31-(0)521-597332 ************************************************************************** From owner-linux-xfs@oss.sgi.com Fri Feb 13 05:34:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 05:34:12 -0800 (PST) Received: from relay-3m.club-internet.fr (relay-3m.club-internet.fr [194.158.104.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DDXuKO032188 for ; Fri, 13 Feb 2004 05:33:56 -0800 Received: from Patrick (f03m-9-76.d1.club-internet.fr [212.194.56.76]) by relay-3m.club-internet.fr (Postfix) with SMTP id CB228E0A6 for ; Fri, 13 Feb 2004 14:03:52 +0100 (CET) Message-ID: <002d01c3f232$91da1120$0c01a8c0@Patrick> From: "Patrick Vier" To: Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site Date: Fri, 13 Feb 2004 14:09:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-archive-position: 2082 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: patrick@post-logic.com Precedence: bulk X-list: linux-xfs > ... Install rh9-xfs was done and finished correctly... > Choose the LILO for boot loader during the install... > ... after the reboot, nothing has changed.... > Black screen with grub in upper left... > > I don't understand why that grub text is displayed, i've forced lilo during > install ??????????? > > Heuuu!!! I've not a diskett boot, cause the system told me that the kernel > is too big for the diskett. > Will Try to find something in the archives... > > But if you have some method that i can follow for boot my linux-xfs... will > kiss you feet... lol > > Patrick :) > > ----- Original Message ----- > From: "Mike Burger" > To: "Patrick Vier" > Cc: > Sent: Friday, February 13, 2004 1:19 PM > Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site > > > > On Fri, 13 Feb 2004, Patrick Vier wrote: > > > > > Yes, grub seems not the good boot loader... > > > Actually, i've restarted all the installs. > > > 1- install RH8 with grub, just to check if HW no problem... OK, rh boot > > > normaly. > > > 2- Upgrade RH8 to RH9 (standard) with grub as boot loader... OK rh > reboot > > > normaly. > > > 3- Actually, i try to upgrade RH9 to RH9-XFS with the cd rh9+xfs... and > with > > > this cd is not possible to upgrade the system... only install from > > > scratch... > > > ... So i will install it with lilo as boot loader... Hope that Linux God > be > > > with me... > > > > Wasn't possible from the boot diskette, either...even though I issued > > "linux upgrade" at the initial prompt. > > -- > > Mike Burger > > http://www.bubbanfriends.org > > > > Visit the Dog Pound II BBS > > telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 > > > > To be notified of updates to the web site, visit > > http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a > > message to: > > > > site-update-request@bubbanfriends.org > > > > with a message of: > > > > subscribe > > > > > From owner-linux-xfs@oss.sgi.com Fri Feb 13 05:46:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 05:46:23 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DDk0KO001214 for ; Fri, 13 Feb 2004 05:46:01 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id i1DDjwEL011462 for ; Fri, 13 Feb 2004 14:45:58 +0100 (CET) Received: from gandoliere.imag.fr ([129.88.43.136] helo=gandoliere.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1Arddm-0006rN-00 for ; Fri, 13 Feb 2004 14:45:58 +0100 To: linux-xfs@oss.sgi.com Subject: xfsrestore -i with ssh/rsh+dd as stdin From: Nicolas Kowalski Mail-Copies-To: never Date: Fri, 13 Feb 2004 14:45:57 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 2083 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Hello. I have some problems using xfsrestore (2.2.16-1, Debian woody) with stdin file specifier when requesting an /interactive/ restore. I have no problems with unattended restores. For example, in the following, xfsrestore reads its data from the output of dd, locally. Everything is ok. gaspard:/restore# dd if=/dev/nst0 bs=1024k | xfsrestore -J -i - /restore xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 2.2.16 (dump format 3.0) - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: gaspard xfsrestore: mount point: /backup xfsrestore: volume: /dev/hdb1 xfsrestore: session time: Fri Feb 13 09:48:34 2004 xfsrestore: level: 0 xfsrestore: session label: "gaspard:2004.02.13:0:/backup" xfsrestore: media label: "sdlt320" xfsrestore: file system id: 25b1018d-9731-4011-a7c1-e73e84a8d1dd xfsrestore: session id: dfa73565-7c0c-4aaa-8c59-cc4efeb037f2 xfsrestore: media id: 17679139-35e5-4963-84a3-6679fba4c227 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 128651 directories and 1755499 entries processed xfsrestore: directory post-processing ========================== subtree selection dialog ========================== the following commands are available: pwd ls [ ] cd [ ] add [ ] delete [ ] extract quit help -> ls 1766562304 samba/ 1502097925 dumpmgr/ 1902503387 tftpboot/ 1902503372 ftp/ 1632470340 www/ 559823869 intranet/ 427661074 pgsqla/ 1225615128 pgsql/ 1900119102 imap/ 1761413207 mail/ 143438905 local/ 1342177537 home/ 134217856 cvs/ 131 lost+found/ -> [other commands ok] If dd is called remotely with rsh, xfsrestore hangs. See below: gaspard:/restore# rsh gaspard 'dd if=/dev/nst0 bs=1024k' | xfsrestore -J -i - /restore xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 2.2.16 (dump format 3.0) - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: gaspard xfsrestore: mount point: /backup xfsrestore: volume: /dev/hdb1 xfsrestore: session time: Fri Feb 13 09:48:34 2004 xfsrestore: level: 0 xfsrestore: session label: "gaspard:2004.02.13:0:/backup" xfsrestore: media label: "sdlt320" xfsrestore: file system id: 25b1018d-9731-4011-a7c1-e73e84a8d1dd xfsrestore: session id: dfa73565-7c0c-4aaa-8c59-cc4efeb037f2 xfsrestore: media id: 17679139-35e5-4963-84a3-6679fba4c227 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 128651 directories and 1755499 entries processed xfsrestore: directory post-processing ========================== subtree selection dialog ========================== the following commands are available: pwd ls [ ] cd [ ] add [ ] delete [ ] extract quit help -> ls ===> nothing happens. The dd, rsh and xfsrestore processes are just sleeping. And finally, to add confusion, when dd is called remotely using ssh, xfsrestore seems to accept commands, but does nothing: gaspard:~# ssh gaspard 'dd bs=1024k if=/dev/nst0' | xfsrestore -J -i - /restore xfsrestore: using file dump (drive_simple) strategy xfsrestore: version 2.2.16 (dump format 3.0) - Running single-threaded xfsrestore: searching media for dump xfsrestore: examining media file 0 xfsrestore: dump description: xfsrestore: hostname: gaspard xfsrestore: mount point: /backup xfsrestore: volume: /dev/hdb1 xfsrestore: session time: Fri Feb 13 09:48:34 2004 xfsrestore: level: 0 xfsrestore: session label: "gaspard:2004.02.13:0:/backup" xfsrestore: media label: "sdlt320" xfsrestore: file system id: 25b1018d-9731-4011-a7c1-e73e84a8d1dd xfsrestore: session id: dfa73565-7c0c-4aaa-8c59-cc4efeb037f2 xfsrestore: media id: 17679139-35e5-4963-84a3-6679fba4c227 xfsrestore: searching media for directory dump xfsrestore: reading directories xfsrestore: 128651 directories and 1755499 entries processed xfsrestore: directory post-processing ========================== subtree selection dialog ========================== the following commands are available: pwd ls [ ] cd [ ] add [ ] delete [ ] extract quit help -> ls 1766562304 samba/ 1502097925 dumpmgr/ 1902503387 tftpboot/ 1902503372 ftp/ 1632470340 www/ 559823869 intranet/ 427661074 pgsqla/ 1225615128 pgsql/ 1900119102 imap/ 1761413207 mail/ 143438905 local/ 1342177537 home/ 134217856 cvs/ 131 lost+found/ -> cd home => nothing, happens, so I hit [RET]... the following commands are available: pwd ls [ ] cd [ ] add [ ] delete [ ] extract quit help -> (<== [RET] here) the following commands are available: pwd ls [ ] cd [ ] add [ ] delete [ ] extract quit help -> Am I doing something wrong ? Any help would be greatly appeciated. Thanks. -- Nicolas From owner-linux-xfs@oss.sgi.com Fri Feb 13 06:26:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 06:26:32 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DEQ5KO002465 for ; Fri, 13 Feb 2004 06:26:06 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id i1DEQ3EL024560 for ; Fri, 13 Feb 2004 15:26:03 +0100 (CET) Received: from gandoliere.imag.fr ([129.88.43.136] helo=gandoliere.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1AreGZ-0007U6-00 for ; Fri, 13 Feb 2004 15:26:03 +0100 To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore -i with ssh/rsh+dd as stdin References: From: Nicolas Kowalski Mail-Copies-To: never Date: Fri, 13 Feb 2004 15:26:03 +0100 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 2084 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Nicolas Kowalski writes: > I have some problems using xfsrestore (2.2.16-1, Debian woody) with > stdin file specifier when requesting an /interactive/ restore. I have > no problems with unattended restores. Well, with unattended, I also get a bunch of of warnings at the end of the process: [...] xfsrestore: WARNING: open_by_handle of var/run/screen/S-root failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/run/screen failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/run/identd failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/run/exim failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/run failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/opt failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/mail failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/log/rsync failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/log/news failed:Bad file descriptor xfsrestore: WARNING: open_by_handle of var/log/ksymoops failed:Bad file descriptor [...] -- Nicolas From owner-linux-xfs@oss.sgi.com Fri Feb 13 06:49:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 06:49:18 -0800 (PST) Received: from server7.nfra.nl (server7.nfra.nl [192.87.1.57]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DEnAKO003526 for ; Fri, 13 Feb 2004 06:49:11 -0800 Received: from wop10.nfra.nl [195.169.63.130] by server7.nfra.nl; Fri, 13 Feb 2004 15:49:39 +0100 Date: Fri, 13 Feb 2004 14:48:42 +0000 (UTC) From: Ramesh K X-X-Sender: kram@wop10.nfra.nl To: linux-xfs@oss.sgi.com Subject: more experiments with realtime subvolumes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2085 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kram@astron.nl Precedence: bulk X-list: linux-xfs Hello: Some more experiements with the realtime subvolumes. Please do pass your comments. Before we start, my system (OS - SuSE 8.1, kernel 2.4.19-64GB-SMP, hardware: Transtec, dual-xeon 2.8 GHz, with 3ware Raid Controller - 8*120GB IDE disks on controller), doesn't seem to have O_DIRECT and O_LARGEFILE options. I'm downloading a newer kernel (2.4.21) from suse website - hopefully that has these options enabled. My harddisk is setup as explained in my previous mail, 100 GB meta-data section, and 800 GB realtime section. More questions on realtime subvolume: When I open a file and try to place it in the realtime section with: struct fsxattr myfsxattr; struct xfs_flock64 file; fd = open("/data/kram/data/file1.dat",O_CREAT|O_RDWR); myfsxattr.fsx_xflags = XFS_XFLAG_REALTIME; ioctl(fd,XFS_IOC_FSSETXATTR,&myfsxattr); file.l_whence = 0; file.l_start = 0; file.l_len=2*1024*1024; ioctl(fd,XFS_IOC_RESVSP,&file); close(fd); And then followed it up with, ioctl(fd,XFS_IOC_FSGETXATTR,&myfsxattr); This call returns fsx_xflags as 0x00 (meaning no realtime, and not preallocated). Is it because of the absence of O_DIRECT in the open call? What are the alignment constraints? The man page of xfsctl explains that "d_mem is the memory alignment requirement of the user's data buffer. d_miniosz specifies block size, minimum I/O request size, and I/O alignment.The size of all I/O requests must be a multiple of this amount and the value of the seek pointer at the time of the I/O request must also be an integer multiple of this amount. d_maxiosz is the maximum I/O request size which can be performed on the file descriptor." Does this mean a write of "char array[1024*1024]" is aligned with 512-byte boundary for the I/O to succeed? Or in other words, is array[1024*1024] d_mem aligned, or do I have to do something special to get it aligned? Thanks for your responses. -Ramesh > > Hi: > Thanks Nathan. I wanted to use ramdisk only to store filenames, and the > actual data in realtime subvolume. Thoguht it'll have better performance. > However I've now repartioned my disk to have two partitions: one of > 100GB and the other of 800GB (/dev/sda1 and /dev/sda2 respectively). I'm using > /dev/sda1 as my regular xfs volume (log plus metadata), and configured /dev/sda2 > as the realtime subvolume. This is the output of mkfs.xfs: > > dop93:~ # mkfs -t xfs -f -d unwritten=0 -r rtdev=/dev/sda2 /dev/sda1 > meta-data=/dev/sda1 isize=256 agcount=25, agsize=1048576 blks > = sectsz=512 > data = bsize=4096 blocks=25601577, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=12500, version=1 > = sectsz=512 sunit=0 blks > realtime =/dev/sda2 extsz=65536 blocks=208836967, > rtextents=13052310 > > dop93:~ # mount -t xfs -o rtdev=/dev/sda2 /dev/sda1 /mnt > > It's been good so far. Now how do I determine the amount of free space > in my realtime subvolume? Do I need to have the realtime subvolume on another > device altogether (instead of another partition) to get better performance? > I don't know what version of XFS I'm using (it's not v1.3, but the one > packaged with SuSE 8.1). I have new version ( 2.2.1-28) of xfsprogs though. > In the mean time I also tried to write a 'realtime' file on the realtime > subvolume - but SuSE 8.1 seems to have disabled O_DIRECT and O_LARGEFILE > support. Any clues on that? I'm trying hard to get the realtime subvolumes > working - hopefully it is more deterministic than the regular buffered I/O. Any > info on these lines would be great. Thanks in advance. > > -Ramesh > > > On Thu, Feb 12, 2004 at 03:55:10PM +0000, Ramesh K wrote: > > > > > > Hello, > > > I'm trying to use realtime subvolumes under Linux (SuSE 8.1, running > > > kernel 2.4.19-64GB-SMP (I know it is very old!!) > > > > You should be aware that realtime support is marked experimental > > and may not function correctly. That said, Eric made several > > fixes in this area awhile ago and the last time I tested it, it > > was looking much more stable. > > > > > The hardware: I'm using a 3ware RAID controller, and am using RAID level > > > 0 (all eight 120GByte disks together are seen as one disk of 960 GByte device). > > > Now I want to use this entire 960 GBytes for my realtime data, and want > > > to place metadata on ramdisk. When I try: > > > dop93:> mkfs -t xfs -f -d unwritten=0 -r rtdev=/dev/sda1 /dev/ram1, > > > > > > I get warnings on block size of ramdisk. And when I try to mount the > > > > What is the warning? > > > > > device with: mount -t xfs -o rtdev /dev/sda1 - the call never returns. > > > Am I doing something very gross? Thanks. > > > > That mount line is incorrect, you need to use something like: > > mount -t xfs -o rtdev=/dev/sda1 /dev/ram1 /mnt > > > > It seems odd to be using a ram disk in this way... > > > > cheers. > > > > -- > > Nathan > > > > ************************************************************************** > Ramesh K > (Mo/Tu): Radiosterrenwacht Westerbork, Schattenburg 1, 9433 TA Zwiggelte. > ph: +31-(0)593-598755 fax:+31-(0)593-592486 > (We/Th/Fr): Stitching Astron, Oude Hoogeveensedijk 4, 7991 PD Dwingeloo. > ph: +31-(0)521-595255 fax:+31-(0)521-597332 > ************************************************************************** > > > ************************************************************************** Ramesh K (Mo/Tu): Radiosterrenwacht Westerbork, Schattenburg 1, 9433 TA Zwiggelte. ph: +31-(0)593-598755 fax:+31-(0)593-592486 (We/Th/Fr): Stitching Astron, Oude Hoogeveensedijk 4, 7991 PD Dwingeloo. ph: +31-(0)521-595255 fax:+31-(0)521-597332 ************************************************************************** From owner-linux-xfs@oss.sgi.com Fri Feb 13 09:19:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 09:19:25 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DHJ9KO012618 for ; Fri, 13 Feb 2004 09:19:10 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1DHJ2xb026641 for ; Fri, 13 Feb 2004 11:19:02 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1DHJ1Cg34044713; Fri, 13 Feb 2004 11:19:01 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1DHJ1oZ398502; Fri, 13 Feb 2004 11:19:01 -0600 (CST) Subject: Re: more experiments with realtime subvolumes. From: Eric Sandeen To: Ramesh K Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1076692740.10710.31.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Feb 2004 11:19:01 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2086 X-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 Before we go too far with this, you do understand that if your metadata is on a ramdisk, all of your realtime data will be useless after a reboot, right? -Eric On Fri, 2004-02-13 at 08:48, Ramesh K wrote: > Hello: > Some more experiements with the realtime subvolumes. Please do pass your > comments. -- Eric Sandeen [C]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 Feb 13 09:30:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 09:30:42 -0800 (PST) Received: from hptimail01.HPTI.COM ([208.20.6.201]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DHUbKO015794 for ; Fri, 13 Feb 2004 09:30:38 -0800 Received: from ijet.fsl.noaa.gov ([216.241.44.152]) by hptimail01.HPTI.COM with Microsoft SMTPSVC(6.0.3790.0); Fri, 13 Feb 2004 12:30:36 -0500 Subject: Re: Data corruption with xfs+nfs+lvm From: Craig Tierney To: Nathan Scott Cc: cattelan@sgi.com, linux-xfs@oss.sgi.com In-Reply-To: <1076360029.5321.53.camel@hpti9.fsl.noaa.gov> References: <1075423747.3859.280.camel@hpti7.fsl.noaa.gov> <20040130024343.GC1062@frodo> <1075482631.3866.9.camel@hpti7.fsl.noaa.gov> <1076360029.5321.53.camel@hpti9.fsl.noaa.gov> Content-Type: text/plain Message-Id: <1076693365.7211.33.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Fri, 13 Feb 2004 10:29:25 -0700 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2004 17:30:37.0348 (UTC) FILETIME=[17E53640:01C3F257] X-archive-position: 2087 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ctierney@HPTI.com Precedence: bulk X-list: linux-xfs I wanted to update my investigation with the corruption I was seeing on my xfs filesystem exported over nfs. The problem is NOT xfs or nfs. It turns out that the tg3 driver in 2.4.20 and 2.4.21 doesn't hold up under load (at least this load). I have not tried a newer driver at this point, but switching to a Acenic based gigE card has solved the problem. I have not gone back to see what happens when I re-enable xfs_refcache_purge_some yet. We needed to get a project done. When that happens (in a few days) I can take that server back and enable that function and see if things still work. Craig From owner-linux-xfs@oss.sgi.com Fri Feb 13 09:31:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 09:31:45 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1DHVgKO016023 for ; Fri, 13 Feb 2004 09:31:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1DHVaMJ006340 for ; Fri, 13 Feb 2004 09:31:36 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1DHVZCg34139009; Fri, 13 Feb 2004 11:31:35 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1DHVZoZ395785; Fri, 13 Feb 2004 11:31:35 -0600 (CST) Subject: Re: more experiments with realtime subvolumes. From: Eric Sandeen To: Ramesh K Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1076693494.10710.44.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 13 Feb 2004 11:31:35 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2088 X-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 Oops, sorry, ok so you've abandoned the ramdisk idea, missed that. :) On Fri, 2004-02-13 at 08:48, Ramesh K wrote: > Hello: > Some more experiements with the realtime subvolumes. Please do pass your > comments. Before we start, my system (OS - SuSE 8.1, kernel 2.4.19-64GB-SMP, > hardware: Transtec, dual-xeon 2.8 GHz, with 3ware Raid Controller - 8*120GB IDE > disks on controller), doesn't seem to have O_DIRECT and O_LARGEFILE options. I'm > downloading a newer kernel (2.4.21) from suse website - hopefully that has these > options enabled. > My harddisk is setup as explained in my previous mail, 100 GB > meta-data section, and 800 GB realtime section. More questions on realtime > subvolume: > When I open a file and try to place it in the realtime section with: > > struct fsxattr myfsxattr; > struct xfs_flock64 file; > > fd = open("/data/kram/data/file1.dat",O_CREAT|O_RDWR); > myfsxattr.fsx_xflags = XFS_XFLAG_REALTIME; > ioctl(fd,XFS_IOC_FSSETXATTR,&myfsxattr); > file.l_whence = 0; > file.l_start = 0; > file.l_len=2*1024*1024; > ioctl(fd,XFS_IOC_RESVSP,&file); > close(fd); > > And then followed it up with, ioctl(fd,XFS_IOC_FSGETXATTR,&myfsxattr); > This call returns fsx_xflags as 0x00 (meaning no realtime, and not > preallocated). Is it because of the absence of O_DIRECT in the open call? For starters, your file cannot have had any non-realtime I/O to it before you try to set it as REALTIME. Is this the case? I do something like this: if (ioctl(ofd, XFS_IOC_FSGETXATTR, &fsxinfo) == -1) { perror("fsgetxattr failed"); } else { fsxinfo.fsx_xflags = XFS_XFLAG_REALTIME; if (ioctl(ofd, XFS_IOC_FSSETXATTR, &fsxinfo) == -1) { perror("setxattr ioctl failed"); } } Without digging around too much - I don't remember offhand - I'd suggest opening the file O_DIRECT as well, yes. > What are the alignment constraints? The man page of xfsctl explains that > "d_mem is the memory alignment requirement of the user's data buffer. > d_miniosz specifies block size, minimum I/O request size, and I/O alignment.The > size of all I/O requests must be a multiple of this amount and the value of the > seek pointer at the time of the I/O request must also be an integer multiple of > this amount. d_maxiosz is the maximum I/O request size which can be performed on > the file descriptor." Does this mean a write of "char array[1024*1024]" is > aligned with 512-byte boundary for the I/O to succeed? Or in other words, is > array[1024*1024] d_mem aligned, or do I have to do something special to get it > aligned? While I do think that xfsctl should return proper alignment info, it really should be just the same as normal O_DIRECT requirements on Linux, I think. i.e. page-aligned, multiple of page-sized. You can use memalign to get aligned memory. See http://oss.sgi.com/~sandeen/odirect-rt.c for an example of something which can do O_DIRECT / Realtime I/O - note I didn't write most of it but hacked in some realtime goodness for testing. It worked last time I tried it, I think. :) -Eric -- Eric Sandeen [C]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 Feb 13 17:30:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 17:30:19 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1E1UFKO016621 for ; Fri, 13 Feb 2004 17:30:15 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1E1UFmx016620 for linux-xfs@oss.sgi.com; Fri, 13 Feb 2004 17:30:15 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1E1UDKQ016606 for ; Fri, 13 Feb 2004 17:30:13 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1E1JLQ6016323; Fri, 13 Feb 2004 17:19:21 -0800 Date: Fri, 13 Feb 2004 17:19:21 -0800 Message-Id: <200402140119.i1E1JLQ6016323@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 307] New: prohibited_mr_events() in dmapi/dmapi_xfs.c unconditionally prohibits DM_EVENT_READ X-Bugzilla-Reason: AssignedTo X-archive-position: 2089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=307 Summary: prohibited_mr_events() in dmapi/dmapi_xfs.c unconditionally prohibits DM_EVENT_READ Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: dmapi AssignedTo: xfs-master@oss.sgi.com ReportedBy: mmontour@bycast.com In the current CVS checkout (version 1.29 of dmapi/dmapi_xfs.c): STATIC int prohibited_mr_events( vnode_t *vp) { struct address_space *mapping = LINVFS_GET_IP(vp)->i_mapping; int prohibited = (1 << DM_EVENT_READ); struct vm_area_struct *vma; #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0) down(&mapping->i_shared_sem); list_for_each_entry(vma, &mapping->i_mmap_shared, shared) { if (!(vma->vm_flags & VM_DENYWRITE)) { prohibited |= (1 << DM_EVENT_WRITE); break; } } up(&mapping->i_shared_sem); #else spin_lock(&mapping->i_shared_lock); for (vma = mapping->i_mmap_shared; vma; vma = vma->vm_next) { if (!(vma->vm_flags & VM_DENYWRITE)) { prohibited |= (1 << DM_EVENT_WRITE); break; } } spin_unlock(&mapping->i_shared_lock); #endif return prohibited; } "prohibited" is initialized to (1 << DM_EVENT_READ) and only OR-ed with other values in the body of the function. Therefore, prohibited_mr_events() will prevent the setting of READ events on a file regardless of its i_mapping status. The previous version of this function checked VN_MAPPED(vp) first: STATIC int prohibited_mr_events( vnode_t *vp) { struct address_space *mapping; struct vm_area_struct *vma; int prohibited; if(!VN_MAPPED(vp)) return 0; prohibited = 1 << DM_EVENT_READ; mapping = LINVFS_GET_IP(vp)->i_mapping; ... ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Feb 13 23:42:53 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Feb 2004 23:43:06 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1E7gqKO026095 for ; Fri, 13 Feb 2004 23:42:53 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1E7gl3P012238 for ; Sat, 14 Feb 2004 01:42:47 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1E7gkbh34165383; Sat, 14 Feb 2004 01:42:46 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AruRp-0002WA-00; Sat, 14 Feb 2004 01:42:45 -0600 Subject: TAKE 908003 - Add back missing check for mapped files in prohibited_mr_events Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Sat, 14 Feb 2004 01:42:45 -0600 X-archive-position: 2090 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Feb 13 23:42:28 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:166800a fs/xfs/dmapi/dmapi_xfs.c - 1.30 - add back VN_MAPPED check that got lost From owner-linux-xfs@oss.sgi.com Mon Feb 16 05:30:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 05:30:50 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUWKO013675 for ; Mon, 16 Feb 2004 05:30:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDUVVA013665 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 05:30:31 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUOKY013606 for ; Mon, 16 Feb 2004 05:30:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDNsVl013533; Mon, 16 Feb 2004 05:23:54 -0800 Date: Mon, 16 Feb 2004 05:23:54 -0800 Message-Id: <200402161323.i1GDNsVl013533@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 178] NFSD and 2.4.19+xfs-1.2pre problem X-Bugzilla-Reason: AssignedTo X-archive-position: 2091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=178 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From hch@xfs.org 2004-16-02 05:23 PDT ------- This isn't reproducible with a current codebase, doesn't look like an XFS bug to start with and the submitter hasn't responed for 1 1/2 month. Closing. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 05:30:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 05:30:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUXKO013686 for ; Mon, 16 Feb 2004 05:30:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDUWhG013685 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 05:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUOKc013606 for ; Mon, 16 Feb 2004 05:30:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDLLOA013412; Mon, 16 Feb 2004 05:21:21 -0800 Date: Mon, 16 Feb 2004 05:21:21 -0800 Message-Id: <200402161321.i1GDLLOA013412@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 307] prohibited_mr_events() in dmapi/dmapi_xfs.c unconditionally prohibits DM_EVENT_READ X-Bugzilla-Reason: AssignedTo X-archive-position: 2091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=307 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED Summary|prohibited_mr_events() in |prohibited_mr_events() in |dmapi/dmapi_xfs.c |dmapi/dmapi_xfs.c |unconditionally prohibits |unconditionally prohibits |DM_EVENT_READ |DM_EVENT_READ ------- Additional Comments From hch@xfs.org 2004-16-02 05:21 PDT ------- Fixed in current CVS. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 05:30:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 05:30:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUQKO013635 for ; Mon, 16 Feb 2004 05:30:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDUQIx013633 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 05:30:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUOKQ013606 for ; Mon, 16 Feb 2004 05:30:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDQQVd013565; Mon, 16 Feb 2004 05:26:26 -0800 Date: Mon, 16 Feb 2004 05:26:26 -0800 Message-Id: <200402161326.i1GDQQVd013565@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 222] file truncation after fsync() and following reset. X-Bugzilla-Reason: AssignedTo X-archive-position: 2091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=222 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WORKSFORME ------- Additional Comments From hch@xfs.org 2004-16-02 05:26 PDT ------- Really closing now after I claimed to close in in January ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 05:30:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 05:30:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUQKO013636 for ; Mon, 16 Feb 2004 05:30:26 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDUQHB013634 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 05:30:26 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GDUOKO013606 for ; Mon, 16 Feb 2004 05:30:24 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDSmXN013589; Mon, 16 Feb 2004 05:28:48 -0800 Date: Mon, 16 Feb 2004 05:28:48 -0800 Message-Id: <200402161328.i1GDSmXN013589@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 255] 2.5.72: kernel BUG at fs/xfs/pagebuf/page_buf.c:1288 X-Bugzilla-Reason: AssignedTo X-archive-position: 2092 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=255 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-16-02 05:28 PDT ------- Really closing after I claimed to do so in January. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:20:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:20:50 -0800 (PST) Received: from medoc.inf.ethz.ch (medoc.inf.ethz.ch [129.132.178.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GEKkKO023932 for ; Mon, 16 Feb 2004 06:20:47 -0800 Received: from localhost (localhost [127.0.0.1]) by medoc.inf.ethz.ch (Postfix) with ESMTP id 56942D972 for ; Mon, 16 Feb 2004 15:20:45 +0100 (MET) Received: from medoc.inf.ethz.ch ([127.0.0.1]) by localhost (medoc [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03903-01-2 for ; Mon, 16 Feb 2004 15:20:44 +0100 (MET) Received: by medoc.inf.ethz.ch (Postfix, from userid 42460) id A1575D973; Mon, 16 Feb 2004 15:20:44 +0100 (MET) Received: from ikarus.inf.ethz.ch (ikarus.inf.ethz.ch [129.132.10.58]) by www.mail.inf.ethz.ch (IMP) with HTTP for ; Mon, 16 Feb 2004 15:20:44 +0100 Message-ID: <1076941244.4030d1bc0eb22@www.mail.inf.ethz.ch> Date: Mon, 16 Feb 2004 15:20:44 +0100 From: mschmitt@inf.ethz.ch To: linux-xfs@oss.sgi.com Subject: XFS: Filesystem sd(8,50) has duplicate UUID - can't mount MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 129.132.10.58 X-Virus-Scanned: by amavisd-new at inf.ethz.ch Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1GEKmKO023933 X-archive-position: 2092 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs We have the following error in the dmesg output: xfs_force_shutdown(sd(8,50),0x8) called from line 1071 of file xfs_trans.c. Return address = 0xf91fe4a6 Filesystem "sd(8,50)": Corruption of in-memory data detected. Shutting down filesystem: sd(8,50) I stopped all services that access that partition and tried xfs_repair: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_repair. If you are unable to mount the filesystem, then use the -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. So I tried to mount the filesystem again: mount -LNH1 /export/home/h1 -o logbufs=8,logbsize=65536,usrquota mount: wrong fs type, bad option, bad superblock on /dev/sdd2, or too many mounted file systems Which showed the following message in dmesg: XFS: Filesystem sd(8,50) has duplicate UUID - can't mount What does that mean? Is there a chance I can replay the log anyway? Any hints will be appreciated. Thanks Greetz Marc From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:56 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUWKO024561 for ; Mon, 16 Feb 2004 06:30:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUWKh024551 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKU024471 for ; Mon, 16 Feb 2004 06:30:28 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDdGdb015265; Mon, 16 Feb 2004 05:39:16 -0800 Date: Mon, 16 Feb 2004 05:39:16 -0800 Message-Id: <200402161339.i1GDdGdb015265@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 259] xfs_freeze gets stuck in "D" state in the function "down" X-Bugzilla-Reason: AssignedTo X-archive-position: 2098 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=259 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-16-02 05:39 PDT ------- Really closing now as it's not reproducible ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUWKO024557 for ; Mon, 16 Feb 2004 06:30:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUW0F024552 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKQ024471 for ; Mon, 16 Feb 2004 06:30:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDWVf0014105; Mon, 16 Feb 2004 05:32:31 -0800 Date: Mon, 16 Feb 2004 05:32:31 -0800 Message-Id: <200402161332.i1GDWVf0014105@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 277] xfs_force_shutdown after kernel bug X-Bugzilla-Reason: AssignedTo X-archive-position: 2094 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=277 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |REMIND ------- Additional Comments From hch@xfs.org 2004-16-02 05:32 PDT ------- Marking REMIND as it's absolutely not reproducible ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:31:03 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUWKO024560 for ; Mon, 16 Feb 2004 06:30:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUWwA024553 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKa024471 for ; Mon, 16 Feb 2004 06:30:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDYsf4014575; Mon, 16 Feb 2004 05:34:54 -0800 Date: Mon, 16 Feb 2004 05:34:54 -0800 Message-Id: <200402161334.i1GDYsf4014575@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 286] Kernel BUG at buffer.c:568 X-Bugzilla-Reason: AssignedTo X-archive-position: 2100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=286 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |REMIND ------- Additional Comments From hch@xfs.org 2004-16-02 05:34 PDT ------- Marking REMIND. This thing looks impossible from the XFS perspective and doesn't seem to be reproducible. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUXKO024584 for ; Mon, 16 Feb 2004 06:30:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUXQP024582 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:33 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKo024471 for ; Mon, 16 Feb 2004 06:30:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEG88r016697; Mon, 16 Feb 2004 06:16:08 -0800 Date: Mon, 16 Feb 2004 06:16:08 -0800 Message-Id: <200402161416.i1GEG88r016697@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 309] New: xfs_iget_core: ambiguous vns: vp/0xc7e23380, invp/0xc4a2fc80 X-Bugzilla-Reason: AssignedTo X-archive-position: 2095 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=309 Summary: xfs_iget_core: ambiguous vns: vp/0xc7e23380, invp/0xc4a2fc80 Product: Linux XFS Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: sgi@stone.nu Don't know if this is a XFS bug or not. But here goes. This happend on our NFS storage server. OS: Linux wwwfs-01 2.6.2 #2 SMP Tue Feb 10 22:29:17 EST 2004 i686 unknown xfs_iget_core: ambiguous vns: vp/0xc7e23380, invp/0xc4a2fc80 ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:106! invalid operand: 0000 [#1] CPU: 0 EIP: 0060:[cmn_err+157/173] Not tainted EFLAGS: 00010246 EIP is at cmn_err+0x9d/0xad eax: 00000040 ebx: 00000000 ecx: f761a080 edx: c036e4dc esi: c03483d7 edi: c043459e ebp: 00000293 esp: f6015a68 ds: 007b es: 007b ss: 0068 Process nfsd (pid: 2536, threadinfo=f6014000 task=f761a080) Stack: c034869e c0337a8f c0434560 c04199c0 00c00678 00000000 d338fb70 c0219149 00000000 c0342500 c7e23380 c4a2fc80 f7edfa3c c0167286 c1baea00 c1b5b7a8 c04199c0 c1bc0124 f6014000 c1baea00 f7edfa3c c1b5b7a4 00000000 00000000 Call Trace: [xfs_iget_core+1183/1449] xfs_iget_core+0x49f/0x5a9 [get_new_inode_fast+74/218] get_new_inode_fast+0x4a/0xda [xfs_iget+343/393] xfs_iget+0x157/0x189 [xfs_vget+104/220] xfs_vget+0x68/0xdc [vfs_vget+52/56] vfs_vget+0x34/0x38 [linvfs_get_dentry+83/138] linvfs_get_dentry+0x53/0x8a [find_exported_dentry+68/1691] find_exported_dentry+0x44/0x69b [xfs_iget+247/393] xfs_iget+0xf7/0x189 [iget_locked+105/186] iget_locked+0x69/0xba [xfs_iunlock+55/113] xfs_iunlock+0x37/0x71 [xfs_vget+202/220] xfs_vget+0xca/0xdc [iput+63/124] iput+0x3f/0x7c [in_group_p+37/45] in_group_p+0x25/0x2d [alloc_skb+71/224] alloc_skb+0x47/0xe0 [sock_alloc_send_pskb+197/481] sock_alloc_send_pskb+0xc5/0x1e1 [_end+944038524/1069274584] ip_fw_check+0x75a/0x8b2 [ipchains] [dev_queue_xmit+430/564] dev_queue_xmit+0x1ae/0x234 [ip_finish_output2+166/420] ip_finish_output2+0xa6/0x1a4 [ip_finish_output2+0/420] ip_finish_output2+0x0/0x1a4 [nf_hook_slow+212/291] nf_hook_slow+0xd4/0x123 [exp_find_key+133/152] exp_find_key+0x85/0x98 [export_decode_fh+92/120] export_decode_fh+0x5c/0x78 [nfsd_acceptable+0/252] nfsd_acceptable+0x0/0xfc [fh_verify+473/1338] fh_verify+0x1d9/0x53a [nfsd_acceptable+0/252] nfsd_acceptable+0x0/0xfc [udp_push_pending_frames+330/625] udp_push_pending_frames+0x14a/0x271 [nfsd_open+56/311] nfsd_open+0x38/0x137 [nfsd_read+82/941] nfsd_read+0x52/0x3ad [__wake_up_common+56/87] __wake_up_common+0x38/0x57 [nfsd3_proc_read+222/359] nfsd3_proc_read+0xde/0x167 [nfsd_dispatch+232/485] nfsd_dispatch+0xe8/0x1e5 [svc_process+1184/1635] svc_process+0x4a0/0x663 [apic_timer_interrupt+26/32] apic_timer_interrupt+0x1a/0x20 [nfsd+490/910] nfsd+0x1ea/0x38e ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:54 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUWKO024558 for ; Mon, 16 Feb 2004 06:30:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUWnq024555 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKg024471 for ; Mon, 16 Feb 2004 06:30:30 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDaqgn015085; Mon, 16 Feb 2004 05:36:52 -0800 Date: Mon, 16 Feb 2004 05:36:52 -0800 Message-Id: <200402161336.i1GDaqgn015085@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 288] XFS NULL pointer dereference at virtual address 0000005c X-Bugzilla-Reason: AssignedTo X-archive-position: 2097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=288 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From hch@xfs.org 2004-16-02 05:36 PDT ------- All OOM conditions are fixed in CVS for a while. There's still a problem when running out of vmalloc space, but I have an SGI-internal bug to track that one. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUZKO024631 for ; Mon, 16 Feb 2004 06:30:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUZCu024629 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:35 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKs024471 for ; Mon, 16 Feb 2004 06:30:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDlHPV015608; Mon, 16 Feb 2004 05:47:17 -0800 Date: Mon, 16 Feb 2004 05:47:17 -0800 Message-Id: <200402161347.i1GDlHPV015608@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 308] New: SGID bit gets lost with default ACL and owner not in dir group X-Bugzilla-Reason: AssignedTo X-archive-position: 2093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=308 Summary: SGID bit gets lost with default ACL and owner not in dir group Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: major Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: s.hetze@linux-ag.de SGID inheritance fails if user is not in directory group and default ACL is not empty. Specially with Linux distributions where all users share the same primary group (like SuSE) this is likely to introduce security problems in real live scenario with not technical users. I attach a script to trigger the bogous behavior. I already took a look into the source, but since the inheritance works correct if the user is in the directory group and irix_sgid_inherit set to 0 I am lost without clue what causes this bug. Maybe someone out there can help... --snip here --- script follows ------------ #! /bin/bash # set this to somewhere in the XFS tree testroot=/home/some-XFS-test-dir # if you enable this part, the testusers and groups are created. if(false) then adduser --disabled-password --no-create-home --gecos "test1" test1 adduser --disabled-password --no-create-home --gecos "test2" test2 addgroup testgroup1 addgroup testgroup2 adduser test1 testgroup1 adduser test2 testgroup1 adduser test2 testgroup2 fi # just in case you perform this test repeatedly rm -fr ${testroot}/testgroup? # we want to make shure irix_sgid_inherit is off echo "irix_sgid_inherit on startup:" cat /proc/sys/fs/xfs/irix_sgid_inherit echo "We force irix_sgid_inherit to 0:" echo 0 > /proc/sys/fs/xfs/irix_sgid_inherit cat /proc/sys/fs/xfs/irix_sgid_inherit # some basic setup for our test environment umask 0007 mkdir ${testroot}/testgroup1 chown test1.testgroup1 ${testroot}/testgroup1 mkdir ${testroot}/testgroup2 chown test2.testgroup2 ${testroot}/testgroup2 mkdir ${testroot}/testgroup3 chown test1.testgroup2 ${testroot}/testgroup3 chmod 2770 ${testroot}/testgroup3 # first we see what SGID is supposed to do... su test1 -c chmod 2770 ${testroot}/testgroup1 su test2 -c mkdir ${testroot}/testgroup1/testdir1 su test2 -c mkdir ${testroot}/testgroup1/testdir1/testdir2 echo "Nothing special here: SGID is inherited from parent" ls -ld ${testroot}/testgroup1/ ls -ld ${testroot}/testgroup1/testdir1 ls -ld ${testroot}/testgroup1/testdir1/testdir2 # As long as owner is in directory group, no problems with SGID inheritance # even if default ACL is set echo echo "First check: ordinary group dir" su test2 -c mkdir ${testroot}/testgroup1/testdir3 su test2 -c "setfacl -m d:g:testgroup2:rwx ${testroot}/testgroup1/testdir3" su test2 -c "setfacl -m g:testgroup2:rwx ${testroot}/testgroup1/testdir3" su test2 -c mkdir ${testroot}/testgroup1/testdir3/testdir4 echo "nothing changes here with default ACL as long as owner is in group" ls -ld ${testroot}/testgroup1/ ls -ld ${testroot}/testgroup1/testdir3/ getfacl ${testroot}/testgroup1/testdir3 ls -ld ${testroot}/testgroup1/testdir3/testdir4 getfacl ${testroot}/testgroup1/testdir3/testdir4 echo # without default ACL user does not need to be in directory group echo "Second check: home dir with external group (user does not belong to)" su test1 -c mkdir ${testroot}/testgroup3/testdir1 su test1 -c mkdir ${testroot}/testgroup3/testdir1/testdir2 echo "The first generation of DIRs living in the SGID parent are owned by that group" ls -ld ${testroot}/testgroup3/testdir1 echo "with irix_sgid_inherit set to 0 we get inheritance for SGID here:" ls -ld ${testroot}/testgroup3/testdir1/testdir2 echo # this is more or less the same, owner gets write access through # access ACL echo "Third check: group dir with additional write access" su test2 -c chmod 2770 ${testroot}/testgroup2 echo "testgroup1 gets acl write access to testgroup2 dir" su test2 -c "setfacl -m g:testgroup1:rwx ${testroot}/testgroup2" echo -n "test1 can make dir and subdir " su test1 -c mkdir ${testroot}/testgroup2/testdir1 su test1 -c mkdir ${testroot}/testgroup2/testdir1/testdir2 echo "and the SGID keeps inherited" ls -ld ${testroot}/testgroup2/ ls -ld ${testroot}/testgroup2/testdir1/ ls -ld ${testroot}/testgroup2/testdir1/testdir2 getfacl ${testroot}/testgroup2 # here we finally get the bug: echo "Final check: group dir with default ACL" echo "now testgroup1 gets default ACL with write access to testdir3" su test2 -c mkdir ${testroot}/testgroup2/testdir3 su test2 -c "setfacl -m g:testgroup1:rwx ${testroot}/testgroup2/testdir3" su test2 -c "setfacl -m d:g:testgroup1:rwx ${testroot}/testgroup2/testdir3" echo "test1 again can make subdir and first generation is owned by testgroup2" echo "but SGID bit itself is lost..." su test1 -c mkdir ${testroot}/testgroup2/testdir3/testdir4 ls -ld ${testroot}/testgroup2/testdir3 ls -ld ${testroot}/testgroup2/testdir3/testdir4 getfacl ${testroot}/testgroup2/testdir3 # again, if you enable this users and groups will be deleted upon # completetion if(false) then deluser test1 deluser test2 delgroup testgroup2 delgroup testgroup1 fi ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:53 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUWKO024577 for ; Mon, 16 Feb 2004 06:30:33 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUWWR024563 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKk024471 for ; Mon, 16 Feb 2004 06:30:31 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDUqd5013723; Mon, 16 Feb 2004 05:30:52 -0800 Date: Mon, 16 Feb 2004 05:30:52 -0800 Message-Id: <200402161330.i1GDUqd5013723@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 261] linux kernel 2.5.73 / xfsprogs 2.3.9 fails on striped devices with 2K block size X-Bugzilla-Reason: AssignedTo X-archive-position: 2096 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=261 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-16-02 05:30 PDT ------- Old release of XFS require 512byte sector sizes, and as any input from the submitter is missing for half a year I can only assume those are used. Closing as INVALID ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 06:30:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 06:30:57 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEUWKO024559 for ; Mon, 16 Feb 2004 06:30:32 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEUWg9024554 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 06:30:32 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GEURKc024471 for ; Mon, 16 Feb 2004 06:30:29 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GDXQ5r014285; Mon, 16 Feb 2004 05:33:26 -0800 Date: Mon, 16 Feb 2004 05:33:26 -0800 Message-Id: <200402161333.i1GDXQ5r014285@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 278] xfs_growfs crashes with kernel bug for negative grow sizes X-Bugzilla-Reason: AssignedTo X-archive-position: 2099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=278 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |INVALID ------- Additional Comments From hch@xfs.org 2004-16-02 05:33 PDT ------- Marking invalid as the report was confusing. Nathan fixed the signed/unsigned issue anyway. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 07:30:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 07:30:45 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GFUSKO006926 for ; Mon, 16 Feb 2004 07:30:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GFUSHt006923 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 07:30:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GFUPKc006877 for ; Mon, 16 Feb 2004 07:30:26 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEZ94u027684; Mon, 16 Feb 2004 06:35:09 -0800 Date: Mon, 16 Feb 2004 06:35:09 -0800 Message-Id: <200402161435.i1GEZ94u027684@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 309] xfs_iget_core: ambiguous vns: vp/0xc7e23380, invp/0xc4a2fc80 X-Bugzilla-Reason: AssignedTo X-archive-position: 2103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=309 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|xfs-master@oss.sgi.com |hch@xfs.org ------- Additional Comments From hch@xfs.org 2004-16-02 06:35 PDT ------- This already was reported to the kernel bugzilla at http://bugme.osdl.org/show_bug.cgi?id=870, but I've failed to reproduce it sofar. I'll try harder to reproduce and fix it. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 07:30:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 07:30:44 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GFUSKO006924 for ; Mon, 16 Feb 2004 07:30:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GFUSHm006921 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 07:30:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GFUPKU006877 for ; Mon, 16 Feb 2004 07:30:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEaq4I027752; Mon, 16 Feb 2004 06:36:52 -0800 Date: Mon, 16 Feb 2004 06:36:52 -0800 Message-Id: <200402161436.i1GEaq4I027752@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 308] SGID bit gets lost with default ACL and owner not in dir group X-Bugzilla-Reason: AssignedTo X-archive-position: 2102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=308 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE ------- Additional Comments From hch@xfs.org 2004-16-02 06:36 PDT ------- *** This bug has been marked as a duplicate of 280 *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 07:30:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 07:30:44 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GFUSKO006925 for ; Mon, 16 Feb 2004 07:30:28 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GFUSFa006920 for linux-xfs@oss.sgi.com; Mon, 16 Feb 2004 07:30:28 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1GFUPKS006877 for ; Mon, 16 Feb 2004 07:30:25 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1GEaqFL027756; Mon, 16 Feb 2004 06:36:52 -0800 Date: Mon, 16 Feb 2004 06:36:52 -0800 Message-Id: <200402161436.i1GEaqFL027756@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 280] still a bug in sgid inheritance with ACLs activated (I know about fs.xfs.irix_sgid_inherit) X-Bugzilla-Reason: AssignedTo X-archive-position: 2101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=280 hch@xfs.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |s.hetze@linux-ag.de ------- Additional Comments From hch@xfs.org 2004-16-02 06:36 PDT ------- *** Bug 308 has been marked as a duplicate of this bug. *** ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Mon Feb 16 08:15:49 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 08:16:03 -0800 (PST) Received: from medoc.inf.ethz.ch (medoc.inf.ethz.ch [129.132.178.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GGFcKO008630 for ; Mon, 16 Feb 2004 08:15:38 -0800 Received: from localhost (localhost [127.0.0.1]) by medoc.inf.ethz.ch (Postfix) with ESMTP id A1450DB31; Mon, 16 Feb 2004 16:38:52 +0100 (MET) Received: from medoc.inf.ethz.ch ([127.0.0.1]) by localhost (medoc [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15575-01-7; Mon, 16 Feb 2004 16:38:52 +0100 (MET) Received: by medoc.inf.ethz.ch (Postfix, from userid 42460) id 587A0DB33; Mon, 16 Feb 2004 16:38:52 +0100 (MET) Received: from 129.132.10.58 (SquirrelMail authenticated user mschmitt) by www.mail.inf.ethz.ch with HTTP; Mon, 16 Feb 2004 16:38:52 +0100 (MET) Message-ID: <32871.129.132.10.58.1076945932.squirrel@www.mail.inf.ethz.ch> In-Reply-To: <1076941244.4030d1bc0eb22@www.mail.inf.ethz.ch> References: <1076941244.4030d1bc0eb22@www.mail.inf.ethz.ch> Date: Mon, 16 Feb 2004 16:38:52 +0100 (MET) Subject: Re: XFS: Filesystem sd(8,50) has duplicate UUID - can't mount From: mschmitt@inf.ethz.ch To: mschmitt@inf.ethz.ch Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at inf.ethz.ch Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1GGFnKO008632 X-archive-position: 2104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Found a hint in the archive, mounting with -nouuid worked, the log was successfully replayed. I forgot to mention what version I'm using: 2.4.20-28_36.rh7.3.atsmp (xfs 1.3.0) The machine acts as NFS/Samba server and was under very high load all day long today (20-80). I just switched the data (800GB, home directories of about 200 users) two days ago from ext3 to xfs because I was hoping for stable quota support. Sigh. Any idea how to find out what could have been the problem? The xfs_repair (xfsprogs-2.6.2-0_7.rh7.3.at) is still running and will continue doing so for a while, I guess... TIA Marc From owner-linux-xfs@oss.sgi.com Mon Feb 16 08:49:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 08:50:00 -0800 (PST) Received: from medoc.inf.ethz.ch (medoc.inf.ethz.ch [129.132.178.200]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GGnZKO012255 for ; Mon, 16 Feb 2004 08:49:35 -0800 Received: from localhost (localhost [127.0.0.1]) by medoc.inf.ethz.ch (Postfix) with ESMTP id B6504DB3F; Mon, 16 Feb 2004 17:21:16 +0100 (MET) Received: from medoc.inf.ethz.ch ([127.0.0.1]) by localhost (medoc [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22263-01-3; Mon, 16 Feb 2004 17:21:16 +0100 (MET) Received: by medoc.inf.ethz.ch (Postfix, from userid 42460) id 6D2C6DB3E; Mon, 16 Feb 2004 17:21:16 +0100 (MET) Received: from 129.132.10.58 (SquirrelMail authenticated user mschmitt) by www.mail.inf.ethz.ch with HTTP; Mon, 16 Feb 2004 17:21:15 +0100 (MET) Message-ID: <32995.129.132.10.58.1076948475.squirrel@www.mail.inf.ethz.ch> In-Reply-To: <32871.129.132.10.58.1076945932.squirrel@www.mail.inf.ethz.ch> References: <1076941244.4030d1bc0eb22@www.mail.inf.ethz.ch> <32871.129.132.10.58.1076945932.squirrel@www.mail.inf.ethz.ch> Date: Mon, 16 Feb 2004 17:21:15 +0100 (MET) Subject: Re: XFS: Filesystem sd(8,50) has duplicate UUID - can't mount From: mschmitt@inf.ethz.ch To: mschmitt@inf.ethz.ch Cc: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at inf.ethz.ch Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1GGnkKO012256 X-archive-position: 2105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mschmitt@inf.ethz.ch Precedence: bulk X-list: linux-xfs Well, the xfs_repair did not fix the problem. I'm running NFS/SMB now on the fs mounted with -nouuid, I hope that's not a problem... Will the error message in the subject go away with a reboot only? Greetz Marc > Any idea how to find out what could have been the problem? The xfs_repair > (xfsprogs-2.6.2-0_7.rh7.3.at) is still running and will continue doing so > for a while, I guess... From owner-linux-xfs@oss.sgi.com Mon Feb 16 11:44:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 11:44:50 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GJiXKO015069 for ; Mon, 16 Feb 2004 11:44:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1GJVjHH014009 for ; Mon, 16 Feb 2004 11:31:45 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1GJVijh34308848; Mon, 16 Feb 2004 13:31:44 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1GJVioa690189; Mon, 16 Feb 2004 13:31:44 -0600 (CST) Date: Mon, 16 Feb 2004 13:31:44 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: mschmitt@inf.ethz.ch cc: linux-xfs@oss.sgi.com Subject: Re: XFS: Filesystem sd(8,50) has duplicate UUID - can't mount In-Reply-To: <32995.129.132.10.58.1076948475.squirrel@www.mail.inf.ethz.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2106 X-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 Was the filesystem ever cloned or snapshotted? do you have other xfs filesystems mounted? we could use xfs_db to look at superblocks on each, and see why it thinks it's a duplicate uuid... hm, or perhaps it thinks the filesystem is mounted twice somehow...? -Eric On Mon, 16 Feb 2004 mschmitt@inf.ethz.ch wrote: > Well, the xfs_repair did not fix the problem. I'm running NFS/SMB now on > the fs mounted with -nouuid, I hope that's not a problem... > Will the error message in the subject go away with a reboot only? > > Greetz > Marc > > > Any idea how to find out what could have been the problem? The xfs_repair > > (xfsprogs-2.6.2-0_7.rh7.3.at) is still running and will continue doing so > > for a while, I guess... > > From owner-linux-xfs@oss.sgi.com Mon Feb 16 12:59:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 12:59:50 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GKxXKO019473 for ; Mon, 16 Feb 2004 12:59:34 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1GKxSB7011334 for ; Mon, 16 Feb 2004 14:59:28 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1GKxQfF26620115 for ; Mon, 16 Feb 2004 12:59:27 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GKxOhI9554369 for ; Tue, 17 Feb 2004 07:59:25 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1GKxO2111067870 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 07:59:24 +1100 (EST) Date: Tue, 17 Feb 2004 07:59:24 +1100 (EST) From: Nathan Scott Message-Id: <200402162059.i1GKxO2111067870@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.25-rc3 X-archive-position: 2107 X-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: Mon Feb 16 12:54:37 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:166816a Makefile - 1.9 drivers/atm/he.c - 1.2 drivers/message/fusion/linux_compat.h - 1.3 drivers/message/fusion/mptbase.h - 1.3 drivers/message/fusion/mptctl.c - 1.3 drivers/message/fusion/mptscsih.c - 1.3 fs/ntfs/support.c - 1.2 include/linux/atmdev.h - 1.2 include/linux/sonet.h - 1.2 lib/vsprintf.c - 1.3 net/core/ethtool.c - 1.2 net/decnet/dn_rules.c - 1.2 net/ipv4/fib_rules.c - 1.2 net/sched/sch_sfq.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Feb 16 13:03:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 13:03:42 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GL3SKO019967 for ; Mon, 16 Feb 2004 13:03:29 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1GL3NB7012435 for ; Mon, 16 Feb 2004 15:03:23 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1GL3Mf926495283 for ; Mon, 16 Feb 2004 13:03:22 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GL3LhI11039120 for ; Tue, 17 Feb 2004 08:03:21 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1GL3KZN11052032 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 08:03:20 +1100 (EST) Date: Tue, 17 Feb 2004 08:03:20 +1100 (EST) From: Nathan Scott Message-Id: <200402162103.i1GL3KZN11052032@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.3-rc3 X-archive-position: 2108 X-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: Mon Feb 16 13:01:25 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166817a drivers/char/watchdog/i8xx_tco.c - 1.1 drivers/char/watchdog/i8xx_tco.h - 1.1 drivers/char/watchdog/pcwd_pci.c - 1.1 drivers/video/aty/ati_ids.h - 1.1 drivers/video/aty/radeon_accel.c - 1.1 drivers/video/aty/radeon_base.c - 1.1 drivers/video/aty/radeon_i2c.c - 1.1 drivers/video/aty/radeon_monitor.c - 1.1 drivers/video/aty/radeon_pm.c - 1.1 drivers/video/aty/radeonfb.h - 1.1 include/asm-ppc64/bootx.h - 1.1 include/asm-ppc64/btext.h - 1.1 include/asm-ppc64/dbdma.h - 1.1 include/asm-ppc64/keylargo.h - 1.1 include/asm-ppc64/macio.h - 1.1 include/asm-ppc64/of_device.h - 1.1 include/asm-ppc64/pmac_feature.h - 1.1 arch/sh/configs/defconfig-hp680 - 1.1 arch/sh/boards/hp6xx/hp680/setup.c - 1.1 include/asm-ppc64/pmac_low_i2c.h - 1.1 include/asm-ppc64/uninorth.h - 1.1 arch/ppc64/kernel/smp-tbsync.c - 1.1 arch/ppc64/kernel/pmac_time.c - 1.1 arch/ppc64/kernel/pmac_smp.c - 1.1 arch/ppc64/kernel/pmac_setup.c - 1.1 arch/ppc64/kernel/pmac_pci.c - 1.1 arch/ppc64/kernel/pmac_nvram.c - 1.1 arch/ppc64/kernel/pmac_low_i2c.c - 1.1 arch/ppc64/kernel/pmac_feature.c - 1.1 arch/ppc64/kernel/pmac.h - 1.1 arch/ppc64/kernel/pci_dma_direct.c - 1.1 arch/ppc64/kernel/pSeries_nvram.c - 1.1 arch/ppc64/kernel/open_pic_u3.c - 1.1 arch/ppc64/kernel/of_device.c - 1.1 arch/ppc64/kernel/idle_power4.S - 1.1 arch/ppc64/kernel/cpu_setup_power4.S - 1.1 arch/ppc64/kernel/btext.c - 1.1 arch/ppc64/configs/pSeries_defconfig - 1.1 arch/ppc64/configs/g5_defconfig - 1.1 arch/ppc/platforms/4xx/oak.c - 1.1 arch/ppc/boot/common/bootinfo.c - 1.1 Makefile - 1.8 arch/alpha/kernel/core_apecs.c - 1.2 arch/alpha/kernel/core_cia.c - 1.2 arch/alpha/kernel/core_irongate.c - 1.2 arch/alpha/kernel/core_lca.c - 1.2 arch/alpha/kernel/core_marvel.c - 1.2 arch/alpha/kernel/core_mcpcia.c - 1.2 arch/alpha/kernel/core_polaris.c - 1.2 arch/alpha/kernel/core_t2.c - 1.2 arch/alpha/kernel/core_titan.c - 1.2 arch/alpha/kernel/core_tsunami.c - 1.2 arch/alpha/kernel/core_wildfire.c - 1.2 arch/arm/common/amba.c - 1.3 arch/arm/kernel/time.c - 1.2 arch/arm/mach-sa1100/generic.c - 1.3 arch/arm/mm/Kconfig - 1.2 arch/i386/Kconfig - 1.4 arch/i386/kernel/acpi/boot.c - 1.6 arch/i386/kernel/cpu/cpufreq/gx-suspmod.c - 1.2 arch/i386/kernel/cpu/cpufreq/longhaul.c - 1.3 arch/i386/kernel/cpu/cpufreq/p4-clockmod.c - 1.4 arch/i386/kernel/cpu/cpufreq/powernow-k7.c - 1.3 arch/i386/kernel/cpu/cpufreq/powernow-k8.c - 1.3 arch/i386/kernel/cpu/cpufreq/powernow-k8.h - 1.2 arch/i386/kernel/cpu/cpufreq/speedstep-lib.c - 1.4 arch/i386/kernel/cpu/intel.c - 1.3 arch/i386/kernel/mpparse.c - 1.5 arch/ia64/defconfig - 1.4 arch/ia64/hp/common/sba_iommu.c - 1.4 arch/ia64/kernel/acpi.c - 1.6 arch/ia64/kernel/efivars.c - 1.2 arch/ia64/kernel/irq.c - 1.4 arch/ia64/kernel/mca.c - 1.3 arch/ia64/kernel/salinfo.c - 1.3 arch/ia64/kernel/smp.c - 1.3 arch/ia64/kernel/smpboot.c - 1.5 arch/ia64/kernel/traps.c - 1.3 arch/ia64/kernel/unaligned.c - 1.3 arch/ia64/lib/io.c - 1.4 arch/ia64/scripts/toolchain-flags - 1.2 arch/ia64/sn/kernel/mca.c - 1.4 arch/ia64/sn/kernel/setup.c - 1.4 arch/ia64/sn/kernel/sn2/cache.c - 1.3 arch/ia64/sn/kernel/sn2/sn2_smp.c - 1.5 arch/m68k/Kconfig - 1.3 arch/ppc/Kconfig - 1.4 arch/ppc/boot/simple/Makefile - 1.3 arch/ppc/boot/simple/misc-spruce.c - 1.2 arch/ppc/boot/simple/misc.c - 1.2 arch/ppc/configs/spruce_defconfig - 1.2 arch/ppc/kernel/entry.S - 1.2 arch/ppc/kernel/head_44x.S - 1.2 arch/ppc/kernel/misc.S - 1.4 arch/ppc/kernel/pci.c - 1.3 arch/ppc/mm/44x_mmu.c - 1.2 arch/ppc/platforms/4xx/Kconfig - 1.2 arch/ppc/platforms/4xx/Makefile - 1.2 arch/ppc/platforms/4xx/beech.c - 1.2 arch/ppc/platforms/4xx/beech.h - 1.2 arch/ppc/platforms/4xx/cedar.c - 1.2 arch/ppc/platforms/4xx/cedar.h - 1.2 arch/ppc/platforms/4xx/ibm405lp.c - 1.2 arch/ppc/platforms/4xx/ibm405lp.h - 1.2 arch/ppc/platforms/4xx/ibmnp405l.c - 1.2 arch/ppc/platforms/4xx/ibmnp405l.h - 1.2 arch/ppc/platforms/4xx/ibmnp4gs.c - 1.2 arch/ppc/platforms/4xx/ibmnp4gs.h - 1.2 arch/ppc/platforms/4xx/ibmstb3.c - 1.2 arch/ppc/platforms/4xx/ibmstb3.h - 1.2 arch/ppc/platforms/4xx/oak.h - 1.2 arch/ppc/platforms/4xx/oak_setup.c - 1.2 arch/ppc/platforms/4xx/redwood.c - 1.2 arch/ppc/platforms/4xx/redwood.h - 1.2 arch/ppc/platforms/Makefile - 1.3 arch/ppc/platforms/pmac_feature.c - 1.3 arch/ppc/platforms/prep_setup.c - 1.2 arch/ppc/platforms/prep_time.c - 1.2 arch/ppc/platforms/spruce.h - 1.2 arch/ppc/platforms/spruce_setup.c - 1.2 arch/ppc/syslib/Makefile - 1.3 arch/ppc/syslib/ppc4xx_setup.c - 1.2 arch/ppc64/Kconfig - 1.4 arch/ppc64/boot/prom.c - 1.2 arch/ppc64/boot/zlib.c - 1.2 arch/ppc64/kernel/Makefile - 1.4 arch/ppc64/kernel/chrp_setup.c - 1.3 arch/ppc64/kernel/cputable.c - 1.3 arch/ppc64/kernel/head.S - 1.5 arch/ppc64/kernel/iSeries_pci.c - 1.3 arch/ppc64/kernel/iSeries_setup.c - 1.3 arch/ppc64/kernel/idle.c - 1.4 arch/ppc64/kernel/misc.S - 1.3 arch/ppc64/kernel/nvram.c - 1.3 arch/ppc64/kernel/open_pic.c - 1.3 arch/ppc64/kernel/open_pic.h - 1.2 arch/ppc64/kernel/open_pic_defs.h - 1.2 arch/ppc64/kernel/pSeries_pci.c - 1.4 arch/ppc64/kernel/pci.c - 1.3 arch/ppc64/kernel/pci_dma.c - 1.3 arch/ppc64/kernel/pci_dn.c - 1.3 arch/ppc64/kernel/ppc_ksyms.c - 1.4 arch/ppc64/kernel/process.c - 1.4 arch/ppc64/kernel/prom.c - 1.5 arch/ppc64/kernel/setup.c - 1.5 arch/ppc64/kernel/smp.c - 1.4 arch/ppc64/kernel/sys_ppc32.c - 1.4 arch/ppc64/kernel/traps.c - 1.3 arch/ppc64/kernel/udbg.c - 1.3 arch/ppc64/kernel/xics.c - 1.3 arch/ppc64/mm/fault.c - 1.2 arch/ppc64/mm/init.c - 1.3 arch/ppc64/xmon/privinst.h - 1.2 arch/ppc64/xmon/start.c - 1.4 arch/ppc64/xmon/xmon.c - 1.4 arch/sh/Kconfig - 1.4 arch/sh/boards/hp6xx/hp680/Makefile - 1.2 arch/sh/boards/hp6xx/hp680/mach.c - 1.3 arch/sh/cchips/hd6446x/hd64461/io.c - 1.3 arch/sh/defconfig - 1.2 arch/sh/kernel/cpu/rtc.c - 1.2 arch/sh/kernel/cpu/sh4/fpu.c - 1.3 arch/sh/kernel/entry.S - 1.3 arch/sh/kernel/irq.c - 1.4 arch/sh/kernel/process.c - 1.3 arch/sh/kernel/signal.c - 1.3 arch/sh/mm/cache-sh3.c - 1.3 arch/sh/mm/fault.c - 1.3 arch/sparc/Kconfig - 1.4 arch/sparc/kernel/irq.c - 1.4 arch/sparc/kernel/process.c - 1.3 arch/sparc/kernel/semaphore.c - 1.2 arch/sparc/kernel/smp.c - 1.2 arch/sparc/kernel/sparc_ksyms.c - 1.3 arch/sparc/lib/atomic.S - 1.2 arch/sparc64/Kconfig - 1.4 arch/sparc64/lib/VIScopy.S - 1.2 arch/x86_64/kernel/acpi/boot.c - 1.4 arch/x86_64/kernel/mpparse.c - 1.4 arch/x86_64/kernel/sys_x86_64.c - 1.4 drivers/acpi/Kconfig - 1.3 drivers/acpi/numa.c - 1.3 drivers/acpi/processor.c - 1.5 drivers/atm/he.c - 1.4 drivers/base/bus.c - 1.2 drivers/cdrom/cdrom.c - 1.4 drivers/char/sh-sci.c - 1.3 drivers/char/sh-sci.h - 1.3 drivers/char/sn_serial.c - 1.4 drivers/char/watchdog/Kconfig - 1.3 drivers/char/watchdog/Makefile - 1.3 drivers/char/watchdog/acquirewdt.c - 1.3 drivers/char/watchdog/advantechwdt.c - 1.3 drivers/char/watchdog/alim1535_wdt.c - 1.3 drivers/char/watchdog/alim7101_wdt.c - 1.3 drivers/char/watchdog/amd7xx_tco.c - 1.3 drivers/char/watchdog/i810-tco.c - 1.4 drivers/char/watchdog/i810-tco.h - 1.2 drivers/char/watchdog/indydog.c - 1.4 drivers/char/watchdog/sbc60xxwdt.c - 1.3 drivers/char/watchdog/sc520_wdt.c - 1.2 drivers/char/watchdog/scx200_wdt.c - 1.3 drivers/char/watchdog/shwdt.c - 1.3 drivers/char/watchdog/softdog.c - 1.4 drivers/char/watchdog/wafer5823wdt.c - 1.3 drivers/cpufreq/cpufreq_userspace.c - 1.2 drivers/i2c/busses/i2c-keywest.c - 1.4 drivers/ide/ppc/pmac.c - 1.3 drivers/macintosh/adb.c - 1.3 drivers/macintosh/macio_asic.c - 1.3 drivers/macintosh/via-pmu.c - 1.3 drivers/md/dm.c - 1.3 drivers/pci/pci-sysfs.c - 1.3 drivers/scsi/BusLogic.c - 1.4 drivers/scsi/BusLogic.h - 1.3 drivers/scsi/ata_piix.c - 1.3 drivers/scsi/libata-core.c - 1.4 drivers/scsi/libata-scsi.c - 1.3 drivers/scsi/libata.h - 1.3 drivers/scsi/sata_promise.c - 1.3 drivers/scsi/sata_via.c - 1.3 drivers/scsi/sr.c - 1.4 drivers/serial/8250.c - 1.3 drivers/serial/pmac_zilog.c - 1.3 drivers/serial/serial_core.c - 1.4 drivers/video/Kconfig - 1.4 drivers/video/Makefile - 1.4 drivers/video/aty/Makefile - 1.2 drivers/video/console/fbcon.c - 1.4 drivers/video/fbmem.c - 1.4 drivers/video/fbmon.c - 1.3 drivers/video/hitfb.c - 1.2 drivers/video/offb.c - 1.2 drivers/video/pvr2fb.c - 1.3 drivers/video/radeonfb.c - 1.4 drivers/video/riva/fbdev.c - 1.3 fs/jfs/jfs_logmgr.c - 1.2 fs/jfs/jfs_txnmgr.c - 1.2 fs/jfs/namei.c - 1.3 fs/namei.c - 1.3 fs/reiserfs/fix_node.c - 1.2 fs/smbfs/proc.c - 1.3 include/asm-alpha/pci.h - 1.3 include/asm-arm/pci.h - 1.3 include/asm-arm/setup.h - 1.2 include/asm-generic/local.h - 1.2 include/asm-h8300/pci.h - 1.3 include/asm-i386/atomic.h - 1.2 include/asm-i386/pci.h - 1.3 include/asm-ia64/fpswa.h - 1.2 include/asm-ia64/mca.h - 1.3 include/asm-ia64/mmu_context.h - 1.3 include/asm-ia64/pci.h - 1.3 include/asm-ia64/percpu.h - 1.2 include/asm-ia64/processor.h - 1.4 include/asm-m68k/pci.h - 1.4 include/asm-m68knommu/pci.h - 1.3 include/asm-mips/atomic.h - 1.2 include/asm-mips/pci.h - 1.4 include/asm-parisc/pci.h - 1.3 include/asm-ppc/bootinfo.h - 1.2 include/asm-ppc/ibm44x.h - 1.2 include/asm-ppc/mmu.h - 1.2 include/asm-ppc/pci.h - 1.4 include/asm-ppc/pgtable.h - 1.4 include/asm-ppc/pmac_feature.h - 1.3 include/asm-ppc/reg_booke.h - 1.2 include/asm-ppc64/lmb.h - 1.2 include/asm-ppc64/machdep.h - 1.3 include/asm-ppc64/mmzone.h - 1.3 include/asm-ppc64/nvram.h - 1.3 include/asm-ppc64/pci-bridge.h - 1.2 include/asm-ppc64/pci.h - 1.4 include/asm-ppc64/pci_dma.h - 1.2 include/asm-ppc64/ppcdebug.h - 1.2 include/asm-ppc64/processor.h - 1.4 include/asm-ppc64/prom.h - 1.3 include/asm-ppc64/sections.h - 1.2 include/asm-ppc64/smp.h - 1.3 include/asm-ppc64/system.h - 1.3 include/asm-ppc64/systemcfg.h - 1.2 include/asm-sh/hd64461/hd64461.h - 1.2 include/asm-sh/hd64461/io.h - 1.3 include/asm-sh/io_generic.h - 1.3 include/asm-sh/pci.h - 1.4 include/asm-sh/processor.h - 1.3 include/asm-sh/ptrace.h - 1.3 include/asm-sparc/atomic.h - 1.2 include/asm-sparc/dma-mapping.h - 1.2 include/asm-sparc/pci.h - 1.3 include/asm-sparc/processor.h - 1.3 include/asm-sparc/semaphore.h - 1.2 include/asm-sparc/system.h - 1.2 include/asm-sparc64/pci.h - 1.3 include/asm-v850/pci.h - 1.3 include/asm-x86_64/atomic.h - 1.2 include/asm-x86_64/pci.h - 1.3 include/linux/ata.h - 1.2 include/linux/atmdev.h - 1.2 include/linux/compiler.h - 1.3 include/linux/fb.h - 1.3 include/linux/ide.h - 1.7 include/linux/libata.h - 1.3 include/linux/list.h - 1.3 include/linux/sonet.h - 1.2 include/net/bluetooth/hci.h - 1.3 include/net/bluetooth/hci_core.h - 1.3 include/video/radeon.h - 1.2 kernel/kmod.c - 1.3 mm/fadvise.c - 1.3 mm/mmap.c - 1.5 mm/swapfile.c - 1.3 net/atm/clip.c - 1.5 net/ax25/ax25_route.c - 1.2 net/bluetooth/af_bluetooth.c - 1.4 net/bluetooth/bnep/sock.c - 1.2 net/bluetooth/hci_conn.c - 1.3 net/bluetooth/hci_core.c - 1.3 net/bluetooth/hci_event.c - 1.3 net/bluetooth/rfcomm/core.c - 1.3 net/bluetooth/rfcomm/tty.c - 1.2 net/sctp/socket.c - 1.4 net/sctp/ssnmap.c - 1.2 security/selinux/ss/avtab.c - 1.3 security/selinux/ss/policydb.c - 1.3 net/bluetooth/cmtp/sock.c - 1.2 arch/sh/kernel/cpu/init.c - 1.2 arch/ppc64/mm/hash_utils.c - 1.2 arch/ppc64/mm/hash_low.S - 1.3 drivers/video/fbsysfs.c - 1.2 drivers/macintosh/Kconfig - 1.2 From owner-linux-xfs@oss.sgi.com Mon Feb 16 13:17:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 13:17:36 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GLHVKO020505 for ; Mon, 16 Feb 2004 13:17:32 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 2BF451800A6 for ; Tue, 17 Feb 2004 08:17:20 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 14EA5C00A9; Tue, 17 Feb 2004 08:17:12 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 12412140086 for ; Tue, 17 Feb 2004 08:17:12 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - Merge up to 2.6.3-rc3 In-reply-to: Your message of "Tue, 17 Feb 2004 08:03:20 +1100." <200402162103.i1GL3KZN11052032@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Feb 2004 08:17:11 +1100 Message-ID: <8953.1076966231@ocs3.ocs.com.au> X-archive-position: 2109 X-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 FYI, 2.6.3-rc3 has a bug in serial console handling. http://marc.theaimsgroup.com/?l=linux-kernel&m=107693772704247&w=1 http://marc.theaimsgroup.com/?l=linux-kernel&m=107695907806351&w=1 http://marc.theaimsgroup.com/?l=linux-kernel&m=107696587014353&w=2 From owner-linux-xfs@oss.sgi.com Mon Feb 16 13:21:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 13:21:40 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GLLcKO020982 for ; Mon, 16 Feb 2004 13:21:38 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1GLKUB7017145 for ; Mon, 16 Feb 2004 15:20:31 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1GLKTf926643854 for ; Mon, 16 Feb 2004 13:20:30 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GLKShI11045910 for ; Tue, 17 Feb 2004 08:20:28 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1GLKSrl10960472 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 08:20:28 +1100 (EST) Date: Tue, 17 Feb 2004 08:20:28 +1100 (EST) From: Nathan Scott Message-Id: <200402162120.i1GLKSrl10960472@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - kdb for 2.6 X-archive-position: 2110 X-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 Merge in kdb-common patch for 2.6 Date: Mon Feb 16 13:14:18 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166818a Documentation/kdb/dump.txt - 1.1 Documentation/kdb/kdb.mm - 1.1 Documentation/kdb/kdb_bp.man - 1.1 Documentation/kdb/kdb_bt.man - 1.1 Documentation/kdb/kdb_env.man - 1.1 Documentation/kdb/kdb_ll.man - 1.1 Documentation/kdb/kdb_md.man - 1.1 Documentation/kdb/kdb_rd.man - 1.1 Documentation/kdb/kdb_sr.man - 1.1 Documentation/kdb/kdb_ss.man - 1.1 Documentation/kdb/slides - 1.1 kdb/Makefile - 1.1 kdb/kdbmain.c - 1.1 kdb/modules/kdbm_vm.c - 1.1 kdb/modules/kdbm_task.c - 1.1 include/linux/dis-asm.h - 1.1 include/linux/kdb.h - 1.1 include/linux/kdbprivate.h - 1.1 kdb/modules/kdbm_pg.c - 1.1 kdb/modules/Makefile - 1.1 kdb/ChangeLog - 1.1 kdb/kdbsupport.c - 1.1 kdb/kdb_bp.c - 1.1 kdb/kdb_bt.c - 1.1 kdb/kdb_id.c - 1.1 kdb/kdb_io.c - 1.1 kdb/kdb_cmds - 1.1 Makefile - 1.9 drivers/char/keyboard.c - 1.6 drivers/char/sn_serial.c - 1.5 drivers/serial/8250.c - 1.4 include/linux/sysctl.h - 1.6 init/main.c - 1.6 kernel/exit.c - 1.5 kernel/kallsyms.c - 1.2 kernel/module.c - 1.5 kernel/printk.c - 1.5 kernel/sched.c - 1.6 kernel/signal.c - 1.2 kernel/sysctl.c - 1.5 mm/memory.c - 1.5 scripts/Makefile - 1.2 scripts/kallsyms.c - 1.2 Subject: TAKE 904196 - Merge in kdb-i386 patch for 2.6 Date: Mon Feb 16 13:17:17 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166819a kdb/modules/kdbm_x86.c - 1.1 include/asm-i386/kdbprivate.h - 1.1 arch/i386/kdb/ChangeLog - 1.1 arch/i386/kdb/Makefile - 1.1 arch/i386/kdb/ansidecl.h - 1.1 arch/i386/kdb/bfd.h - 1.1 arch/i386/kdb/i386-dis.c - 1.1 arch/i386/kdb/kdba_bp.c - 1.1 arch/i386/kdb/kdba_bt.c - 1.1 arch/i386/kdb/kdba_id.c - 1.1 arch/i386/kdb/kdba_io.c - 1.1 arch/i386/kdb/kdbasupport.c - 1.1 arch/i386/kdb/pc_keyb.h - 1.1 include/asm-i386/kdb.h - 1.1 arch/i386/Kconfig - 1.5 arch/i386/Makefile - 1.2 arch/i386/kernel/entry.S - 1.2 arch/i386/kernel/i8259.c - 1.3 arch/i386/kernel/io_apic.c - 1.4 arch/i386/kernel/nmi.c - 1.2 arch/i386/kernel/reboot.c - 1.3 arch/i386/kernel/smp.c - 1.2 arch/i386/kernel/smpboot.c - 1.3 arch/i386/kernel/traps.c - 1.2 arch/i386/kernel/vmlinux.lds.S - 1.2 include/asm-i386/kmap_types.h - 1.2 include/asm-i386/mach-default/irq_vectors.h - 1.3 include/asm-i386/ptrace.h - 1.2 From owner-linux-xfs@oss.sgi.com Mon Feb 16 13:36:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 13:36:26 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GLaKKO021914 for ; Mon, 16 Feb 2004 13:36:20 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id B97841800A6; Tue, 17 Feb 2004 08:36:14 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 793E1C00A9; Tue, 17 Feb 2004 08:36:06 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 767D8140086; Tue, 17 Feb 2004 08:36:06 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - kdb for 2.6 In-reply-to: Your message of "Tue, 17 Feb 2004 08:20:28 +1100." <200402162120.i1GLKSrl10960472@snort.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Feb 2004 08:36:05 +1100 Message-ID: <9298.1076967365@ocs3.ocs.com.au> X-archive-position: 2111 X-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 Tue, 17 Feb 2004 08:20:28 +1100 (EST), Nathan Scott wrote: >Merge in kdb-common patch for 2.6 >Merge in kdb-i386 patch for 2.6 Nathan, please remove both patches. They are not the working versions of kdb for 2.6 and have bugs. From owner-linux-xfs@oss.sgi.com Mon Feb 16 13:44:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 13:44:29 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GLiLKO022394 for ; Mon, 16 Feb 2004 13:44:21 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1GKiGho016109 for ; Mon, 16 Feb 2004 12:44:17 -0800 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 IAA08996; Tue, 17 Feb 2004 08:42:23 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GLgM8n185049; Tue, 17 Feb 2004 08:42:22 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1GLfdx6001104; Tue, 17 Feb 2004 08:41:39 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1GLfdxc001102; Tue, 17 Feb 2004 08:41:39 +1100 Date: Tue, 17 Feb 2004 08:41:39 +1100 From: Nathan Scott To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - kdb for 2.6 Message-ID: <20040216214139.GA992@frodo> References: <200402162120.i1GLKSrl10960472@snort.melbourne.sgi.com> <9298.1076967365@ocs3.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9298.1076967365@ocs3.ocs.com.au> User-Agent: Mutt/1.5.3i X-archive-position: 2112 X-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 Tue, Feb 17, 2004 at 08:36:05AM +1100, Keith Owens wrote: > On Tue, 17 Feb 2004 08:20:28 +1100 (EST), > Nathan Scott wrote: > >Merge in kdb-common patch for 2.6 > >Merge in kdb-i386 patch for 2.6 > > Nathan, please remove both patches. They are not the working versions > of kdb for 2.6 and have bugs. > Umm, OK (wondering why you said these were OK to merge yesterday..). Can you point me to the real patches please? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 16 14:03:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 14:03:54 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GM3mKO022956 for ; Mon, 16 Feb 2004 14:03:49 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id BA9951800A6; Tue, 17 Feb 2004 09:03:46 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id BE1ACC00A9; Tue, 17 Feb 2004 09:03:38 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id B3388140086; Tue, 17 Feb 2004 09:03:38 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - kdb for 2.6 In-reply-to: Your message of "Tue, 17 Feb 2004 08:41:39 +1100." <20040216214139.GA992@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Feb 2004 09:03:37 +1100 Message-ID: <9757.1076969017@ocs3.ocs.com.au> X-archive-position: 2113 X-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 Tue, 17 Feb 2004 08:41:39 +1100, Nathan Scott wrote: >Umm, OK (wondering why you said these were OK to merge yesterday..). kdb was working against 2.6.3-rc2, but 2.6.3-rc3 broke it. >Can you point me to the real patches please? As soon as I sort out the 2.6.3-rc3 breakage. Later today with any luck. From owner-linux-xfs@oss.sgi.com Mon Feb 16 14:19:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 14:19:05 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GMJ2KO023522 for ; Mon, 16 Feb 2004 14:19:02 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1GMItB7000398 for ; Mon, 16 Feb 2004 16:18:56 -0600 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 JAA09736; Tue, 17 Feb 2004 09:18:54 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GMIq8n192716; Tue, 17 Feb 2004 09:18:53 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1GMIAx6001199; Tue, 17 Feb 2004 09:18:10 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1GMI90Q001197; Tue, 17 Feb 2004 09:18:09 +1100 Date: Tue, 17 Feb 2004 09:18:09 +1100 From: Nathan Scott To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - kdb for 2.6 Message-ID: <20040216221809.GB992@frodo> References: <20040216214139.GA992@frodo> <9757.1076969017@ocs3.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9757.1076969017@ocs3.ocs.com.au> User-Agent: Mutt/1.5.3i X-archive-position: 2114 X-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 Tue, Feb 17, 2004 at 09:03:37AM +1100, Keith Owens wrote: > On Tue, 17 Feb 2004 08:41:39 +1100, > Nathan Scott wrote: > >Umm, OK (wondering why you said these were OK to merge yesterday..). > > kdb was working against 2.6.3-rc2, but 2.6.3-rc3 broke it. For some reason I misunderstood and thought you'd said 2.6.3-rc3 was working yesterday too. Oh well, no matter. > >Can you point me to the real patches please? > > As soon as I sort out the 2.6.3-rc3 breakage. Later today with any > luck. Taa. How fatal is the problem? (he says, waiting for the kernel compile to finish). Any kind of even-half-working kdb is of great use to me. :) thanks Keith. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 16 14:34:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 14:34:16 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GMYEKO024133 for ; Mon, 16 Feb 2004 14:34:14 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1GMY737004654 for ; Mon, 16 Feb 2004 16:34:08 -0600 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 JAA10000; Tue, 17 Feb 2004 09:34:06 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GMY48n193528; Tue, 17 Feb 2004 09:34:05 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1GMXLx6001306; Tue, 17 Feb 2004 09:33:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1GMXL13001304; Tue, 17 Feb 2004 09:33:21 +1100 Date: Tue, 17 Feb 2004 09:33:21 +1100 From: Nathan Scott To: Keith Owens Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - kdb for 2.6 Message-ID: <20040216223321.GB1214@frodo> References: <20040216214139.GA992@frodo> <9757.1076969017@ocs3.ocs.com.au> <20040216221809.GB992@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040216221809.GB992@frodo> User-Agent: Mutt/1.5.3i X-archive-position: 2115 X-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 Tue, Feb 17, 2004 at 09:18:09AM +1100, Nathan Scott wrote: > On Tue, Feb 17, 2004 at 09:03:37AM +1100, Keith Owens wrote: > > > > As soon as I sort out the 2.6.3-rc3 breakage. Later today with any > > luck. > > Taa. How fatal is the problem? (he says, waiting for the kernel > compile to finish). I see, quite fatal - I'll back it out for now. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Feb 16 14:39:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 14:39:07 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GMd5KO024524 for ; Mon, 16 Feb 2004 14:39:05 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1GMcx37006468 for ; Mon, 16 Feb 2004 16:39:00 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1GMcwf926506733 for ; Mon, 16 Feb 2004 14:38:59 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GMcvhI10099805 for ; Tue, 17 Feb 2004 09:38:57 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1GMcuHr11082875 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 09:38:56 +1100 (EST) Date: Tue, 17 Feb 2004 09:38:56 +1100 (EST) From: Nathan Scott Message-Id: <200402162238.i1GMcuHr11082875@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: Undo kdb for 2.6.x-xfs mods X-archive-position: 2116 X-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: Mon Feb 16 14:35:58 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs Undoes mod: 2.6.x-xfs:linux:166819a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166820a arch/i386/Kconfig - 1.6 arch/i386/Makefile - 1.3 arch/i386/kernel/entry.S - 1.3 arch/i386/kernel/i8259.c - 1.4 arch/i386/kernel/io_apic.c - 1.5 arch/i386/kernel/nmi.c - 1.3 arch/i386/kernel/reboot.c - 1.4 arch/i386/kernel/smp.c - 1.3 arch/i386/kernel/smpboot.c - 1.4 arch/i386/kernel/traps.c - 1.3 arch/i386/kernel/vmlinux.lds.S - 1.3 include/asm-i386/kmap_types.h - 1.3 include/asm-i386/mach-default/irq_vectors.h - 1.4 include/asm-i386/ptrace.h - 1.3 kdb/modules/kdbm_x86.c - 1.2 include/asm-i386/kdbprivate.h - 1.2 arch/i386/kdb/ChangeLog - 1.2 arch/i386/kdb/Makefile - 1.2 arch/i386/kdb/ansidecl.h - 1.2 arch/i386/kdb/bfd.h - 1.2 arch/i386/kdb/i386-dis.c - 1.2 arch/i386/kdb/kdba_bp.c - 1.2 arch/i386/kdb/kdba_bt.c - 1.2 arch/i386/kdb/kdba_id.c - 1.2 arch/i386/kdb/kdba_io.c - 1.2 arch/i386/kdb/kdbasupport.c - 1.2 arch/i386/kdb/pc_keyb.h - 1.2 include/asm-i386/kdb.h - 1.2 Date: Mon Feb 16 14:37:45 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs Undoes mod: 2.6.x-xfs:linux:166818a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166821a Makefile - 1.10 drivers/char/keyboard.c - 1.7 drivers/char/sn_serial.c - 1.6 drivers/serial/8250.c - 1.5 include/linux/sysctl.h - 1.7 init/main.c - 1.7 kernel/exit.c - 1.6 kernel/kallsyms.c - 1.3 kernel/module.c - 1.6 kernel/printk.c - 1.6 kernel/sched.c - 1.7 kernel/signal.c - 1.3 kernel/sysctl.c - 1.6 mm/memory.c - 1.6 scripts/Makefile - 1.3 scripts/kallsyms.c - 1.3 Documentation/kdb/dump.txt - 1.2 Documentation/kdb/kdb.mm - 1.2 Documentation/kdb/kdb_bp.man - 1.2 Documentation/kdb/kdb_bt.man - 1.2 Documentation/kdb/kdb_env.man - 1.2 Documentation/kdb/kdb_ll.man - 1.2 Documentation/kdb/kdb_md.man - 1.2 Documentation/kdb/kdb_rd.man - 1.2 Documentation/kdb/kdb_sr.man - 1.2 Documentation/kdb/kdb_ss.man - 1.2 Documentation/kdb/slides - 1.2 kdb/Makefile - 1.2 kdb/kdbmain.c - 1.2 kdb/modules/kdbm_vm.c - 1.2 kdb/modules/kdbm_task.c - 1.2 include/linux/dis-asm.h - 1.2 include/linux/kdb.h - 1.2 include/linux/kdbprivate.h - 1.2 kdb/modules/kdbm_pg.c - 1.2 kdb/modules/Makefile - 1.2 kdb/ChangeLog - 1.2 kdb/kdbsupport.c - 1.2 kdb/kdb_bp.c - 1.2 kdb/kdb_bt.c - 1.2 kdb/kdb_id.c - 1.2 kdb/kdb_io.c - 1.2 kdb/kdb_cmds - 1.2 From owner-linux-xfs@oss.sgi.com Mon Feb 16 14:53:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 14:53:08 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GMr6KO025383 for ; Mon, 16 Feb 2004 14:53:06 -0800 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1GMr037010421 for ; Mon, 16 Feb 2004 16:53:01 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by nodin.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1GMqxf925456639 for ; Mon, 16 Feb 2004 14:53:00 -0800 (PST) Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1GMqthI11091283; Tue, 17 Feb 2004 09:52:55 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1GMqsRw11089616; Tue, 17 Feb 2004 09:52:54 +1100 (EST) Date: Tue, 17 Feb 2004 09:52:54 +1100 (EST) From: Nathan Scott Message-Id: <200402162252.i1GMqsRw11089616@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 907600 - xfsdump configure X-archive-position: 2117 X-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 Ensure packaging and configuring is done correctly, after libhandle fixups/extension yesterday. Date: Mon Feb 16 14:52:14 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166822a xfsprogs/VERSION - 1.98 xfsprogs/doc/CHANGES - 1.135 xfsprogs/debian/changelog - 1.88 xfsprogs/libhandle/Makefile - 1.12 xfsdump/configure.in - 1.36 xfsdump/debian/control - 1.19 xfsdump/debian/changelog - 1.45 xfsdump/debian/shlibs.local - 1.5 xfsdump/m4/package_xfslibs.m4 - 1.4 xfsdump/aclocal.m4 - 1.7 From owner-linux-xfs@oss.sgi.com Mon Feb 16 15:59:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 16:00:01 -0800 (PST) Received: from mailer1.psc.edu (mailer1.psc.edu [128.182.58.100]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1GNxkKO027348 for ; Mon, 16 Feb 2004 15:59:46 -0800 Received: from psc.edu (panzer.psc.edu [128.182.61.113]) by mailer1.psc.edu (8.12.10/8.12.5) with ESMTP id i1GNxjt0004555 for ; Mon, 16 Feb 2004 18:59:45 -0500 (EST) Message-ID: <40315970.4060801@psc.edu> Date: Mon, 16 Feb 2004 18:59:44 -0500 From: PAulN User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: inode allocation and volume groups Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: pauln@psc.edu Precedence: bulk X-list: linux-xfs Hi, I know this the linux list but I have an irix question.. I was wondering if someone could please explain the policy for inode allocation in an XVM environment. To maximize performance, I'd like to create a scheme where multiple file creates in the same directory are distributed across volume groups. If necessary, I can resort to creating the inodes in separate directories and hardlinking them into the "proper" namespace but it would be helpful to know what XFS is doing under the hood. I've tried various tests to charaterize the behavior but still have yet to fully understand how it works. Could someone enlighten me? Thanks, Paul From owner-linux-xfs@oss.sgi.com Mon Feb 16 17:26:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 17:26:15 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1H1QCKO032227 for ; Mon, 16 Feb 2004 17:26:12 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1H0Eeho002395 for ; Mon, 16 Feb 2004 16:14:40 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1H1CljS34114996; Mon, 16 Feb 2004 19:12:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1H1Cloa729612; Mon, 16 Feb 2004 19:12:47 -0600 (CST) Date: Mon, 16 Feb 2004 19:12:47 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: mschmitt@inf.ethz.ch cc: linux-xfs@oss.sgi.com Subject: Re: XFS: Filesystem sd(8,50) has duplicate UUID - can't mount In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2119 X-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 suppose the most likely scenario is that the mount failed after inserting the uuid into the list, and did not clean up properly (thanks for the hint Glen) - in which case mounting nouuid is fine, and yes it should resolve on the next reboot. sounds like a relatively harless (but annoying) bug. -Eric On Mon, 16 Feb 2004, Eric Sandeen wrote: > Was the filesystem ever cloned or snapshotted? > > do you have other xfs filesystems mounted? we could > use xfs_db to look at superblocks on each, and see why > it thinks it's a duplicate uuid... hm, or perhaps it > thinks the filesystem is mounted twice somehow...? > > -Eric > From owner-linux-xfs@oss.sgi.com Mon Feb 16 19:33:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 19:33:20 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1H3XHKO001556 for ; Mon, 16 Feb 2004 19:33:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1H3XB37027286 for ; Mon, 16 Feb 2004 21:33:11 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1H3X9hI10988329 for ; Tue, 17 Feb 2004 14:33:09 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1H3X86K11067014 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 14:33:08 +1100 (EST) Date: Tue, 17 Feb 2004 14:33:08 +1100 (EST) From: Nathan Scott Message-Id: <200402170333.i1H3X86K11067014@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - kdb for 2.6 (really this time) X-archive-position: 2120 X-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 Merge in the real kdb-v4.3-2.6.3-rc3-common-1 patch. Date: Mon Feb 16 19:29:30 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166825a Makefile - 1.11 drivers/char/keyboard.c - 1.8 drivers/char/sn_serial.c - 1.7 drivers/serial/8250.c - 1.6 include/linux/console.h - 1.4 include/linux/sysctl.h - 1.8 init/main.c - 1.8 kernel/exit.c - 1.7 kernel/kallsyms.c - 1.4 kernel/module.c - 1.7 kernel/printk.c - 1.7 kernel/sched.c - 1.8 kernel/signal.c - 1.4 kernel/sysctl.c - 1.7 mm/memory.c - 1.7 scripts/Makefile - 1.4 scripts/kallsyms.c - 1.4 Documentation/kdb/dump.txt - 1.3 Documentation/kdb/kdb.mm - 1.3 Documentation/kdb/kdb_bp.man - 1.3 Documentation/kdb/kdb_bt.man - 1.3 Documentation/kdb/kdb_env.man - 1.3 Documentation/kdb/kdb_ll.man - 1.3 Documentation/kdb/kdb_md.man - 1.3 Documentation/kdb/kdb_rd.man - 1.3 Documentation/kdb/kdb_sr.man - 1.3 Documentation/kdb/kdb_ss.man - 1.3 Documentation/kdb/slides - 1.3 kdb/Makefile - 1.3 kdb/kdbmain.c - 1.3 kdb/modules/kdbm_vm.c - 1.3 kdb/modules/kdbm_task.c - 1.3 include/linux/dis-asm.h - 1.3 include/linux/kdb.h - 1.3 include/linux/kdbprivate.h - 1.3 kdb/modules/kdbm_pg.c - 1.3 kdb/modules/Makefile - 1.3 kdb/ChangeLog - 1.3 kdb/kdbsupport.c - 1.3 kdb/kdb_bp.c - 1.3 kdb/kdb_bt.c - 1.3 kdb/kdb_id.c - 1.3 kdb/kdb_io.c - 1.3 kdb/kdb_cmds - 1.3 Merge in the real /tmp/kdb-v4.3-2.6.3-rc3-i386-1 patch. Date: Mon Feb 16 19:32:29 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166826a arch/i386/Kconfig - 1.7 arch/i386/Makefile - 1.4 arch/i386/kernel/entry.S - 1.4 arch/i386/kernel/i8259.c - 1.5 arch/i386/kernel/io_apic.c - 1.6 arch/i386/kernel/nmi.c - 1.4 arch/i386/kernel/reboot.c - 1.5 arch/i386/kernel/smp.c - 1.4 arch/i386/kernel/smpboot.c - 1.5 arch/i386/kernel/traps.c - 1.4 arch/i386/kernel/vmlinux.lds.S - 1.4 include/asm-i386/kmap_types.h - 1.4 include/asm-i386/mach-default/irq_vectors.h - 1.5 include/asm-i386/ptrace.h - 1.4 kdb/modules/kdbm_x86.c - 1.3 include/asm-i386/kdbprivate.h - 1.3 arch/i386/kdb/ChangeLog - 1.3 arch/i386/kdb/Makefile - 1.3 arch/i386/kdb/ansidecl.h - 1.3 arch/i386/kdb/bfd.h - 1.3 arch/i386/kdb/i386-dis.c - 1.3 arch/i386/kdb/kdba_bp.c - 1.3 arch/i386/kdb/kdba_bt.c - 1.3 arch/i386/kdb/kdba_id.c - 1.3 arch/i386/kdb/kdba_io.c - 1.3 arch/i386/kdb/kdbasupport.c - 1.3 arch/i386/kdb/pc_keyb.h - 1.3 include/asm-i386/kdb.h - 1.3 From owner-linux-xfs@oss.sgi.com Mon Feb 16 21:56:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 21:56:48 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1H5ukKO006476 for ; Mon, 16 Feb 2004 21:56:47 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1H5uc37001755 for ; Mon, 16 Feb 2004 23:56:40 -0600 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1H5uahR001923 for ; Tue, 17 Feb 2004 16:56:37 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1H5uaIq001922 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 16:56:36 +1100 Date: Tue, 17 Feb 2004 16:56:36 +1100 From: FSG QA Message-Id: <200402170556.i1H5uaIq001922@bruce.melbourne.sgi.com> Subject: TAKE - xfstests X-archive-position: 2121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Ensure dump/restore QA output is in a canonical whitespace form. In particular, sizes of directory inodes can change, validly, between dumped/restored filesystems which was messing up diffs. -- nathans Date: Mon Feb 16 21:55:08 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: tes@sgi.com,nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:166827a xfstests/common.dump - 1.47 From owner-linux-xfs@oss.sgi.com Mon Feb 16 22:10:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Feb 2004 22:10:23 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1H6AKKO007030 for ; Mon, 16 Feb 2004 22:10:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1H6AE37007226 for ; Tue, 17 Feb 2004 00:10:15 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1H6AChI11254104 for ; Tue, 17 Feb 2004 17:10:12 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1H6ACsP11197452 for linux-xfs@oss.sgi.com; Tue, 17 Feb 2004 17:10:12 +1100 (EST) Date: Tue, 17 Feb 2004 17:10:12 +1100 (EST) From: Nathan Scott Message-Id: <200402170610.i1H6ACsP11197452@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 908003 - fix some debug code X-archive-position: 2122 X-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 BUG() in new trace code, it was plain wrong for the unmapped page case (but only trips up on 2.6 due to extra checks there). Date: Mon Feb 16 22:08:30 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166828a linux-2.6/xfs_aops.c - 1.64 linux-2.4/xfs_aops.c - 1.72 From owner-linux-xfs@oss.sgi.com Tue Feb 17 04:06:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 04:06:36 -0800 (PST) Received: from relay01.roc.ny.frontiernet.net (relay01.roc.ny.frontiernet.net [66.133.131.34]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1HC67KO010236 for ; Tue, 17 Feb 2004 04:06:08 -0800 Received: (qmail 23270 invoked from network); 17 Feb 2004 12:06:06 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay01.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 17 Feb 2004 12:06:06 -0000 Message-ID: <4032035D.2010608@xfs.org> Date: Tue, 17 Feb 2004 06:04:45 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: PAulN CC: linux-xfs@oss.sgi.com Subject: Re: inode allocation and volume groups References: <40315970.4060801@psc.edu> In-Reply-To: <40315970.4060801@psc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2123 X-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@xfs.org Precedence: bulk X-list: linux-xfs PAulN wrote: > Hi, > I know this the linux list but I have an irix question.. > I was wondering if someone could please explain the policy for inode > allocation > in an XVM environment. To maximize performance, I'd like to create a > scheme where > multiple file creates in the same directory are distributed across > volume groups. If necessary, > I can resort to creating the inodes in separate directories and > hardlinking them into the "proper" > namespace but it would be helpful to know what XFS is doing under the hood. > > I've tried various tests to charaterize the behavior but still have yet > to fully understand > how it works. Could someone enlighten me? > > Thanks, > Paul > Normal behavior is that an inode is placed in the same allocation group as the parent directory. New directories round robin to the next allocation group. Exceptions to this are: o when there is locking contention on the allocation group, or it does not have reasonable space available. In this case the allocator will move on to the next available allocation group. o for filesystems of more than 1 Tbyte inodes can be kept in allocation groups within the first 1 Tbyte to keep inode numbers down within 32 bits. This can be turned off with the inode64 option (except on 32 bit linux where inode numbers larger than 32 bits are a bad thing). Steve From owner-linux-xfs@oss.sgi.com Tue Feb 17 07:11:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 07:11:36 -0800 (PST) Received: from alienAngel.upjs.sk (gprs185-222.eurotel.cz [160.218.185.222]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1HFB5KO017191 for ; Tue, 17 Feb 2004 07:11:08 -0800 Received: by alienAngel.upjs.sk (Postfix, from userid 500) id 96F241C2; Tue, 17 Feb 2004 14:28:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by alienAngel.upjs.sk (Postfix) with ESMTP id 92DE01A6 for ; Tue, 17 Feb 2004 14:28:54 +0100 (CET) Date: Tue, 17 Feb 2004 14:28:54 +0100 (CET) From: Jan Derfinak X-X-Sender: ja@alienAngel.home.sk To: linux-xfs@oss.sgi.com Subject: Zeroed files on / partition after clean unmount Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Hi. Recently I found weird behaviour of xfs on my root filesystem. Kernel version is 2.6.0-test11-xfs, 2.6.2-rc3, 2.6.3-rc4. The last one wrote this message on boot: SGI-XFS CVS-2004-02-17_06:00_UTC with ACLs, realtime, no debug enabled SGI XFS Quota Management subsystem Steps to reproduce: 1. I booted the computer. 2. Immediately after boot I logged to text console. I used vi to edit /boot/grub/menu.lst. 3. I ended vi and reboot machine with 'reboot' command. During reboot process I saw "/dev/hda1 unmouted" (hda1 is my root partition). During next boot I saw: XFS mounting filesystem hda1 Ending clean XFS mount for filesystem: hda1 VFS: Mounted root (xfs filesystem) readonly. But file menu.lst is filled with zeros. After this I did next test. 1. I booted the computer. 2. I copied file /boot/grup/menu.lst~ to /boot/grup/menu.lst, /root/menu.lst, /home/menu.lst. 3. Rebooted with 'reboot' command. /boot/grup/menu.lst and /root/menu.lst were filled with zeros. /home/menu.lst was OK. /home is different partition. Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 2094240 1326768 767472 64% / /dev/mapper/system-test 519488 269464 250024 52% /home If the computer is running for longer time, I can edit menu.lst and reboot and everything is OK. But if I just boot, edit a file on root partition and reboot, the file is every time zeroed. I think this isn't expected behaviour. Should I do more testing? Which one? jan -- From owner-linux-xfs@oss.sgi.com Tue Feb 17 10:34:14 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 10:34:30 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1HIYEKO025769 for ; Tue, 17 Feb 2004 10:34:14 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1HIY8Wd028605 for ; Tue, 17 Feb 2004 12:34:08 -0600 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1HIY8cT34318596; Tue, 17 Feb 2004 12:34:08 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1HIXu4X2965995; Tue, 17 Feb 2004 12:33:56 -0600 (CST) Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site From: Russell Cattelan To: Patrick Vier Cc: Mike Burger , linux-xfs@oss.sgi.com In-Reply-To: <000b01c3f22a$f77d7b50$0c01a8c0@Patrick> References: <000b01c3f22a$f77d7b50$0c01a8c0@Patrick> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DQEYykDM3r867hxIggaB" Message-Id: <1077042836.2966.3.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-3mdk Date: Tue, 17 Feb 2004 12:33:56 -0600 X-archive-position: 2125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs --=-DQEYykDM3r867hxIggaB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Grub works fine once you get it installed. We think the problem is a bogus test in grub that tries to check the consistency of the install. It does so=20 my accessing the block device directly but it does its set up via the filesystem, so things sometimes are not=20 consistent yet. The work around to the problem is enter the shell=20 from the installer kill grub and run by hand. e.g. % grub grub> root (hd0,0) grub> setup (hd0) On Fri, 2004-02-13 at 06:14, Patrick Vier wrote: > Yes, grub seems not the good boot loader... > Actually, i've restarted all the installs. > 1- install RH8 with grub, just to check if HW no problem... OK, rh boot > normaly. > 2- Upgrade RH8 to RH9 (standard) with grub as boot loader... OK rh reboot > normaly. > 3- Actually, i try to upgrade RH9 to RH9-XFS with the cd rh9+xfs... and w= ith > this cd is not possible to upgrade the system... only install from > scratch... > ... So i will install it with lilo as boot loader... Hope that Linux God = be > with me... >=20 > Patrick :) >=20 > ----- Original Message ----- > From: "Mike Burger" > To: "Patrick Vier" > Cc: > Sent: Friday, February 13, 2004 12:29 PM > Subject: Re: Install rh9+xfs from the iso cd downloaded from sgi site >=20 >=20 > > On Fri, 13 Feb 2004, Patrick Vier wrote: > > > > > Hi all, > > > > > > I've a problem to install Linux-xfs with the iso downloaded from the = sgi > > > site. > > > > > > 1- installing from linux-xfs (rh9)... install is hang when install pa= ck > for > > > grub boot loader... > > > Nota : the test of the distrib is ok. > > > > > > Please help. > > > Some of you have meet this problem ??? > > > > There's been problems noted, in the past, regarding GRUB. I just stick > > with LILO on my RH+XFS systems. > > -- > > Mike Burger > > http://www.bubbanfriends.org > > > > Visit the Dog Pound II BBS > > telnet://dogpound2.citadel.org or http://dogpound2.citadel.org:2000 > > > > To be notified of updates to the web site, visit > > http://www.bubbanfriends.org/mailman/listinfo/site-update, or send a > > message to: > > > > site-update-request@bubbanfriends.org > > > > with a message of: > > > > subscribe > > > > > > >=20 --=-DQEYykDM3r867hxIggaB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAMl6TNRmM+OaGhBgRAkTKAJ4yxBjGyDiv/HZixfgpqaQ8wWdm4QCeN5Fh 0SFks4zV1If4VKVe0HyS5Ng= =RYV2 -----END PGP SIGNATURE----- --=-DQEYykDM3r867hxIggaB-- From owner-linux-xfs@oss.sgi.com Tue Feb 17 18:47:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 18:47:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1I2lHKO014855 for ; Tue, 17 Feb 2004 18:47:18 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1I1n66W014209 for ; Tue, 17 Feb 2004 17:49:07 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1I2l5hI11294649; Wed, 18 Feb 2004 13:47:05 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1I2l47N11360565; Wed, 18 Feb 2004 13:47:04 +1100 (EST) Date: Wed, 18 Feb 2004 13:47:04 +1100 (EST) From: Nathan Scott Message-Id: <200402180247.i1I2l47N11360565@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 769637 - restore mount stripe-unit/width-alignment check X-archive-position: 2126 X-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 Merge missing mount stripe-unit/width-alignment check over from IRIX. Date: Tue Feb 17 18:45:10 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux Inspected by: overby Author: jpk Merged by: nathans Merged mods: grove2:irix:166614a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:166614a xfs_mount.c - 1.340 - Merge of grove2:irix:166614a by nathans. If the stripe unit or stripe width are not multiples of the filesystem block size, turn off striping. (This line of code was inadvertently deleted with rev 1.206.) From owner-linux-xfs@oss.sgi.com Tue Feb 17 20:44:10 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 20:44:12 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1I4iAKO020122 for ; Tue, 17 Feb 2004 20:44:10 -0800 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1I4i4ba354600 for ; Tue, 17 Feb 2004 23:44:04 -0500 Received: from sig-9-65-13-224.mts.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1I4i36d123526 for ; Tue, 17 Feb 2004 21:44:04 -0700 Subject: DMAPI test suite. From: Ram Pai To: linux-xfs@oss.sgi.com Content-Type: text/plain Organization: Message-Id: <1077079431.30824.66.camel@dyn319009bld.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 17 Feb 2004 20:43:52 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linuxram@us.ibm.com Precedence: bulk X-list: linux-xfs Is there tar file or some rpm of the DMAPI test suite. I tried compiling it from the CVS and ended up with ../../../depcomp: ../../../depcomp: No such file or directory Thanks, RP From owner-linux-xfs@oss.sgi.com Tue Feb 17 21:06:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 21:06:55 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1I56oKO020992 for ; Tue, 17 Feb 2004 21:06:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1I56ivC017264 for ; Tue, 17 Feb 2004 21:06:44 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1I56hhI11483574 for ; Wed, 18 Feb 2004 16:06:43 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1I56gFq11403409 for linux-xfs@oss.sgi.com; Wed, 18 Feb 2004 16:06:42 +1100 (EST) Date: Wed, 18 Feb 2004 16:06:42 +1100 (EST) From: Nathan Scott Message-Id: <200402180506.i1I56gFq11403409@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.3 X-archive-position: 2129 X-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 Feb 17 21:03:37 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166923a Makefile - 1.15 arch/sparc64/kernel/sys_sparc32.c - 1.3 arch/sparc64/kernel/traps.c - 1.3 arch/x86_64/kernel/pci-gart.c - 1.5 drivers/char/agp/Kconfig - 1.2 drivers/char/drm/radeon_state.c - 1.3 drivers/ide/ide-iops.c - 1.5 drivers/ide/ide.c - 1.8 drivers/ide/setup-pci.c - 1.4 drivers/media/video/tuner.c - 1.4 drivers/video/Kconfig - 1.6 drivers/video/fbmem.c - 1.6 fs/block_dev.c - 1.3 fs/cifs/file.c - 1.2 include/asm-sparc64/dma-mapping.h - 1.2 include/linux/ide.h - 1.9 mm/mremap.c - 1.5 net/ipv4/netfilter/ip_tables.c - 1.4 net/ipv6/netfilter/ip6_tables.c - 1.3 scripts/kconfig/symbol.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Feb 17 21:06:13 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 21:06:26 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1I56DKO020915 for ; Tue, 17 Feb 2004 21:06:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1I51dvC016387 for ; Tue, 17 Feb 2004 21:01:40 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1I51chI11451117 for ; Wed, 18 Feb 2004 16:01:38 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1I51cso11494284 for linux-xfs@oss.sgi.com; Wed, 18 Feb 2004 16:01:38 +1100 (EST) Date: Wed, 18 Feb 2004 16:01:38 +1100 (EST) From: Nathan Scott Message-Id: <200402180501.i1I51cso11494284@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.4.25-rc4 X-archive-position: 2128 X-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 Feb 17 21:00:17 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:166922a Makefile - 1.10 arch/sparc64/kernel/sys_sparc32.c - 1.2 mm/mremap.c - 1.3 net/ipv4/netfilter/ip_tables.c - 1.3 net/ipv6/netfilter/ip6_tables.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Feb 17 21:56:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Feb 2004 21:56:57 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1I5ugKO022252 for ; Tue, 17 Feb 2004 21:56:45 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1I5uZ8O026582 for ; Tue, 17 Feb 2004 23:56:36 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1I5uXhI11489838 for ; Wed, 18 Feb 2004 16:56:33 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1I5uXwk11461487 for linux-xfs@oss.sgi.com; Wed, 18 Feb 2004 16:56:33 +1100 (EST) Date: Wed, 18 Feb 2004 16:56:33 +1100 (EST) From: Nathan Scott Message-Id: <200402180556.i1I5uXwk11461487@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - kdb update X-archive-position: 2130 X-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 Merge in kdb changelog updates. Date: Tue Feb 17 21:56:11 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:166924a kdb/ChangeLog - 1.6 arch/i386/kdb/ChangeLog - 1.4 From owner-linux-xfs@oss.sgi.com Wed Feb 18 02:30:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 02:30:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1IAUZKO029893 for ; Wed, 18 Feb 2004 02:30:35 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1IAUZRw029892 for linux-xfs@oss.sgi.com; Wed, 18 Feb 2004 02:30:35 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1IAUXKQ029878 for ; Wed, 18 Feb 2004 02:30:33 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1I9mXrY029474; Wed, 18 Feb 2004 01:48:33 -0800 Date: Wed, 18 Feb 2004 01:48:33 -0800 Message-Id: <200402180948.i1I9mXrY029474@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 310] New: Zeroed files on / partition after clean unmount X-Bugzilla-Reason: AssignedTo X-archive-position: 2131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=310 Summary: Zeroed files on / partition after clean unmount Product: Linux XFS Version: Current Platform: All OS/Version: Linux Status: NEW Severity: critical Priority: High Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: ja@mail.upjs.sk Kernel versions are 2.6.0-test11-xfs, 2.6.2-rc3, 2.6.3-rc4. The last one wrote this message on boot: SGI-XFS CVS-2004-02-17_06:00_UTC with ACLs, realtime, no debug enabled SGI XFS Quota Management subsystem Steps to reproduce: 1. I booted the computer. 2. Immediately after boot I logged to text console. I used vi to edit /boot/grub/menu.lst. 3. I ended vi and reboot machine with 'reboot' command. During reboot process I saw "/dev/hda1 unmouted" (hda1 is my root partition). During next boot I saw: XFS mounting filesystem hda1 Ending clean XFS mount for filesystem: hda1 VFS: Mounted root (xfs filesystem) readonly. But file menu.lst is filled with zeros. After this I did next test. 1. I booted the computer. 2. I copied file /boot/grup/menu.lst~ to /boot/grup/menu.lst, /root/menu.lst, /home/menu.lst. 3. Rebooted with 'reboot' command. /boot/grup/menu.lst and /root/menu.lst were filled with zeros. /home/menu.lst was OK. /home is different partition. Filesystem 1K-blocks Used Available Use% Mounted on /dev/hda1 2094240 1326768 767472 64% / /dev/mapper/system-test 519488 269464 250024 52% /home If the computer is running for longer time, I can edit menu.lst and reboot and everything is OK. But if I just boot, edit a file on root partition and reboot, the file is every time zeroed. I tried to edit a file, reboot and boot from rescue CD. Then I mounted /dev/hda1 with '-o ro,norecovery' to be sure that there are no transactions replaying. The file was filled with zeros so I think that the file is zeroed during umount or flush. I tested SUSE kernel 2.4.21-99-athlon too: SGI XFS 1.3.0 with ACLs, no debug enabled SGI XFS Quota Management subsystem With this kernel is everything OK. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 18 09:55:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 09:56:18 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IHtxKO017514 for ; Wed, 18 Feb 2004 09:55:59 -0800 Received: from penguin5.americas.sgi.com ([128.162.240.141]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1IHmcgF027263 for ; Wed, 18 Feb 2004 11:48:39 -0600 Received: from penguin5.americas.sgi.com (penguin5.americas.sgi.com [127.0.0.1]) by penguin5.americas.sgi.com (8.12.10/8.12.10) with ESMTP id i1IHmYWM023387; Wed, 18 Feb 2004 11:48:35 -0600 Received: (from sandeen@localhost) by penguin5.americas.sgi.com (8.12.10/8.12.10/Submit) id i1IHmYGf023385; Wed, 18 Feb 2004 11:48:34 -0600 Date: Wed, 18 Feb 2004 11:48:34 -0600 From: Eric Sandeen Message-Id: <200402181748.i1IHmYGf023385@penguin5.americas.sgi.com> Subject: TAKE 904196 - Merge up to 2.4.25 final X-archive-position: 2132 X-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@penguin5.americas.sgi.com Precedence: bulk X-list: linux-xfs Just a makefile change :) Date: Wed Feb 18 09:47:50 PST 2004 Workarea: penguin5.americas.sgi.com:/src/eric/linux-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:166945a Makefile - 1.11 - Merge up to 2.4.25 final From owner-linux-xfs@oss.sgi.com Wed Feb 18 09:57:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 09:57:48 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IHveKO017587 for ; Wed, 18 Feb 2004 09:57:41 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id i1IHvZil031450 for ; Wed, 18 Feb 2004 12:57:35 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id i1IHvZrw031446 for ; Wed, 18 Feb 2004 12:57:35 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 18 Feb 2004 12:57:35 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Linux xfs mailing list Subject: Performance question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs I have a server with a single 3ware 7500-8 board and 8 Maxtor 160GB disks running as a hardware RAID5 w/ a hot spare. I'm running RedHat 7.3 and the 2.4.18-18SGI_XFS_1.2.0smp kernel (more on the kernel later). The partitions look like this: Filesystem 1k-blocks Used Available Use% Mounted on /dev/sda1 505605 133975 345526 28% / /dev/sda2 4127108 3810308 107152 98% /home none 1031920 0 1031920 0% /dev/shm /dev/sda7 1027768 20140 955420 3% /tmp /dev/sda3 2063536 1797416 161296 92% /usr /dev/sda5 3099260 2799304 142524 96% /usr/local /dev/sda6 1027768 117548 858012 13% /var /dev/sda8 948330428 627683892 320646536 67% /data Only /data is XFS, the rest are ext3. Backups on /data on this machine have been slowing to a crawl. I use amanda, and even the estimate phase (which does 'tar cf /dev/null' and so should be very fast) takes hours. I tried upgrading to 2.4.21 plus the 1.3 XFS patches (I'm running this on 2 other 3ware based servers), and this made the situation much worse. During backups, the OOM killer started going crazy, killing bash sessions and eventually the estimate tar process. I've pretty much ruled out hardware. I've swapped the 3ware and rebuilt the array, and the disks all show good SMART data. In narrowing down the problem, it seems that one particular (large) directory is the main culprit. This dir is 471,401,788 KB big and has 3,377,520 files (~140KB/file average). Is the large number of files the entire culprit? If so, is there anything I can do to alleviate the problem? I already 'mount -o logbufs=8'. Here's xfs_info on that partition: meta-data=/data isize=256 agcount=227, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=237115375, imaxpct=25 = sunit=16 swidth=96 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Any pointers would be much appreciated. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Feb 18 10:30:36 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 10:30:41 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1IIUaKO019310 for ; Wed, 18 Feb 2004 10:30:36 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1IIUaxe019309 for linux-xfs@oss.sgi.com; Wed, 18 Feb 2004 10:30:36 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1IIUYKQ019295 for ; Wed, 18 Feb 2004 10:30:34 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1IHfdri017413; Wed, 18 Feb 2004 09:41:39 -0800 Date: Wed, 18 Feb 2004 09:41:39 -0800 Message-Id: <200402181741.i1IHfdri017413@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 310] Zeroed files on / partition after clean unmount X-Bugzilla-Reason: AssignedTo X-archive-position: 2134 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=310 ------- Additional Comments From sandeen@sgi.com 2004-18-02 09:41 PDT ------- Since this only happens on the root filesystem, this is probably a bug in the remount,readonly code - root never really unmounts, but is remounted ro before the system shuts down. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Wed Feb 18 10:41:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 10:41:56 -0800 (PST) Received: from smtp-out5.xs4all.nl (smtp-out5.xs4all.nl [194.109.24.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IIfoKO019969 for ; Wed, 18 Feb 2004 10:41:51 -0800 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtp-out5.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1IIfkn2068194; Wed, 18 Feb 2004 19:41:46 +0100 (CET) Message-Id: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Feb 2004 19:41:45 +0100 To: Joshua Baker-LePain , Linux xfs mailing list From: Seth Mos Subject: Re: Performance question In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2135 X-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:57 18-2-2004 -0500, Joshua Baker-LePain wrote: >I've pretty much ruled out hardware. I've swapped the 3ware and rebuilt >the array, and the disks all show good SMART data. Have you considered raid 10 configuration? It will about halve the storage space but increase IO by a multiple. You could flip the cover and see if the disks are pushed hard by the controller (leds on the 3ware controller). Although from what you described above it's probably a directory growing a bit on the large side. >In narrowing down the problem, it seems that one particular (large) >directory is the main culprit. This dir is 471,401,788 KB big and has >3,377,520 files (~140KB/file average). Is the large number of files the >entire culprit? If so, is there anything I can do to alleviate the >problem? I already 'mount -o logbufs=8'. Here's xfs_info on that >partition: > >meta-data=/data isize=256 agcount=227, agsize=1048576 blks > = sectsz=512 Perhaps creating the filessystem with a larger inode size like 512. You could also use version logs instead of version which mostly helped software raid 5 although this might help hardware as well. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Feb 18 10:47:23 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 10:47:27 -0800 (PST) Received: from rrzd1.rz.uni-regensburg.de (rrzd1.rz.uni-regensburg.de [132.199.1.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IIlLKO020533 for ; Wed, 18 Feb 2004 10:47:22 -0800 Received: from rrzd1 (rrzd1 [127.0.0.1]) by rrzd1.rz.uni-regensburg.de (8.12.3/8.12.3/Debian -4) with ESMTP id i1IIlFxs012170; Wed, 18 Feb 2004 19:47:15 +0100 Received: from rx3227.cip.uni-regensburg.de ([132.199.237.32]) by rrzd1 (MailMonitor for SMTP v1.2.2 ) ; Wed, 18 Feb 2004 19:47:15 +0100 (CET) Received: from bonnie79 ([127.0.0.1] helo=localhost) by bonnie79 with esmtp (Exim 3.36 #1 (Debian)) id 1AtWj5-0003lw-00; Wed, 18 Feb 2004 19:47:15 +0100 Subject: Re: Performance question From: Christian Guggenberger Reply-To: christian.guggenberger@physik.uni-regensburg.de To: Seth Mos Cc: Joshua Baker-LePain , Linux xfs mailing list In-Reply-To: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> References: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> Content-Type: text/plain Message-Id: <1077130035.797.3.camel@bonnie79> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 18 Feb 2004 19:47:15 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2136 X-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 Wed, 2004-02-18 at 19:41, Seth Mos wrote: > At 12:57 18-2-2004 -0500, Joshua Baker-LePain wrote: > >I've pretty much ruled out hardware. I've swapped the 3ware and rebuilt > >the array, and the disks all show good SMART data. > > Have you considered raid 10 configuration? It will about halve the storage > space but increase IO by a multiple. > > You could flip the cover and see if the disks are pushed hard by the > controller (leds on the 3ware controller). Although from what you described > above it's probably a directory growing a bit on the large side. > > >In narrowing down the problem, it seems that one particular (large) > >directory is the main culprit. This dir is 471,401,788 KB big and has > >3,377,520 files (~140KB/file average). Is the large number of files the > >entire culprit? If so, is there anything I can do to alleviate the > >problem? I already 'mount -o logbufs=8'. Here's xfs_info on that > >partition: > > > >meta-data=/data isize=256 agcount=227, agsize=1048576 blks > > = sectsz=512 > > Perhaps creating the filessystem with a larger inode size like 512. You > could also use version logs instead of version which mostly helped software should read 'version 2 logs instead of version 1 logs', shouldn't it?:-) - Christian From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:03:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:03:42 -0800 (PST) Received: from smtp-out5.xs4all.nl (smtp-out5.xs4all.nl [194.109.24.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJ3NKO021963 for ; Wed, 18 Feb 2004 11:03:23 -0800 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtp-out5.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1IJ3Jn2083297; Wed, 18 Feb 2004 20:03:19 +0100 (CET) Message-Id: <4.3.2.7.2.20040218200249.03565ae8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Feb 2004 20:03:18 +0100 To: Joshua Baker-LePain , Linux xfs mailing list From: Seth Mos Subject: Re: Performance question In-Reply-To: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2137 X-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 19:41 18-2-2004 +0100, Seth Mos wrote: >At 12:57 18-2-2004 -0500, Joshua Baker-LePain wrote: >Perhaps creating the filessystem with a larger inode size like 512. You >could also use version logs instead of version which mostly helped >software raid 5 although this might help hardware as well. Version 2 logs that is. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:11:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:11:38 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJBLKO022473 for ; Wed, 18 Feb 2004 11:11:22 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 644917000BDA for ; Wed, 18 Feb 2004 11:12:26 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdnd7JJR; Wed Feb 18 11:12:24 2004 Received: from bubbles.imr-net.com (unknown [12.111.175.170]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 2FAD57000BDA for ; Wed, 18 Feb 2004 11:12:24 -0800 (PST) Subject: xfs_repair -n -f - Dangerous? From: Joshua Schmidlkofer To: linux-xfs@oss.sgi.com Content-Type: text/plain Message-Id: <1077131478.4214.11.camel@bubbles.imr-net.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 18 Feb 2004 11:11:18 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2138 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs I see that running xfs_db is dangerous. I have a system that I ran xfs_repair (-n -f) on a live filesystem, and it was a Bad Thing(tm). Is that the case? not a lot was going on, but I got some really nice call traces, =(. Then 990's on directory access, messages about corrupted inodes. I initiated a reboot, but not before saving the logs. I am trying to get data off it on to the stand-by, but Am I Borked? js From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:17:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:17:18 -0800 (PST) Received: from mail.pacrimopen.com ([64.65.177.98]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJH8KO022919 for ; Wed, 18 Feb 2004 11:17:08 -0800 Received: from mail.pacrimopen.com (localhost [127.0.0.1]) by mail.pacrimopen.com (Postfix) with ESMTP id 587317000BDA for ; Wed, 18 Feb 2004 11:18:13 -0800 (PST) Received: from UNKNOWN(127.0.0.1), claiming to be "mail.pacrimopen.com" via SMTP by sa-relay.pacrimopen.com, id smtpdExoXdL; Wed Feb 18 11:18:11 2004 Received: from bubbles.imr-net.com (unknown [12.111.175.170]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.pacrimopen.com (Postfix) with ESMTP id 1C5F87000BDA for ; Wed, 18 Feb 2004 11:18:11 -0800 (PST) Subject: xfsdump - From: Joshua Schmidlkofer To: XFS List Content-Type: text/plain Message-Id: <1077131825.4214.13.camel@bubbles.imr-net.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 18 Feb 2004 11:17:05 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: menion@asylumwear.com Precedence: bulk X-list: linux-xfs Can I xfsdump a live filesystem? js From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:20:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:20:43 -0800 (PST) Received: from smtp-out5.xs4all.nl (smtp-out5.xs4all.nl [194.109.24.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJKWKO023310 for ; Wed, 18 Feb 2004 11:20:33 -0800 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtp-out5.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1IJKTn2093599; Wed, 18 Feb 2004 20:20:30 +0100 (CET) Message-Id: <4.3.2.7.2.20040218201609.031b23b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Feb 2004 20:20:28 +0100 To: Joshua Schmidlkofer , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: xfs_repair -n -f - Dangerous? In-Reply-To: <1077131478.4214.11.camel@bubbles.imr-net.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2140 X-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:11 18-2-2004 -0800, Joshua Schmidlkofer wrote: >I see that running xfs_db is dangerous. I have a system that I ran >xfs_repair (-n -f) on a live filesystem, and it was a Bad Thing(tm). Is >that the case? not a lot was going on, but I got some really nice call >traces, =(. Then 990's on directory access, messages about corrupted >inodes. I initiated a reboot, but not before saving the logs Fixing a filesystem. 1. Reboot the server with your favorite rescue disk. Mine is the lnx-bbc disk. 2. Mount the filesystem, unmount the filesystem (so the log is flushed). 3. run xfs_repair -n to see what it wants to do. If it looks normalish you can run xfs_repair without -n. If xfs_repair recovers file and puts them in lost+found they will be unlinked and found again if you run xfs_repair another time. 4 It should be fixed. Reboot the server. Files might end up in lost+found if there are big problems. >I am trying to get data off it on to the stand-by, but Am I Borked? I don't think everything is hosed. But try above suggestion. Lnx-bbc disk has network support and other neccesary utilities to get data off. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:25:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:25:19 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJPBKO023731 for ; Wed, 18 Feb 2004 11:25:12 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id i1IJP6il031544; Wed, 18 Feb 2004 14:25:06 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id i1IJP6wN031540; Wed, 18 Feb 2004 14:25:06 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 18 Feb 2004 14:25:06 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Seth Mos cc: Linux xfs mailing list Subject: Re: Performance question In-Reply-To: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> Message-ID: References: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs On Wed, 18 Feb 2004 at 7:41pm, Seth Mos wrote > At 12:57 18-2-2004 -0500, Joshua Baker-LePain wrote: > >I've pretty much ruled out hardware. I've swapped the 3ware and rebuilt > >the array, and the disks all show good SMART data. > > Have you considered raid 10 configuration? It will about halve the storage > space but increase IO by a multiple. Unfortunately I shold have mentioned that this is a heavily used production server, and doing anything the requires rebuilding the FS is pretty much off limits unless I have a *very* good reason. > You could flip the cover and see if the disks are pushed hard by the > controller (leds on the 3ware controller). Although from what you described > above it's probably a directory growing a bit on the large side. Yeah, I really think it's the large number of files. I'm working to see how much of them we can clean up right now. I was wondering if xfs_fsr would be a good idea, but ISTR it not being all that highly recommended. > Perhaps creating the filessystem with a larger inode size like 512. You > could also use version logs instead of version which mostly helped software > raid 5 although this might help hardware as well. Again, mkfs is a hard sell right now. Thanks for the input. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:43:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:43:48 -0800 (PST) Received: from smtp-out5.xs4all.nl (smtp-out5.xs4all.nl [194.109.24.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJhLKO024357 for ; Wed, 18 Feb 2004 11:43:22 -0800 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtp-out5.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1IJhEn2006627; Wed, 18 Feb 2004 20:43:14 +0100 (CET) Message-Id: <4.3.2.7.2.20040218203942.02fb0d78@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Feb 2004 20:43:12 +0100 To: Joshua Baker-LePain From: Seth Mos Subject: Re: Performance question Cc: Linux xfs mailing list In-Reply-To: References: <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> <4.3.2.7.2.20040218193615.035c24c8@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2142 X-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:25 18-2-2004 -0500, Joshua Baker-LePain wrote: >On Wed, 18 Feb 2004 at 7:41pm, Seth Mos wrote > > > At 12:57 18-2-2004 -0500, Joshua Baker-LePain wrote: > > > You could flip the cover and see if the disks are pushed hard by the > > controller (leds on the 3ware controller). Although from what you > described > > above it's probably a directory growing a bit on the large side. >Yeah, I really think it's the large number of files. I'm working to see >how much of them we can clean up right now. I was wondering if xfs_fsr >would be a good idea, but ISTR it not being all that highly recommended. You might be able to make 1 2 3 4 5 ... directories or based on the first letter. the is also very often at providers with a _lot_ of usernames. This will greatly reduce the amount of files in one directory and thus make doing dumps a lot easier and faster. XFS was was ment to be scalable but 413 million files (if I read correctly) is stretching it. > > Perhaps creating the filessystem with a larger inode size like 512. You > > could also use version logs instead of version which mostly helped > software > > raid 5 although this might help hardware as well. > >Again, mkfs is a hard sell right now. My brain is failing right now, but I think you might be able to xfs_growfs. Search the archive for it. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Feb 18 11:44:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 11:44:38 -0800 (PST) Received: from smtp-out6.xs4all.nl (smtp-out6.xs4all.nl [194.109.24.7]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IJiUKO024464 for ; Wed, 18 Feb 2004 11:44:31 -0800 Received: from auto-nb1.xs4all.nl (a80-126-90-136.adsl.xs4all.nl [80.126.90.136]) by smtp-out6.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1IJiRiV078673; Wed, 18 Feb 2004 20:44:27 +0100 (CET) Message-Id: <4.3.2.7.2.20040218204321.033df780@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Feb 2004 20:44:26 +0100 To: Joshua Schmidlkofer , XFS List From: Seth Mos Subject: Re: xfsdump - In-Reply-To: <1077131825.4214.13.camel@bubbles.imr-net.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 11:17 18-2-2004 -0800, Joshua Schmidlkofer wrote: >Can I xfsdump a live filesystem? xfsdump can only use mounted filesystems to do the dumps. Restores can go to device directly IIRC. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Wed Feb 18 12:07:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 12:07:28 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IK73KO025328 for ; Wed, 18 Feb 2004 12:07:03 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1IK6rFC009923 for ; Wed, 18 Feb 2004 12:06:57 -0800 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 HAA16056; Thu, 19 Feb 2004 07:06:43 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1IK6f8n248879; Thu, 19 Feb 2004 07:06:42 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1IK6Umo248842; Thu, 19 Feb 2004 07:06:30 +1100 (EST) Date: Thu, 19 Feb 2004 07:06:30 +1100 From: Nathan Scott To: Seth Mos Cc: Joshua Schmidlkofer , XFS List Subject: Re: xfsdump - Message-ID: <20040219070630.C244261@wobbly.melbourne.sgi.com> References: <1077131825.4214.13.camel@bubbles.imr-net.com> <4.3.2.7.2.20040218204321.033df780@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20040218204321.033df780@pop.xs4all.nl>; from knuffie@xs4all.nl on Wed, Feb 18, 2004 at 08:44:26PM +0100 X-archive-position: 2144 X-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, Feb 18, 2004 at 08:44:26PM +0100, Seth Mos wrote: > At 11:17 18-2-2004 -0800, Joshua Schmidlkofer wrote: > >Can I xfsdump a live filesystem? > > xfsdump can only use mounted filesystems to do the dumps. Restores can go > to device directly IIRC. Both xfsdump & xfsrestore go to mounted filesystems (restore does creates/mkdirs/chmods,etc). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 18 12:08:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 12:08:46 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IK8fKO025576 for ; Wed, 18 Feb 2004 12:08:41 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1IK8XFC010154 for ; Wed, 18 Feb 2004 12:08:34 -0800 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 HAA16089; Thu, 19 Feb 2004 07:08:23 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1IK8M8n248203; Thu, 19 Feb 2004 07:08:23 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1IK8L2v248919; Thu, 19 Feb 2004 07:08:21 +1100 (EST) Date: Thu, 19 Feb 2004 07:08:21 +1100 From: Nathan Scott To: Joshua Schmidlkofer Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_repair -n -f - Dangerous? Message-ID: <20040219070821.D244261@wobbly.melbourne.sgi.com> References: <1077131478.4214.11.camel@bubbles.imr-net.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1077131478.4214.11.camel@bubbles.imr-net.com>; from menion@asylumwear.com on Wed, Feb 18, 2004 at 11:11:18AM -0800 X-archive-position: 2145 X-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, Feb 18, 2004 at 11:11:18AM -0800, Joshua Schmidlkofer wrote: > I see that running xfs_db is dangerous. I have a system that I ran > xfs_repair (-n -f) on a live filesystem, and it was a Bad Thing(tm). Is > that the case? not a lot was going on, but I got some really nice call yes, xfs_repair will have the same problem as xfs_db. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 18 12:18:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 12:18:34 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IKIQKO026450 for ; Wed, 18 Feb 2004 12:18:27 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1IKIKFC012181 for ; Wed, 18 Feb 2004 12:18:21 -0800 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 HAA16284; Thu, 19 Feb 2004 07:18:13 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1IKI28n246767; Thu, 19 Feb 2004 07:18:02 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1IKI0H1249255; Thu, 19 Feb 2004 07:18:00 +1100 (EST) Date: Thu, 19 Feb 2004 07:18:00 +1100 From: Nathan Scott To: Joshua Baker-LePain , sandeen@sgi.com Cc: Linux xfs mailing list Subject: Re: Performance question Message-ID: <20040219071800.F244261@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 jlb17@duke.edu on Wed, Feb 18, 2004 at 12:57:35PM -0500 X-archive-position: 2146 X-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, Feb 18, 2004 at 12:57:35PM -0500, Joshua Baker-LePain wrote: > I have a server with a single 3ware 7500-8 board and 8 Maxtor 160GB disks > running as a hardware RAID5 w/ a hot spare. I'm running RedHat 7.3 and > the 2.4.18-18SGI_XFS_1.2.0smp kernel (more on the kernel later). The > partitions look like this: > > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/sda1 505605 133975 345526 28% / > /dev/sda2 4127108 3810308 107152 98% /home > none 1031920 0 1031920 0% /dev/shm > /dev/sda7 1027768 20140 955420 3% /tmp > /dev/sda3 2063536 1797416 161296 92% /usr > /dev/sda5 3099260 2799304 142524 96% /usr/local > /dev/sda6 1027768 117548 858012 13% /var > /dev/sda8 948330428 627683892 320646536 67% /data > > Only /data is XFS, the rest are ext3. Backups on /data on this machine > have been slowing to a crawl. I use amanda, and even the estimate phase > (which does 'tar cf /dev/null' and so should be very fast) takes hours. I > tried upgrading to 2.4.21 plus the 1.3 XFS patches (I'm running this on 2 > other 3ware based servers), and this made the situation much worse. > During backups, the OOM killer started going crazy, killing bash sessions > and eventually the estimate tar process. Sounds like Eric's area of expertise. :) Could be another case of inodes not being reclaimed aggresively enough, and OOM follows...? > In narrowing down the problem, it seems that one particular (large) > directory is the main culprit. This dir is 471,401,788 KB big and has > 3,377,520 files (~140KB/file average). Is the large number of files the > entire culprit? If so, is there anything I can do to alleviate the > problem? I already 'mount -o logbufs=8'. Here's xfs_info on that cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 18 13:02:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 13:03:01 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IL2qKO031286 for ; Wed, 18 Feb 2004 13:02:52 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1IKpvFC019266 for ; Wed, 18 Feb 2004 12:51:58 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1IKpru434349855; Wed, 18 Feb 2004 14:51:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1IKpmGa006696; Wed, 18 Feb 2004 14:51:48 -0600 (CST) Subject: Re: Performance question From: Eric Sandeen To: Nathan Scott Cc: Joshua Baker-LePain , Linux xfs mailing list In-Reply-To: <20040219071800.F244261@wobbly.melbourne.sgi.com> References: <20040219071800.F244261@wobbly.melbourne.sgi.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1077137507.14414.18.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 18 Feb 2004 14:51:48 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2147 X-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 > Sounds like Eric's area of expertise. :) Could be another > case of inodes not being reclaimed aggresively enough, and > OOM follows...? Ah... sure... :) Can you watch /proc/slabinfo as this happens, is any particular slab cache growing extremely large? Where is the memory going? Glen suggested that perhaps your directory with all the inodes is terribly fragmented, can you try # xfs_bmap /path/to/big/dir and see how many extents it has... -Eric -- Eric Sandeen [C]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 Feb 18 13:04:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 13:04:42 -0800 (PST) Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IL4XKO031962 for ; Wed, 18 Feb 2004 13:04:34 -0800 Received: from chaos.egr.duke.edu (localhost.localdomain [127.0.0.1]) by chaos.egr.duke.edu (8.12.8/8.12.8) with ESMTP id i1IL4Sil031908; Wed, 18 Feb 2004 16:04:28 -0500 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.12.8/8.12.8/Submit) with ESMTP id i1IL4SsJ031904; Wed, 18 Feb 2004 16:04:28 -0500 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Wed, 18 Feb 2004 16:04:28 -0500 (EST) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Eric Sandeen cc: Nathan Scott , Linux xfs mailing list Subject: Re: Performance question In-Reply-To: <1077137507.14414.18.camel@stout.americas.sgi.com> Message-ID: References: <20040219071800.F244261@wobbly.melbourne.sgi.com> <1077137507.14414.18.camel@stout.americas.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlb17@duke.edu Precedence: bulk X-list: linux-xfs On Wed, 18 Feb 2004 at 2:51pm, Eric Sandeen wrote > > Sounds like Eric's area of expertise. :) Could be another > > case of inodes not being reclaimed aggresively enough, and > > OOM follows...? > > Ah... sure... :) There's nothing like confidence I always say... ;) > Can you watch /proc/slabinfo as this happens, is any particular slab > cache growing extremely large? Where is the memory going? I'll schedule some time to reboot into the "newer" kernel to try this. I reverted to XFS 1.2 after that behavior (obviously), and can't reboot ATM as we're in the midst of archiving the Visible Human data. > Glen suggested that perhaps your directory with all the inodes is > terribly fragmented, can you try > > # xfs_bmap /path/to/big/dir > > and see how many extents it has... /data/vcc/vccMuscles_testfiles/: 0: [0..7]: 1417836144..1417836151 1: [8..15]: 1417835896..1417835903 I feel like I should clarify that those 3.3M files are spread out in a deeply branching tree of subdirectories under /data/vcc/vccMuscles_testfiles. There are ~29K total, and they go several levels deep. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Wed Feb 18 14:09:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 14:09:16 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IM8xKO001312 for ; Wed, 18 Feb 2004 14:09:00 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1ILxtgF030583 for ; Wed, 18 Feb 2004 15:59:55 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1ILxptA34250379; Wed, 18 Feb 2004 15:59:51 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1ILxoGa012132; Wed, 18 Feb 2004 15:59:50 -0600 (CST) Subject: Re: Performance question From: Eric Sandeen To: Joshua Baker-LePain Cc: Nathan Scott , Linux xfs mailing list In-Reply-To: References: <20040219071800.F244261@wobbly.melbourne.sgi.com> <1077137507.14414.18.camel@stout.americas.sgi.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1077141590.14414.43.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 18 Feb 2004 15:59:50 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2149 X-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, 2004-02-18 at 15:04, Joshua Baker-LePain wrote: > /data/vcc/vccMuscles_testfiles/: > 0: [0..7]: 1417836144..1417836151 > 1: [8..15]: 1417835896..1417835903 > > I feel like I should clarify that those 3.3M files are spread out in a > deeply branching tree of subdirectories under > /data/vcc/vccMuscles_testfiles. There are ~29K total, and they go several > levels deep. If any one of those has a huge number of inodes in a single dir, that'd be the one we're interested in. -Eric -- Eric Sandeen [C]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 Feb 18 14:58:37 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 14:59:05 -0800 (PST) Received: from sasami.anime.net (sasami.anime.net [207.109.251.120]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IMwaKO005620 for ; Wed, 18 Feb 2004 14:58:37 -0800 Received: from localhost (goemon@localhost) by sasami.anime.net (8.11.6/8.11.6) with ESMTP id i1IMwZ603390 for ; Wed, 18 Feb 2004 14:58:35 -0800 Date: Wed, 18 Feb 2004 14:58:34 -0800 (PST) From: Dan Hollis To: linux xfs ml Subject: All your XFS are belong to SCO Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: goemon@anime.net Precedence: bulk X-list: linux-xfs SCO has just expanded their lawsuit to claim ownership over XFS (and presumably, all of IRIX): http://www.groklaw.net/article.php?story=20040215015800694 "In Exhibit C, SCO sets forth additional code in Linux in which SCO claims a right. Specifically, Exhibit C shows that Silicon Graphics, Inc. ("SGI") violated its UNIX Software Agreement with SCO by transferring direct lines of UNIX to Linux from its version of UNIX known as "IRIX." IRIX is a derivative work of, and modification based on, System V that contains substantial parts of System V code. In addition to SGI's transfer of direct lines of code from UNIX System V to Linux, as set forth in Exhibit A attached hereto, SGI has improperly transferred the UNIX filing system it developed as part of IRIX to Linux, thereby improperly giving the Linux open source developers access to an advanced journaling file system for streaming media for use in enterprise applications of Linux. On information and belief, most or all of the code contained in all of the files of the IRIX/XFS filing system have been improperly transferred to Linux" What is SGI's position on this? -Dan From owner-linux-xfs@oss.sgi.com Wed Feb 18 15:03:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 15:03:43 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1IN3cKO006347 for ; Wed, 18 Feb 2004 15:03:39 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AtajA-0003ts-W9; Wed, 18 Feb 2004 23:03:36 +0000 Date: Wed, 18 Feb 2004 23:03:36 +0000 From: Christoph Hellwig To: Dan Hollis Cc: linux xfs ml Subject: Re: All your XFS are belong to SCO Message-ID: <20040218230336.A14980@infradead.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from goemon@anime.net on Wed, Feb 18, 2004 at 02:58:34PM -0800 X-archive-position: 2151 X-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 > What is SGI's position on this? I think this the wrong list to ask. If you want some form of answer your best bet is to ask an executive, but even then I wouldn't want to guarantee for anything :) From owner-linux-xfs@oss.sgi.com Wed Feb 18 15:11:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 15:11:37 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1INBOKO006823 for ; Wed, 18 Feb 2004 15:11:24 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1IMDBJS008706 for ; Wed, 18 Feb 2004 14:13:12 -0800 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 KAA19427; Thu, 19 Feb 2004 10:11:09 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1INB78n253115; Thu, 19 Feb 2004 10:11:08 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1INALk0001168; Thu, 19 Feb 2004 10:10:21 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1INAKxW001166; Thu, 19 Feb 2004 10:10:20 +1100 Date: Thu, 19 Feb 2004 10:10:20 +1100 From: Nathan Scott To: Dan Hollis Cc: linux xfs ml Subject: Re: All your XFS are belong to SCO Message-ID: <20040218231020.GH641@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 2152 X-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, Feb 18, 2004 at 02:58:34PM -0800, Dan Hollis wrote: > SCO has just expanded their lawsuit to claim ownership over XFS (and > presumably, all of IRIX): > http://www.groklaw.net/article.php?story=20040215015800694 > ... > What is SGI's position on this? SGI's position is publically stated in the first paragraph here: http://oss.sgi.com/projects/xfs/ and the letter it refers to, here: http://oss.sgi.com/letter_100103.txt cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 18 18:01:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 18:01:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1J21IKO007173 for ; Wed, 18 Feb 2004 18:01:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1J0wt5h004527 for ; Wed, 18 Feb 2004 16:58:55 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1J1uqhI11898886; Thu, 19 Feb 2004 12:56:52 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1J1upu011925162; Thu, 19 Feb 2004 12:56:51 +1100 (EST) Date: Thu, 19 Feb 2004 12:56:51 +1100 (EST) From: Nathan Scott Message-Id: <200402190156.i1J1upu011925162@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 907983 - fix security attrs interface for xfsdump X-archive-position: 2153 X-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 the by-handle attr list interface (used by xfsdump) for security namespace attrs. Date: Wed Feb 18 17:55:09 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167038a xfs_attr_leaf.c - 1.77 xfs_attr.h - 1.30 linux-2.6/xfs_iops.c - 1.215 linux-2.4/xfs_iops.c - 1.204 From owner-linux-xfs@oss.sgi.com Wed Feb 18 22:06:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 22:06:10 -0800 (PST) Received: from stargate.coplanar.net (root@CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1J665KO013127 for ; Wed, 18 Feb 2004 22:06:05 -0800 Received: from coplanar.net (thunderdome.skynet.coplanar.net [192.168.7.3]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1J65vhE014956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 19 Feb 2004 01:05:58 -0500 Message-ID: <4034523A.9090305@coplanar.net> Date: Thu, 19 Feb 2004 01:05:46 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: Nicolas Kowalski CC: linux-xfs@oss.sgi.com Subject: Re: xfsrestore -i with ssh/rsh+dd as stdin References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (stargate.coplanar.net: domain of jerj@coplanar.net designates 192.168.7.3 as SASL permitted sender) X-archive-position: 2154 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Nicolas Kowalski wrote: > gaspard:/restore# dd if=/dev/nst0 bs=1024k | xfsrestore -J -i - /restore I'm not sure what the problem is, but what you are doing is meant do be done with rmt. You can still use ssh, but instead of dd handling the tape the rmt utility will do it. You get other benefits too, like the ability to catalog your backups with xfsinvutil, and xfsdump/xfsrestore can handle moving between different tape files (filemarks). Regards, Jeremy From owner-linux-xfs@oss.sgi.com Wed Feb 18 23:30:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Feb 2004 23:30:51 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1J7UcKO015016 for ; Wed, 18 Feb 2004 23:30:38 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1J7UcRJ015015 for linux-xfs@oss.sgi.com; Wed, 18 Feb 2004 23:30:38 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1J7UbKQ015001 for ; Wed, 18 Feb 2004 23:30:37 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1J7L8Zn014857; Wed, 18 Feb 2004 23:21:08 -0800 Date: Wed, 18 Feb 2004 23:21:08 -0800 Message-Id: <200402190721.i1J7L8Zn014857@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] New: ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2155 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 Summary: ioctl hang in 2.6.x kernels with quota support Product: Linux XFS Version: Current Platform: IA32 OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: XFS kernel code AssignedTo: xfs-master@oss.sgi.com ReportedBy: steven.wilton@team.eftel.com I am having problems where a call to ioctl(x, XFS_IOC_FSBULKSTAT, y) hangs after a random number of recursions when the system is under load. The bug occurs when using the "quot" command, while in the following segment of code: j=0; while ((sts = ioctl(fsfd, XFS_IOC_FSBULKSTAT, &bulkreq)) == 0) { j++; printf("IOCTL %d finished\n",j); if (count == 0) break; for (i = 0; i < count; i++) acctXFS(&buf[i]); } The quot command hangs in a D state, and the only way to kill the process is to reboot the server. After a reboot, running the quot command again will hang at a different value of j. If I do not reboot the server, and run another instance of quot, it will hang at the same value of j. The comamnd I am running is "quot -f ". I did notice on my most recent attempt that there was a pdflush kernel process that had started up at about the same time that the quot command hung. I am running the 2.6.3 kernel with the XFS kernel code that came with the kernel, and this problem also occurred on the 2.6.2 kernel. I am using the quota tools v3.10. I have reverted back to the 2.4.22 kernel with the xfs patch applied, and this does not suffer from the same problem. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 19 00:25:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 00:26:25 -0800 (PST) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1J8PvKO019520 for ; Thu, 19 Feb 2004 00:25:58 -0800 Received: from mail-veri.imag.fr (pave.imag.fr [129.88.43.12]) by imag.imag.fr (8.12.10/8.12.10) with ESMTP id i1J8PssX010475 for ; Thu, 19 Feb 2004 09:25:54 +0100 (CET) Received: from gandoliere.imag.fr ([129.88.43.136] helo=gandoliere.imag.fr.imag.fr ident=kowalski) by mail-veri.imag.fr with esmtp (Exim 3.35 #1 (Debian)) id 1AtjVK-0004rZ-00 for ; Thu, 19 Feb 2004 09:25:54 +0100 To: linux-xfs@oss.sgi.com Subject: Re: xfsrestore -i with ssh/rsh+dd as stdin References: <4034523A.9090305@coplanar.net> From: Nicolas Kowalski Mail-Copies-To: never Date: Thu, 19 Feb 2004 09:25:53 +0100 In-Reply-To: <4034523A.9090305@coplanar.net> (Jeremy Jackson's message of "Thu, 19 Feb 2004 01:05:46 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information X-archive-position: 2156 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Nicolas.Kowalski@imag.fr Precedence: bulk X-list: linux-xfs Jeremy Jackson writes: > Nicolas Kowalski wrote: > >> gaspard:/restore# dd if=/dev/nst0 bs=1024k | xfsrestore -J -i - /restore > > > I'm not sure what the problem is, but what you are doing is meant do > be done with rmt. You can still use ssh, but instead of dd handling > the tape the rmt utility will do it. > > You get other benefits too, like the ability to catalog your backups > with xfsinvutil, and xfsdump/xfsrestore can handle moving between > different tape files (filemarks). I am using dd to force the "drive_simple" strategy of xfsdump and xfsrestore; I do not want them to move between tape files, for various reasons. Thanks for your reply. -- Nicolas From owner-linux-xfs@oss.sgi.com Thu Feb 19 01:12:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 01:12:50 -0800 (PST) Received: from hob.acsalaska.net (hob.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1J9CZKO020444 for ; Thu, 19 Feb 2004 01:12:35 -0800 Received: from erbenson.alaska.net (159-pm3.nwc.acsalaska.net [209.112.138.159]) by hob.acsalaska.net (8.12.10/8.12.10) with ESMTP id i1J9CXI0028926 for ; Thu, 19 Feb 2004 00:12:33 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 87BD339E5 for ; Thu, 19 Feb 2004 00:12:32 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id DF7FF40FF35; Thu, 19 Feb 2004 00:12:31 -0900 (AKST) Date: Thu, 19 Feb 2004 00:12:31 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - Merge up to 2.4.25 final Message-ID: <20040219091231.GD11765@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <200402181748.i1IHmYGf023385@penguin5.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TakKZr9L6Hm6aLOc" Content-Disposition: inline In-Reply-To: <200402181748.i1IHmYGf023385@penguin5.americas.sgi.com> User-Agent: Mutt/1.3.28i X-OS: Debian GNU X-gpg-fingerprint: E3E4 D0BC 31BC F7BB C1DD C3D6 24AC 7B1A 2C44 7AFC X-gpg-key: http://www.alaska.net/~erbenson/gpg/key.asc Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.61; spamdefang 1.93 X-archive-position: 2157 X-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 --TakKZr9L6Hm6aLOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable are there any important fixes in the SGI trees that did not make it into 2.4.25 proper? On Wed, Feb 18, 2004 at 11:48:34AM -0600, Eric Sandeen wrote: > Just a makefile change :) >=20 > Date: Wed Feb 18 09:47:50 PST 2004 > Workarea: penguin5.americas.sgi.com:/src/eric/linux-2.4.x >=20 > The following file(s) were checked into: > bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs >=20 >=20 > Modid: 2.4.x-xfs:linux:166945a > Makefile - 1.11 > - Merge up to 2.4.25 final >=20 >=20 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --TakKZr9L6Hm6aLOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkA0ff8ACgkQJKx7GixEevw+yQCcDFNPHgd1Okogbo2Gji3BLCbg Ho0AoJ6PywyY79dopqiEX9NpcIbJtESP =t4QM -----END PGP SIGNATURE----- --TakKZr9L6Hm6aLOc-- From owner-linux-xfs@oss.sgi.com Thu Feb 19 06:34:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 06:34:17 -0800 (PST) Received: from blake.timetraveller.org (blake.timetraveller.org [203.23.43.10]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1JEY2KO011094 for ; Thu, 19 Feb 2004 06:34:03 -0800 Received: from zen.timetraveller.org (CPE00105ae6b1e1-CM000039aeec61.cpe.net.cable.rogers.com [63.138.11.154]) by blake.timetraveller.org (8.12.3/8.12.3) with ESMTP id i1JEXqhT016110 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 20 Feb 2004 00:33:55 +1000 Received: from zen.timetraveller.org (zen.timetraveller.org [192.168.120.2]) by zen.timetraveller.org (8.12.11/8.12.11) with ESMTP id i1JEXpgx013383 for ; Thu, 19 Feb 2004 09:33:51 -0500 Date: Thu, 19 Feb 2004 09:33:51 -0500 (EST) From: Robert Brockway To: XFS List Subject: Re: xfsdump - In-Reply-To: <20040219070630.C244261@wobbly.melbourne.sgi.com> Message-ID: References: <1077131825.4214.13.camel@bubbles.imr-net.com> <4.3.2.7.2.20040218204321.033df780@pop.xs4all.nl> <20040219070630.C244261@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2158 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: robert@timetraveller.org Precedence: bulk X-list: linux-xfs On Thu, 19 Feb 2004, Nathan Scott wrote: > On Wed, Feb 18, 2004 at 08:44:26PM +0100, Seth Mos wrote: > > At 11:17 18-2-2004 -0800, Joshua Schmidlkofer wrote: > > >Can I xfsdump a live filesystem? > > > > xfsdump can only use mounted filesystems to do the dumps. Restores can go > > to device directly IIRC. > > Both xfsdump & xfsrestore go to mounted filesystems (restore > does creates/mkdirs/chmods,etc). Just to provide a real world example: I do live backups of all my xfs filesystems. About 6 months ago I had to invoke a DR (disaster recovery) on one box that runs xfs exclusively. I used xfsrestore to return the data to disk from the latest full & incremental backups and it worked flawlessly. Within a short space of time my system was back up and doing productive work again. I'm sending this email from that very system now. Cheers, Rob -- Robert Brockway B.Sc. email: robert@timetraveller.org, zzbrock@uqconnect.net Linux counter project ID #16440 (http://counter.li.org) "The earth is but one country and mankind its citizens" -Baha'u'llah From owner-linux-xfs@oss.sgi.com Thu Feb 19 06:47:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 06:48:09 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1JEljKO011970 for ; Thu, 19 Feb 2004 06:47:45 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1JEletP003065 for ; Thu, 19 Feb 2004 06:47:40 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1JElctr34381761; Thu, 19 Feb 2004 08:47:38 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AtpSk-0002AV-00; Thu, 19 Feb 2004 08:47:38 -0600 Subject: TAKE 909820 - only lock pagecache pages Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Thu, 19 Feb 2004 08:47:38 -0600 X-archive-position: 2159 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Feb 19 06:45:48 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167054a fs/xfs/linux-2.6/xfs_buf.h - 1.87 - add a flag for pages from the pagecache fs/xfs/linux-2.6/xfs_buf.c - 1.149 - only lock pagecache pages fs/xfs/linux-2.4/xfs_buf.h - 1.93 - add a flag for pages from the pagecache fs/xfs/linux-2.4/xfs_buf.c - 1.169 - only lock pagecache pages From owner-linux-xfs@oss.sgi.com Thu Feb 19 08:18:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 08:19:10 -0800 (PST) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1JGIjKO014183 for ; Thu, 19 Feb 2004 08:18:48 -0800 Received: (qmail 9284 invoked by uid 89); 19 Feb 2004 16:18:32 -0000 Received: from unknown (HELO tamiweb.com) (212.122.164.1) by 0 with SMTP; 19 Feb 2004 16:18:32 -0000 Message-ID: <4034E1C9.9050103@tamiweb.com> Date: Thu, 19 Feb 2004 18:18:17 +0200 From: Kostadin Karaivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs-progs and libtool-1.5.2 issues Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2160 X-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@tamiweb.com Precedence: bulk X-list: linux-xfs Recently I upgarded my libtool to 1.5.2 (slackware-current) nad I'm n unable to compile xfs-cms anymore following error is excerpt from make in xfs-cmds/attr make -C . default make[1]: Entering directory `/usr/src/xfs-cmds/attr' === include === rm -f attr ln -s . attr === libmisc === /usr/bin/libtool --mode=compile gcc -g -DDEBUG -funsigned-char -Wall -I../include -DVERSION=\"2.4.15\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"attr\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT -fno-strict-aliasing -c quote.c libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[2]: *** [quote.lo] Error 1 make[1]: *** [default] Error 2 make[1]: Leaving directory `/usr/src/xfs-cmds/attr' make: *** [default] Error 2 From owner-linux-xfs@oss.sgi.com Thu Feb 19 13:27:59 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 13:28:12 -0800 (PST) Received: from saytrin.hq.k1024.org ([62.217.245.194]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1JLRpKO032253 for ; Thu, 19 Feb 2004 13:27:55 -0800 Received: by saytrin.hq.k1024.org (Postfix, from userid 4004) id 824CBE2; Thu, 19 Feb 2004 23:29:45 +0200 (EET) Date: Thu, 19 Feb 2004 23:29:45 +0200 From: Iustin Pop To: XFS List Subject: Re: xfsdump - Message-ID: <20040219212945.GA7797@saytrin.hq.k1024.org> Mail-Followup-To: XFS List References: <1077131825.4214.13.camel@bubbles.imr-net.com> <4.3.2.7.2.20040218204321.033df780@pop.xs4all.nl> <20040219070630.C244261@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 2161 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: linux-xfs On Thu, Feb 19, 2004 at 09:33:51AM -0500, Robert Brockway wrote: > I used xfsrestore to return the > data to disk from the latest full & incremental backups and it worked > flawlessly. Within a short space of time my system was back up and doing > productive work again. I'm sending this email from that very system now. Unfortunately, I've had some trouble with xfsdump/xfsrestore in the past. Using a xfsdump -l0 ... | xfsrestore ... worker, but a second xfsdump -l1 ... | xfsrestor failed in xfsrestore. So I'd advise you to make a few confirmation tests before going into production. FYI, the error I encountered was: xfsrestore: node.c:669: node_map: Assertion `nodegen == hdlgen' failed. Didn't manage to find a working solution (and ended up with rsync). Regards, Iustin Pop From owner-linux-xfs@oss.sgi.com Thu Feb 19 14:04:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 14:05:08 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1JM4qKO001764 for ; Thu, 19 Feb 2004 14:04:52 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1JM4itP011513 for ; Thu, 19 Feb 2004 14:04:46 -0800 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 JAA08630 for ; Fri, 20 Feb 2004 09:04:43 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1JM4g8n279497 for ; Fri, 20 Feb 2004 09:04:42 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1JM3sSH000864 for ; Fri, 20 Feb 2004 09:03:54 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1JM3rOT000862 for linux-xfs@oss.sgi.com; Fri, 20 Feb 2004 09:03:53 +1100 Date: Fri, 20 Feb 2004 09:03:53 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - Merge up to 2.4.25 final Message-ID: <20040219220353.GA738@frodo> References: <200402181748.i1IHmYGf023385@penguin5.americas.sgi.com> <20040219091231.GD11765@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040219091231.GD11765@plato.local.lan> User-Agent: Mutt/1.5.3i X-archive-position: 2162 X-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 Thu, Feb 19, 2004 at 12:12:31AM -0900, Ethan Benson wrote: > > are there any important fixes in the SGI trees that did not make it > into 2.4.25 proper? Not really - theres been a bunch of pagebuf work done, but that needs a bit more soak time before going to Marcelo. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Feb 19 18:01:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 18:02:10 -0800 (PST) Received: from vsmtp2.tin.it (smtp.virgilio.it [212.216.176.142] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1K21tKO012600 for ; Thu, 19 Feb 2004 18:01:56 -0800 Received: from host76-140.pool80104.interbusiness.it (80.104.140.76) by vsmtp2.tin.it (7.0.019) (authenticated as silvanadimartino) id 40338BD900031204 for linux-xfs@oss.sgi.com; Thu, 19 Feb 2004 13:16:10 +0100 From: Silvana Di Martino To: linux xfs ml Subject: All your thoughts belong to SCO Date: Thu, 19 Feb 2004 13:17:21 +0000 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200402191308.12734.silvanadimartino@tin.it> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-archive-position: 2163 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: silvanadimartino@tin.it Precedence: bulk X-list: linux-xfs SCO has just expanded their lawsuit to claim ownership over human thinking (and presumably, all of human being): http://www.groklaw.net/article.php?story=20040218015800694 "In Exhibit C, SCO sets forth additional code in Linux in which SCO claims a right. Specifically, Exhibit C shows that Silicon Graphics, Inc. ("SGI") violated its UNIX Software Agreement with SCO by transferring concepts of UNIX to Linux from its version of UNIX known as "IRIX." IRIX is a derivative work of, and modification based on, System V that contains ideas taken from System V code. In addition to SGI's transfer of direct lines of code from UNIX System V to Linux, as set forth in Exhibit A attached hereto, SGI has improperly transferred the UNIX concept of "module" (as in modular operating system) and many other intellectual concepts like "program", "assignement" and "operator" it developed as parts of IRIX to Linux, thereby improperly giving the Linux open source developers access to a advanced intellectual concepts for use in enterprise applications of Linux. On information and belief, most or all of the ideas contained in all of the files of the IRIX operating system have been improperly transferred to Linux" What is humankind's position on this? ----------------------------------------- Alessandro Bottoni alessandrobottoni@interfree.it From owner-linux-xfs@oss.sgi.com Thu Feb 19 18:30:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 18:30:45 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1K2UgKO013450 for ; Thu, 19 Feb 2004 18:30:42 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1K2UgOq013449 for linux-xfs@oss.sgi.com; Thu, 19 Feb 2004 18:30:42 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1K2UeKQ013435 for ; Thu, 19 Feb 2004 18:30:41 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1K1m9ID012381; Thu, 19 Feb 2004 17:48:09 -0800 Date: Thu, 19 Feb 2004 17:48:09 -0800 Message-Id: <200402200148.i1K1m9ID012381@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 311] ioctl hang in 2.6.x kernels with quota support X-Bugzilla-Reason: AssignedTo X-archive-position: 2164 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=311 ------- Additional Comments From nathans@sgi.com 2004-19-02 17:48 PDT ------- hi there, Hmmm... the was a bug fixed in the kernel bulkstat code between 2.6.2 and 2.6.3 - but I guess this is something else if you're using 2.6.3. I have run a few quick tests on all my local filesystems and haven't hit this problem - could you try the XFS 2.6 CVS kernel on oss.sgi.com? (when you do, also enable kdb and get a "bt" backtrace when it hangs). thanks. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 19 18:55:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 18:55:24 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1K2t0KO014555 for ; Thu, 19 Feb 2004 18:55:03 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1K2oORs005617 for ; Thu, 19 Feb 2004 20:50:25 -0600 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA13448 for ; Fri, 20 Feb 2004 13:50:17 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1K2oH7a019152 for ; Fri, 20 Feb 2004 13:50:17 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1K2oG77019150 for linux-xfs@oss.sgi.com; Fri, 20 Feb 2004 13:50:16 +1100 Date: Fri, 20 Feb 2004 13:50:16 +1100 From: Tim Shimmin Message-Id: <200402200250.i1K2oG77019150@sherman.melbourne.sgi.com> Subject: PARTIAL TAKE 907752 - xfstests Apparently-To: X-archive-position: 2165 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs add 086 to auto-qa group Date: Thu Feb 12 20:36:25 PST 2004 Modid: xfs-cmds:slinx:166731a xfstests/group - 1.52 - add 086 to auto-qa group only create a fulldir if need one Date: Thu Feb 12 20:56:03 PST 2004 Modid: xfs-cmds:slinx:166734a xfstests/common.log - 1.5 - only create a fulldir if need one Make some log recover tests work on other platforms - don't print out $SCRATCH_MNT. Also test 64K v2 logs. Date: Thu Feb 19 18:47:33 PST 2004 Modid: xfs-cmds:slinx:167180a xfstests/085 - 1.3 xfstests/085.out - 1.3 - don't output $SCRATCH_MNT which varies on hosts xfstests/086.out - 1.2 xfstests/086 - 1.2 - don't output $SCRATCH_MNT which varies on hosts don't do failure mkfs/mount cases which are already tested elsewhere add 64K v2 logs From owner-linux-xfs@oss.sgi.com Thu Feb 19 19:18:26 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 19:18:27 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1K3IPKO015446 for ; Thu, 19 Feb 2004 19:18:26 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1K2KMre019063 for ; Thu, 19 Feb 2004 18:20:22 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1K3IFhI12328546; Fri, 20 Feb 2004 14:18:15 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1K3IEF912347729; Fri, 20 Feb 2004 14:18:14 +1100 (EST) Date: Fri, 20 Feb 2004 14:18:14 +1100 (EST) From: Nathan Scott Message-Id: <200402200318.i1K3IEF912347729@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 905452 - mrlocks X-archive-position: 2166 X-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 Implement mrlocks on top of rwsems, instead of using our own mrlock code. Date: Thu Feb 19 19:16:57 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167181a Makefile-linux-2.6 - 1.187 linux-2.6/xfs_ksyms.c - 1.4 linux-2.6/mrlock.h - 1.13 From owner-linux-xfs@oss.sgi.com Thu Feb 19 21:55:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 21:55:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1K5tIKO021825 for ; Thu, 19 Feb 2004 21:55:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1K4vEre021596 for ; Thu, 19 Feb 2004 20:57:15 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15904; Fri, 20 Feb 2004 16:55:06 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1K5t67a019532; Fri, 20 Feb 2004 16:55:06 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1K5t4U0019530; Fri, 20 Feb 2004 16:55:04 +1100 Date: Fri, 20 Feb 2004 16:55:04 +1100 From: Tim Shimmin Message-Id: <200402200555.i1K5t4U0019530@sherman.melbourne.sgi.com> Subject: TAKE 909879 - mkfs log stripe/size check fix Apparently-To: Apparently-To: X-archive-position: 2167 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix up mkfs checking of logsize multiple of stripe size. Date: Thu Feb 19 21:47:04 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167194a xfsprogs/VERSION - 1.99 xfsprogs/doc/CHANGES - 1.136 - bump version for mkfs logsize check fix xfsprogs/mkfs/xfs_mkfs.c - 1.53 - Fix up mkfs to ensure that the log size is a multiple of the v2 log stripe size even if the log happens to be aligned on a log stripe boundary (always check it). Add some comments explaining use of lalign flag. Fix up output for mkfs failure with logsize not a multiple of stripe size. With impending mkfs change this should always happen not just for non-aligned logs. Date: Thu Feb 19 20:15:18 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167188a xfstests/082.out - 1.4 - Fix up output for mkfs failure with logsize not a multiple of stripe size. With impending mkfs change this should always happen not just for non-aligned logs. From owner-linux-xfs@oss.sgi.com Thu Feb 19 23:09:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Feb 2004 23:09:13 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1K78xKO023697 for ; Thu, 19 Feb 2004 23:09:00 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1K6Aure011566 for ; Thu, 19 Feb 2004 22:10:57 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA16606; Fri, 20 Feb 2004 18:08:49 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1K78S7a019672; Fri, 20 Feb 2004 18:08:49 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1K78NSd019670; Fri, 20 Feb 2004 18:08:23 +1100 Date: Fri, 20 Feb 2004 18:08:23 +1100 From: Tim Shimmin Message-Id: <200402200708.i1K78NSd019670@sherman.melbourne.sgi.com> Subject: TAKE 909639 - XFS log recovery for v2 >32K (64K) LRs on log wrap trips assert Apparently-To: Apparently-To: X-archive-position: 2168 X-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@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix log recovery case when have v2 log with size >32K and we have a Log Record wrapping around the physical log end. Need to reset the pb size back to what we were using and NOT just 32K. Date: Thu Feb 19 23:04:35 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167196a fs/xfs/xfs_log_recover.c - 1.285 - Fix log recovery case when have v2 log with size >32K and we have a Log Record wrapping around the physical log end. Need to reset the pb size back to what we were using and NOT just 32K. From owner-linux-xfs@oss.sgi.com Fri Feb 20 00:23:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 00:24:09 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1K8NXKO027596 for ; Fri, 20 Feb 2004 00:23:39 -0800 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1K8LsFD512334; Fri, 20 Feb 2004 03:21:54 -0500 Received: from sig-9-65-42-65.mts.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1K8LrIN194872; Fri, 20 Feb 2004 01:21:53 -0700 Subject: Re: DMAPI test suite. From: Ram Pai To: Dean Roehrich Cc: linux-xfs@oss.sgi.com In-Reply-To: <200402181519.i1IFJS9i11055016@clink.americas.sgi.com> References: <200402181519.i1IFJS9i11055016@clink.americas.sgi.com> Content-Type: text/plain Organization: Message-Id: <1077265286.7503.37.camel@dyn319009bld.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 20 Feb 2004 00:21:28 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2169 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linuxram@us.ibm.com Precedence: bulk X-list: linux-xfs On Wed, 2004-02-18 at 07:19, Dean Roehrich wrote: > It probably needs to be upgraded to the latest autotools. It's a bit old. > > I don't have an rpm for the binaries. Ok. I am not able to run this test suite. In any case, I want to validate the behavior of XFS for pre-unmount event. As per the spec the pre-unmount event should be generated before the operation is about to check for open files. However given the current VFS code I am not sure, how could ever any filesystem support this feature correctly. The VFS code may not even inform the filesystem specific unmount handler in some cases. As a result no filesystem can ever support this feature correctly. Is my understanding correct? Does XFS provide the pre-unmount event correctly? Any ideas? RP > Dean > > > >From: Ram Pai > >Is there tar file or some rpm of the DMAPI test suite. > > > >I tried compiling it from the CVS and ended up with > > > >../../../depcomp: ../../../depcomp: No such file or directory > > > >Thanks, > >RP > > > > > From owner-linux-xfs@oss.sgi.com Fri Feb 20 04:16:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 04:17:18 -0800 (PST) Received: from dingdong.cryptoapps.com (postfix@uslink-66.173.43-133.uslink.net [66.173.43.133] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KCGpKO001562 for ; Fri, 20 Feb 2004 04:16:51 -0800 Received: by dingdong.cryptoapps.com (Postfix, from userid 1001) id 4B439FBA3C; Fri, 20 Feb 2004 06:16:50 -0600 (CST) Date: Fri, 20 Feb 2004 04:16:50 -0800 From: Chris Wedgwood To: Tim Shimmin Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 909639 - XFS log recovery for v2 >32K (64K) LRs on log wrap trips assert Message-ID: <20040220121650.GA27998@dingdong.cryptoapps.com> References: <200402200708.i1K78NSd019670@sherman.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200402200708.i1K78NSd019670@sherman.melbourne.sgi.com> X-archive-position: 2170 X-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, Feb 20, 2004 at 06:08:23PM +1100, Tim Shimmin wrote: > Fix log recovery case when have v2 log with size >32K and we have a > Log Record wrapping around the physical log end. Need to reset the > pb size back to what we were using and NOT just 32K. Does this mean v2 logs are 'mostly' safe right now? --cw From owner-linux-xfs@oss.sgi.com Fri Feb 20 05:48:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 05:48:16 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KDm7KO006660 for ; Fri, 20 Feb 2004 05:48:07 -0800 Received: (qmail 32230 invoked from network); 20 Feb 2004 13:48:06 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 20 Feb 2004 13:48:06 -0000 Message-ID: <40360FC8.4060405@xfs.org> Date: Fri, 20 Feb 2004 07:46:48 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ram Pai CC: Dean Roehrich , linux-xfs@oss.sgi.com Subject: Re: DMAPI test suite. References: <200402181519.i1IFJS9i11055016@clink.americas.sgi.com> <1077265286.7503.37.camel@dyn319009bld.beaverton.ibm.com> In-Reply-To: <1077265286.7503.37.camel@dyn319009bld.beaverton.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2171 X-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@xfs.org Precedence: bulk X-list: linux-xfs Ram Pai wrote: > On Wed, 2004-02-18 at 07:19, Dean Roehrich wrote: > >>It probably needs to be upgraded to the latest autotools. It's a bit old. >> >>I don't have an rpm for the binaries. > > > Ok. I am not able to run this test suite. In any case, I want to > validate the behavior of XFS for pre-unmount event. > > As per the spec the pre-unmount event should be generated before the > operation is about to check for open files. However given the current > VFS code I am not sure, how could ever any filesystem support this > feature correctly. You are probably correct here, the vfs keeps track of the busy count and apart from the unmount_begin operation which is called in the MNT_FORCE case, there is not a lot of opportunity to insert this call. If the pre-unmount event is allowed to fail the unmount then this will not work either since it does not stop the unmount. > > The VFS code may not even inform the filesystem specific unmount handler > in some cases. As a result no filesystem can ever support this feature > correctly. Is my understanding correct? Does XFS provide the > pre-unmount event correctly? > There is a pre_unmount event in xfs, it is after the vfs has cleaned up all the inodes (in the put_super code), if it returns an error then the vfs will still finish the unmount, and you may well get one of those self destruct in 5 seconds messages. > Any ideas? > RP Al Viro is distinctly anti dmapi, so chances are slim to none I would say. Steve From owner-linux-xfs@oss.sgi.com Fri Feb 20 06:21:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 06:21:23 -0800 (PST) Received: from smtp-out1.xs4all.nl (smtp-out1.xs4all.nl [194.109.24.11]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KEL8KO007832 for ; Fri, 20 Feb 2004 06:21:09 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1KEL5q1082732; Fri, 20 Feb 2004 15:21:05 +0100 (CET) Message-Id: <4.3.2.7.2.20040220151739.02ffcee8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Feb 2004 15:21:04 +0100 To: Chris Wedgwood , Tim Shimmin From: Seth Mos Subject: Re: TAKE 909639 - XFS log recovery for v2 >32K (64K) LRs on log wrap trips assert Cc: linux-xfs@oss.sgi.com In-Reply-To: <20040220121650.GA27998@dingdong.cryptoapps.com> References: <200402200708.i1K78NSd019670@sherman.melbourne.sgi.com> <200402200708.i1K78NSd019670@sherman.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2172 X-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 04:16 20-2-2004 -0800, Chris Wedgwood wrote: >On Fri, Feb 20, 2004 at 06:08:23PM +1100, Tim Shimmin wrote: > > > Fix log recovery case when have v2 log with size >32K and we have a > > Log Record wrapping around the physical log end. Need to reset the > > pb size back to what we were using and NOT just 32K. > >Does this mean v2 logs are 'mostly' safe right now? I consider them safe. The system has a software raid 5 array with version 2 logs and was installed when version 2 logs were "just" available. I've had no issues with it. Note that my system is not high availability system of any kind, it's the test box for my department so it gets the odd thrashing and runs mostly experimental stuff first. And I've had no issues with it yet. Just make sure your favourite rescue disc has recent tools and kernel to mount the filesystems. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Fri Feb 20 06:34:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 06:35:15 -0800 (PST) Received: from moria.linuxis.net (moria.linuxis.net [209.237.231.67]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KEYtKO008346 for ; Fri, 20 Feb 2004 06:34:55 -0800 Received: (qmail 17435 invoked from network); 20 Feb 2004 14:30:18 -0000 Received: from unknown (HELO shoshana.dnsalias.org) (67.163.24.167) by 209.237.231.80 with SMTP; 20 Feb 2004 14:30:18 -0000 Received: (qmail 25935 invoked by uid 501); 20 Feb 2004 14:35:14 -0000 Date: Fri, 20 Feb 2004 08:34:52 -0600 From: John Palkovic To: linux-xfs@oss.sgi.com Subject: 2.6.3 build failure Message-ID: <20040220143452.GA25888@palkovic.org> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-archive-position: 2173 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linux-xfs@shoshana.dnsalias.org Precedence: bulk X-list: linux-xfs Config file is at http://shoshana.dnsalias.org/dot-config. This is a PIII cpu. No need to CC me on replies, I am on the list. Just pulled an update this AM, 20 Feb 2004 with cvs update -d. I use the official cvs repository from :pserver:cvs@oss.sgi.com:2401/cvs Compilation of xfs_attr.c fails thusly: make -f scripts/Makefile.build obj=fs/xfs gcc-2.95 -Wp,-MD,fs/xfs/.xfs_attr.o.d -nostdinc -iwithprefix include -D__KERNEL__ -Iinclude -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -Iinclude/asm-i386/mach-default -O2 -fomit-frame-pointer -Ifs/xfs -Ifs/xfs/linux-2.6 -funsigned-char -DKBUILD_BASENAME=xfs_attr -DKBUILD_MODNAME=xfs -c -o fs/xfs/xfs_attr.o fs/xfs/xfs_attr.c In file included from fs/xfs/xfs_attr.c:56: fs/xfs/xfs_inode.h:269: parse error before `mrlock_t' fs/xfs/xfs_inode.h:269: warning: no semicolon at end of struct or union fs/xfs/xfs_inode.h:270: warning: type defaults to `int' in declaration of `i_iolock' fs/xfs/xfs_inode.h:270: warning: data definition has no type or storage class fs/xfs/xfs_inode.h:309: parse error before `}' fs/xfs/xfs_inode.h:309: warning: type defaults to `int' in declaration of `xfs_inode_t' fs/xfs/xfs_inode.h:309: warning: data definition has no type or storage class fs/xfs/xfs_inode.h:472: parse error before `*' ... It fails with the same error using gcc-3.3 (should I be using 2.95 or 3.3?). xfs_inode.h hasn't changed in months, so this is puzzling to me. The rest of the make error output is at http://shoshana.dnsalias.org/make.out regards, -John -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell From owner-linux-xfs@oss.sgi.com Fri Feb 20 06:51:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 06:52:05 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KEpoKO008852 for ; Fri, 20 Feb 2004 06:51:51 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AuC0L-0001U6-Lc for linux-xfs@oss.sgi.com; Fri, 20 Feb 2004 14:51:49 +0000 Date: Fri, 20 Feb 2004 14:51:49 +0000 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: 2.6.3 build failure Message-ID: <20040220145149.A5706@infradead.org> References: <20040220143452.GA25888@palkovic.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: <20040220143452.GA25888@palkovic.org>; from linux-xfs@shoshana.dnsalias.org on Fri, Feb 20, 2004 at 08:34:52AM -0600 X-archive-position: 2174 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Feb 20, 2004 at 08:34:52AM -0600, John Palkovic wrote: > fs/xfs/xfs_inode.h:269: parse error before `mrlock_t' replace the four occurance of mrlock_t in that file with xfs_mrlock_t, it's an incomplete commit that hit that CVS tree. From owner-linux-xfs@oss.sgi.com Fri Feb 20 10:18:57 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 10:19:14 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KIIvKO017796 for ; Fri, 20 Feb 2004 10:18:57 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1KIIprK024235 for ; Fri, 20 Feb 2004 12:18:51 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1KIIowZ34417266; Fri, 20 Feb 2004 12:18:50 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AuFEf-0003eS-00; Fri, 20 Feb 2004 12:18:49 -0600 Subject: TAKE 909899 - plug race in pagebuf freeing Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Fri, 20 Feb 2004 12:18:49 -0600 X-archive-position: 2175 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Feb 20 10:18:31 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167222a fs/xfs/linux-2.6/xfs_buf.c - 1.150 - avoid small window where a buffer has pb_hold == 0 but is still on the hash list fs/xfs/linux-2.4/xfs_buf.c - 1.170 - avoid small window where a buffer has pb_hold == 0 but is still on the hash list From owner-linux-xfs@oss.sgi.com Fri Feb 20 11:12:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 11:12:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KJCIKO020891 for ; Fri, 20 Feb 2004 11:12:18 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1KIEGaV026456 for ; Fri, 20 Feb 2004 10:14:17 -0800 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 GAA24640 for ; Sat, 21 Feb 2004 06:12:10 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1KJC98n281726 for ; Sat, 21 Feb 2004 06:12:09 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1KJC8lO307169 for linux-xfs@oss.sgi.com; Sat, 21 Feb 2004 06:12:08 +1100 (EST) Date: Sat, 21 Feb 2004 06:12:07 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Subject: Re: 2.6.3 build failure Message-ID: <20040221061207.A308454@wobbly.melbourne.sgi.com> References: <20040220143452.GA25888@palkovic.org> <20040220145149.A5706@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20040220145149.A5706@infradead.org>; from hch@infradead.org on Fri, Feb 20, 2004 at 02:51:49PM +0000 X-archive-position: 2176 X-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, Feb 20, 2004 at 02:51:49PM +0000, Christoph Hellwig wrote: > On Fri, Feb 20, 2004 at 08:34:52AM -0600, John Palkovic wrote: > > fs/xfs/xfs_inode.h:269: parse error before `mrlock_t' > > replace the four occurance of mrlock_t in that file with xfs_mrlock_t, > it's an incomplete commit that hit that CVS tree. > Yep, sorry - I was testing interaction with other code, and that just slipped in. It should stay mrlock_t everywhere - a cvs pull would pick that up (was a small window yesterday and you got unlucky). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Feb 20 14:18:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 14:18:51 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KMIoKO028466 for ; Fri, 20 Feb 2004 14:18:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1KMIfMd026564 for ; Fri, 20 Feb 2004 14:18:42 -0800 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1KMIQhI12674439; Sat, 21 Feb 2004 09:18:31 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1KMIPWt9327356; Sat, 21 Feb 2004 09:18:25 +1100 (EST) Date: Sat, 21 Feb 2004 09:18:25 +1100 (EST) From: Nathan Scott Message-Id: <200402202218.i1KMIPWt9327356@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 905452 - mrlocks X-archive-position: 2177 X-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 Remove leftovers from testing mrlocks-as-rwsems. Date: Thu Feb 19 21:14:04 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167193a linux-2.6/mrlock.c - 1.18 linux-2.6/mrlock.h - 1.14 Implement mrlocks on top of rwsems, conditionally for 2.4 (needs downgrade_write backport from 2.6) Date: Fri Feb 20 14:16:37 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167264a linux-2.4/mrlock_rwsem.h - 1.1 linux-2.4/mrlock.c - 1.20 linux-2.4/mrlock.h - 1.15 From owner-linux-xfs@oss.sgi.com Fri Feb 20 14:24:56 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 14:24:58 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KMOtKO028910 for ; Fri, 20 Feb 2004 14:24:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1KMOnrK020037 for ; Fri, 20 Feb 2004 16:24:49 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1KMOihI7760050; Sat, 21 Feb 2004 09:24:44 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1KMOh3Y12155962; Sat, 21 Feb 2004 09:24:43 +1100 (EST) Date: Sat, 21 Feb 2004 09:24:43 +1100 (EST) From: Nathan Scott Message-Id: <200402202224.i1KMOh3Y12155962@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 905452 - update 2.4 rwsem code X-archive-position: 2178 X-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 Backport 2.6 rwsem changes, and provide a way to conditionally detect the presence of downgrade_write. Date: Fri Feb 20 14:22:55 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:167265a include/asm-i386/rwsem.h - 1.2 include/asm-ia64/rwsem.h - 1.2 include/linux/rwsem.h - 1.2 lib/rwsem.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Feb 20 15:41:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Feb 2004 15:42:16 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1KNfsKO032222 for ; Fri, 20 Feb 2004 15:41:54 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1KNfmiI011743 for ; Fri, 20 Feb 2004 15:41:49 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1KNflvV34433561; Fri, 20 Feb 2004 17:41:47 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AuKHC-0006nA-00; Fri, 20 Feb 2004 17:41:46 -0600 Subject: TAKE 908809 - kill some dead constants from pagebuf Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Fri, 20 Feb 2004 17:41:46 -0600 X-archive-position: 2179 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Feb 20 15:41:31 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167273a fs/xfs/linux-2.6/xfs_buf.c - 1.151 - kill some dead constants from pagebuf fs/xfs/linux-2.4/xfs_buf.c - 1.171 - kill some dead constants from pagebuf From owner-linux-xfs@oss.sgi.com Sat Feb 21 05:08:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Feb 2004 05:08:49 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1LD8YKO024488 for ; Sat, 21 Feb 2004 05:08:34 -0800 Received: (qmail 8848 invoked by uid 65534); 21 Feb 2004 13:08:27 -0000 Received: from 80-218-8-25.dclient.hispeed.ch (EHLO vaio.gigerstyle.ch) (80.218.8.25) by mail.gmx.net (mp017) with SMTP; 21 Feb 2004 14:08:27 +0100 X-Authenticated: #1226656 Date: Sat, 21 Feb 2004 14:08:26 +0100 From: Marc Giger To: linux-xfs@oss.sgi.com Subject: xfs-acl Message-Id: <20040221140826.1af01558.gigerstyle@gmx.ch> X-Mailer: Sylpheed version 0.9.7claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2180 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: gigerstyle@gmx.ch Precedence: bulk X-list: linux-xfs Hi All, Linux 2.4.25 has now xfs included, but the part for acl's seems not to be included. Will you release a patch for the acl part of xfs or have I to use xfs-2.4.24-pre1-split-acl? Thank you Regards Marc From owner-linux-xfs@oss.sgi.com Sat Feb 21 05:49:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Feb 2004 05:49:53 -0800 (PST) Received: from iris.acsalaska.net (iris.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1LDnjKO025683 for ; Sat, 21 Feb 2004 05:49:45 -0800 Received: from erbenson.alaska.net (14-pm1.nwc.acsalaska.net [209.112.138.14]) by iris.acsalaska.net (8.12.10/8.12.10) with ESMTP id i1LDnhHK045820 for ; Sat, 21 Feb 2004 04:49:43 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 36AF539E6 for ; Sat, 21 Feb 2004 04:49:42 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 817D240FF35; Sat, 21 Feb 2004 04:49:42 -0900 (AKST) Date: Sat, 21 Feb 2004 04:49:42 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfs-acl Message-ID: <20040221134942.GL11765@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040221140826.1af01558.gigerstyle@gmx.ch> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k1BdFSKqAqVdu8k/" Content-Disposition: inline In-Reply-To: <20040221140826.1af01558.gigerstyle@gmx.ch> 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-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.37; SA 2.61; spamdefang 1.93 X-archive-position: 2181 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --k1BdFSKqAqVdu8k/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 21, 2004 at 02:08:26PM +0100, Marc Giger wrote: > Hi All, >=20 > Linux 2.4.25 has now xfs included, but the part for acl's seems not to > be included. Will you release a patch for the > acl part of xfs or have I to use xfs-2.4.24-pre1-split-acl? the -split-acl patch has not changed in the last many 2.4 patchsets, and should continue to work with 2.4.25 and beyond. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --k1BdFSKqAqVdu8k/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkA3YfYACgkQJKx7GixEevyfmgCghwJMylSzl1apsHXgve2egsPu jLwAoJrjA0VQqSzV3gxbVu2Fknpam2pJ =xBXg -----END PGP SIGNATURE----- --k1BdFSKqAqVdu8k/-- From owner-linux-xfs@oss.sgi.com Sun Feb 22 06:34:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Feb 2004 06:34:51 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1MEYZKO005207 for ; Sun, 22 Feb 2004 06:34:35 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1MDUQF9002922 for ; Sun, 22 Feb 2004 05:30:26 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1MESMET34475066 for ; Sun, 22 Feb 2004 08:28:22 -0600 (CST) Received: from sgi.com (penguin.americas.sgi.com [128.162.240.135]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1MESLfl3350448; Sun, 22 Feb 2004 08:28:21 -0600 (CST) Received: from penguin.americas.sgi.com (localhost.localdomain [127.0.0.1]) by sgi.com (8.12.8/8.12.8) with ESMTP id i1L2TNxs016601; Fri, 20 Feb 2004 20:30:19 -0600 Received: (from sandeen@localhost) by penguin.americas.sgi.com (8.12.8/8.12.8/Submit) id i1L2TN9g016599; Fri, 20 Feb 2004 20:29:23 -0600 Date: Fri, 20 Feb 2004 20:29:23 -0600 From: Eric Sandeen Message-Id: <200402210229.i1L2TN9g016599@penguin.americas.sgi.com> Subject: PARTIAL TAKE 909954 - remove dead code X-archive-position: 2182 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@penguin.americas.sgi.com Precedence: bulk X-list: linux-xfs Remove some dead debug code Date: Fri Feb 20 18:28:42 PST 2004 Workarea: penguin.americas.sgi.com:/src/eric/linux-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167279a fs/xfs/xfs_alloc.c - 1.170 - remove seed calculation, not used From owner-linux-xfs@oss.sgi.com Sun Feb 22 10:17:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Feb 2004 10:17:23 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1MIHDKO010392 for ; Sun, 22 Feb 2004 10:17:20 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i1MIGuG9426946; Sun, 22 Feb 2004 13:16:56 -0500 Received: from sig-9-65-54-141.mts.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i1MIGshj133998; Sun, 22 Feb 2004 13:16:55 -0500 Subject: Re: DMAPI test suite. From: Ram Pai To: Steve Lord Cc: Dean Roehrich , linux-xfs@oss.sgi.com In-Reply-To: <40360FC8.4060405@xfs.org> References: <200402181519.i1IFJS9i11055016@clink.americas.sgi.com> <1077265286.7503.37.camel@dyn319009bld.beaverton.ibm.com> <40360FC8.4060405@xfs.org> Content-Type: text/plain Organization: Message-Id: <1077473812.2822.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 22 Feb 2004 10:16:52 -0800 Content-Transfer-Encoding: 7bit X-archive-position: 2183 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: linuxram@us.ibm.com Precedence: bulk X-list: linux-xfs On Fri, 2004-02-20 at 05:46, Steve Lord wrote: > Ram Pai wrote: > > On Wed, 2004-02-18 at 07:19, Dean Roehrich wrote: > > > >>It probably needs to be upgraded to the latest autotools. It's a bit old. > >> > >>I don't have an rpm for the binaries. > > > > > > Ok. I am not able to run this test suite. In any case, I want to > > validate the behavior of XFS for pre-unmount event. > > > > As per the spec the pre-unmount event should be generated before the > > operation is about to check for open files. However given the current > > VFS code I am not sure, how could ever any filesystem support this > > feature correctly. > > You are probably correct here, the vfs keeps track of the busy count > and apart from the unmount_begin operation which is called in the > MNT_FORCE case, there is not a lot of opportunity to insert this > call. If the pre-unmount event is allowed to fail the unmount > then this will not work either since it does not stop the unmount. > > > > The VFS code may not even inform the filesystem specific unmount handler > > in some cases. As a result no filesystem can ever support this feature > > correctly. Is my understanding correct? Does XFS provide the > > pre-unmount event correctly? > > > > There is a pre_unmount event in xfs, it is after the vfs has cleaned > up all the inodes (in the put_super code), Looking through the xfs dmapi code, 2 questions pop up: 1. How can the pre_unmount event, when generated through the put_super() code provide the DM_UNMOUNT_FORCE information. There is now way for the put_super() code to know if the unmount is a forceful one or not. 2. And finally I find that all the DMAPI event generators are stubbed to fs_nosys or fs_noerr or fs_noval . So does XFS ever generate DM events ? RP > if it returns an error > then the vfs will still finish the unmount, and you may well get one > of those self destruct in 5 seconds messages. > > > Any ideas? > > RP > > Al Viro is distinctly anti dmapi, so chances are slim to none I would > say. hmm...that makes it difficult. Is he against Dmapi implemented in VFS or against the overall idea of supporting DMAPI anywhere in linux? I hope he is just against DMAPI implemented at the VFS level and is ok with supporting filesystems to implement it. RP From owner-linux-xfs@oss.sgi.com Sun Feb 22 10:22:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Feb 2004 10:22:22 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1MIMJKO010784 for ; Sun, 22 Feb 2004 10:22:20 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AuyEz-0000As-MT; Sun, 22 Feb 2004 18:22:09 +0000 Date: Sun, 22 Feb 2004 18:22:09 +0000 From: Christoph Hellwig To: Ram Pai Cc: Steve Lord , Dean Roehrich , linux-xfs@oss.sgi.com Subject: Re: DMAPI test suite. Message-ID: <20040222182209.A642@infradead.org> References: <200402181519.i1IFJS9i11055016@clink.americas.sgi.com> <1077265286.7503.37.camel@dyn319009bld.beaverton.ibm.com> <40360FC8.4060405@xfs.org> <1077473812.2822.32.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1077473812.2822.32.camel@localhost.localdomain>; from linuxram@us.ibm.com on Sun, Feb 22, 2004 at 10:16:52AM -0800 X-archive-position: 2184 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sun, Feb 22, 2004 at 10:16:52AM -0800, Ram Pai wrote: > Looking through the xfs dmapi code, 2 questions pop up: > 1. How can the pre_unmount event, when generated through the put_super() > code provide the DM_UNMOUNT_FORCE information. There is now way for the > put_super() code to know if the unmount is a forceful one or not. It can't. > 2. And finally I find that all the DMAPI event generators are stubbed > to fs_nosys or fs_noerr or fs_noval . So does XFS ever generate DM > events ? You need to load the xfs_dmapi module to get an implementation. It's in the CVS repository at oss.sgi.com. > > Al Viro is distinctly anti dmapi, so chances are slim to none I would > > say. > > hmm...that makes it difficult. Is he against Dmapi implemented in VFS or > against the overall idea of supporting DMAPI anywhere in linux? I hope > he is just against DMAPI implemented at the VFS level and is ok with > supporting filesystems to implement it. DMAPI is an extremly broken specification, it fits hardly into an unix enviroment and not into Linux at all. SGI tries to provide a best-fit dmapi implementation anyways, but it's just not something that should go into an mainline kernel. If you want to see HSM support in a kernel.org kernel start by designing a saner specification than dmapi. From owner-linux-xfs@oss.sgi.com Sun Feb 22 15:28:47 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Feb 2004 15:29:04 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1MNSlKO019718 for ; Sun, 22 Feb 2004 15:28:47 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1MNSTF6018284 for ; Sun, 22 Feb 2004 15:28:29 -0800 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 KAA23010; Mon, 23 Feb 2004 10:28:26 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1MNSP8n377786; Mon, 23 Feb 2004 10:28:25 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1MNRXQ1003227; Mon, 23 Feb 2004 10:27:33 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1MNRUCY003225; Mon, 23 Feb 2004 10:27:30 +1100 Date: Mon, 23 Feb 2004 10:27:30 +1100 From: Nathan Scott To: Kostadin Karaivanov Cc: linux-xfs@oss.sgi.com Subject: Re: xfs-progs and libtool-1.5.2 issues Message-ID: <20040222232730.GA3213@frodo> References: <4034E1C9.9050103@tamiweb.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <4034E1C9.9050103@tamiweb.com> User-Agent: Mutt/1.5.3i X-archive-position: 2185 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 19, 2004 at 06:18:17PM +0200, Kostadin Karaivanov wrote: > Recently I upgarded my libtool to 1.5.2 (slackware-current) > nad I'm n unable to compile xfs-cms anymore > following error is excerpt from > make in xfs-cmds/attr > > make -C . default > make[1]: Entering directory `/usr/src/xfs-cmds/attr' > === include === > rm -f attr > ln -s . attr > === libmisc === > /usr/bin/libtool --mode=compile gcc -g -DDEBUG -funsigned-char -Wall > -I../include -DVERSION=\"2.4.15\" -DLOCALEDIR=\"/usr/share/locale\" > -DPACKAGE=\"attr\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT > -fno-strict-aliasing -c quote.c > libtool: compile: unable to infer tagged configuration > libtool: compile: specify a tag with `--tag' > make[2]: *** [quote.lo] Error 1 > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/usr/src/xfs-cmds/attr' > make: *** [default] Error 2 > I have libtool 1.5.2 (Debian unstable), and it works fine here. The libtool script is a bit of a rats nest, but from a quick read it looks like you may have CC set to something other than what libtool thinks the base compiler is..? You may be able to find out more by running "sh -x libtool ..." from within the Makefiles and then seeing where it gets confused. If you have a working libtool script, might be easier to diff it with your current version... (I've attached my /usr/bin/libtool - is it any different to yours?) cheers. -- Nathan --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=libtool Content-Transfer-Encoding: quoted-printable #! /bin/sh # libtoolT - Provide generalized library-building support services. # Generated automatically by (GNU libtool 1.5.2) # NOTE: Changes made to this file will be lost: look at ltmain.sh. # # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001 # Free Software Foundation, Inc. # # This file is part of GNU Libtool: # Originally by Gordon Matzigkeit , 1996 # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. # A sed program that does not truncate output. SED=3D"/bin/sed" # Sed that helps us avoid accidentally triggering echo(1) options like -n. Xsed=3D"/bin/sed -e s/^X//" # The HP-UX ksh and POSIX shell print the target directory to stdout # if CDPATH is set. if test "X${CDPATH+set}" =3D Xset; then CDPATH=3D:; export CDPATH; fi # The names of the tagged configurations supported by this script. available_tags=3D" CXX F77 GCJ BINCC BINCXX" # ### BEGIN LIBTOOL CONFIG # Libtool was configured on host descent.netsplit.com: # Shell to use when invoking shell scripts. SHELL=3D"/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=3Dyes # Whether or not to build static libraries. build_old_libs=3Dyes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=3Dno # Whether or not to disallow shared libs when runtime libs are static allow_libtool_libs_with_static_runtimes=3Dno # Whether or not to optimize for fast installation. fast_install=3Dyes # The host system. host_alias=3D host=3Di386-pc-linux-gnu # An echo program that does not interpret backslashes. echo=3D"echo" # The archiver. AR=3D"ar" AR_FLAGS=3D"cru" # A C compiler. LTCC=3D"gcc" # A language-specific compiler. CC=3D"gcc" # Is the compiler the GNU C compiler? with_gcc=3Dyes # An ERE matcher. EGREP=3D"grep -E" # The linker used to build libraries. LD=3D"/usr/bin/ld" # Whether we need hard or soft links. LN_S=3D"ln -s" # A BSD-compatible nm program. NM=3D"/usr/bin/nm -B" # A symbol stripping program STRIP=3D"strip" # Used to examine libraries when file_magic_cmd begins "file" MAGIC_CMD=3Dfile # Used on cygwin: DLL creation program. DLLTOOL=3D"dlltool" # Used on cygwin: object dumper. OBJDUMP=3D"objdump" # Used on cygwin: assembler. AS=3D"as" # The name of the directory that contains temporary libtool files. objdir=3D.libs # How to create reloadable object files. reload_flag=3D" -r" reload_cmds=3D"\$LD\$reload_flag -o \$output\$reload_objs" # How to pass a linker flag through the compiler. wl=3D"-Wl," # Object file suffix (normally "o"). objext=3D"o" # Old archive suffix (normally "a"). libext=3D"a" # Shared library suffix (normally ".so"). shrext=3D'.so' # Executable file suffix (normally ""). exeext=3D"" # Additional compiler flags for building library objects. pic_flag=3D" -fPIC -DPIC" pic_mode=3Ddefault # What is the maximum length of a command? max_cmd_len=3D32768 # Does compiler simultaneously support -c and -o options? compiler_c_o=3D"yes" # Must we lock files when doing compilation ? need_locks=3D"no" # Do we need the lib prefix for modules? need_lib_prefix=3Dno # Do we need a version for libraries? need_version=3Dno # Whether dlopen is supported. dlopen_support=3Dyes # Whether dlopen of programs is supported. dlopen_self=3Dyes # Whether dlopen of statically linked programs is supported. dlopen_self_static=3Dyes # Compiler flag to prevent dynamic linking. link_static_flag=3D"-static" # Compiler flag to turn off builtin functions. no_builtin_flag=3D" -fno-builtin" # Compiler flag to allow reflexive dlopens. export_dynamic_flag_spec=3D"\${wl}--export-dynamic" # Compiler flag to generate shared objects directly from archives. whole_archive_flag_spec=3D"\${wl}--whole-archive\$convenience \${wl}--no-wh= ole-archive" # Compiler flag to generate thread-safe objects. thread_safe_flag_spec=3D"" # Library versioning type. version_type=3Dlinux # Format of library name prefix. libname_spec=3D"lib\$name" # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. library_names_spec=3D"\${libname}\${release}\${shared_ext}\$versuffix \${li= bname}\${release}\${shared_ext}\$major \$libname\${shared_ext}" # The coded name of the library, if different from the real name. soname_spec=3D"\${libname}\${release}\${shared_ext}\$major" # Commands used to build and install an old-style archive. RANLIB=3D"ranlib" old_archive_cmds=3D"\$AR \$AR_FLAGS \$oldlib\$oldobjs\$old_deplibs~\$RANLIB= \$oldlib" old_postinstall_cmds=3D"\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds=3D"" # Create an old-style archive from a shared archive. old_archive_from_new_cmds=3D"" # Create a temporary old-style archive to link instead of a shared archive. old_archive_from_expsyms_cmds=3D"" # Commands used to build and install a shared archive. archive_cmds=3D"\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-so= name \$wl\$soname -o \$lib" archive_expsym_cmds=3D"\$echo \\\"{ global:\\\" > \$output_objdir/\$libname= =2Ever~ cat \$export_symbols | sed -e \\\"s/\\\\(.*\\\\)/\\\\1;/\\\" >> \$output_ob= jdir/\$libname.ver~ \$echo \\\"local: *; };\\\" >> \$output_objdir/\$libname.ver~ \$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname \$w= l\$soname \${wl}-version-script \${wl}\$output_objdir/\$libname.ver -o \$li= b" postinstall_cmds=3D"" postuninstall_cmds=3D"" # Commands used to build a loadable module (assumed same as above if empty) module_cmds=3D"" module_expsym_cmds=3D"" # Commands to strip libraries. old_striplib=3D"strip --strip-debug" striplib=3D"strip --strip-unneeded" # Dependencies to place before the objects being linked to create a # shared library. predep_objects=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdep_objects=3D"" # Dependencies to place before the objects being linked to create a # shared library. predeps=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdeps=3D"" # The library search path used internally by the compiler when linking # a shared library. compiler_lib_search_path=3D"" # Method to check whether dependent libraries are shared objects. deplibs_check_method=3D"pass_all" # Command to use when deplibs_check_method =3D=3D file_magic. file_magic_cmd=3D"\$MAGIC_CMD" # Flag that allows shared libraries with undefined symbols to be built. allow_undefined_flag=3D"" # Flag that forces no undefined symbols. no_undefined_flag=3D"" # Commands used to finish a libtool library installation in a directory. finish_cmds=3D"PATH=3D\\\"\\\$PATH:/sbin\\\" ldconfig -n \$libdir" # Same as above, but a single script fragment to be evaled but not shown. finish_eval=3D"" # Take the output of nm and produce a listing of raw symbols and C names. global_symbol_pipe=3D"sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ = ][ ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2\\3 \\3/p'" # Transform the output of nm in a proper C declaration global_symbol_to_cdecl=3D"sed -n -e 's/^. .* \\(.*\\)\$/extern int \\1;/p'" # Transform the output of nm in a C name address pair global_symbol_to_c_name_address=3D"sed -n -e 's/^: \\([^ ]*\\) \$/ {\\\"\\= 1\\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2= \", (lt_ptr) \\&\\2},/p'" # This is the shared library runtime path variable. runpath_var=3DLD_RUN_PATH # This is the shared library path variable. shlibpath_var=3DLD_LIBRARY_PATH # Is shlibpath searched before the hard-coded library search path? shlibpath_overrides_runpath=3Dno # How to hardcode a shared library path into an executable. hardcode_action=3Dimmediate # Whether we should hardcode library paths into libraries. hardcode_into_libs=3Dyes # Flag to hardcode $libdir into a binary during linking. # This must work even if $libdir does not exist. hardcode_libdir_flag_spec=3D"\${wl}--rpath \${wl}\$libdir" # If ld is used when linking, flag to hardcode $libdir into # a binary during linking. This must work even if $libdir does # not exist. hardcode_libdir_flag_spec_ld=3D"" # Whether we need a single -rpath flag with a separated argument. hardcode_libdir_separator=3D"" # Set to yes if using DIR/libNAME during linking hardcodes DIR into the # resulting binary. hardcode_direct=3Dno # Set to yes if using the -LDIR flag during linking hardcodes DIR into the # resulting binary. hardcode_minus_L=3Dno # Set to yes if using SHLIBPATH_VAR=3DDIR during linking hardcodes DIR into # the resulting binary. hardcode_shlibpath_var=3Dunsupported # Set to yes if building a shared library automatically hardcodes DIR into = the library # and all subsequent libraries and executables linked against it. hardcode_automatic=3Dno # Variables whose values should be saved in libtool wrapper scripts and # restored at relink time. variables_saved_for_relink=3D"PATH LD_RUN_PATH GCC_EXEC_PREFIX COMPILER_PA= TH LIBRARY_PATH" # Whether libtool must link a program against all its dependency libraries. link_all_deplibs=3Dunknown # Compile-time system search path for libraries sys_lib_search_path_spec=3D"/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib/" # Run-time system search path for libraries sys_lib_dlsearch_path_spec=3D"/lib /usr/lib /usr/X11R6/lib" # Fix the shell variable $srcfile for the compiler. fix_srcfile_path=3D"" # Set to yes if exported symbols are required. always_export_symbols=3Dno # The commands to list exported symbols. export_symbols_cmds=3D"\$NM \$libobjs \$convenience | \$global_symbol_pipe = | \$SED 's/.* //' | sort | uniq > \$export_symbols" # The commands to extract the exported symbol list from a shared archive. extract_expsyms_cmds=3D"" # Symbols that should not be listed in the preloaded symbols. exclude_expsyms=3D"_GLOBAL_OFFSET_TABLE_" # Symbols that must always be exported. include_expsyms=3D"" # ### END LIBTOOL CONFIG # ltmain.sh - Provide generalized library-building support services. # NOTE: Changing this file will not affect anything until you rerun configu= re. # # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003 # Free Software Foundation, Inc. # Originally by Gordon Matzigkeit , 1996 # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. # # As a special exception to the GNU General Public License, if you # distribute this file as part of a program that contains a # configuration script generated by Autoconf, you may include it under # the same distribution terms that you use for the rest of that program. # Check that we have a working $echo. if test "X$1" =3D X--no-reexec; then # Discard the --no-reexec flag, and continue. shift elif test "X$1" =3D X--fallback-echo; then # Avoid inline document here, it may be left over : elif test "X`($echo '\t') 2>/dev/null`" =3D 'X\t'; then # Yippee, $echo works! : else # Restart under the correct shell, and then maybe $echo will work. exec $SHELL "$0" --no-reexec ${1+"$@"} fi if test "X$1" =3D X--fallback-echo; then # used as fallback echo shift cat <&2 $echo "Fatal configuration error. See the $PACKAGE docs for more informa= tion." 1>&2 exit 1 fi # Global variables. mode=3D$default_mode nonopt=3D prev=3D prevopt=3D run=3D show=3D"$echo" show_help=3D execute_dlfiles=3D lo2o=3D"s/\\.lo\$/.${objext}/" o2lo=3D"s/\\.${objext}\$/.lo/" ##################################### # Shell function definitions: # This seems to be the best place for them # Need a lot of goo to handle *both* DLLs and import libs # Has to be a shell function in order to 'eat' the argument # that is supplied when $file_magic_command is called. win32_libid () { win32_libid_type=3D"unknown" win32_fileres=3D`file -L $1 2>/dev/null` case $win32_fileres in *ar\ archive\ import\ library*) # definitely import win32_libid_type=3D"x86 archive import" ;; *ar\ archive*) # could be an import, or static if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | \ grep -E 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then win32_nmres=3D`eval $NM -f posix -A $1 | \ sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'` if test "X$win32_nmres" =3D "Ximport" ; then win32_libid_type=3D"x86 archive import" else win32_libid_type=3D"x86 archive static" fi fi ;; *DLL*)=20 win32_libid_type=3D"x86 DLL" ;; *executable*) # but shell scripts are "executable" too... case $win32_fileres in *MS\ Windows\ PE\ Intel*) win32_libid_type=3D"x86 DLL" ;; esac ;; esac $echo $win32_libid_type } # End of Shell function definitions ##################################### # Parse our command line options once, thoroughly. while test "$#" -gt 0 do arg=3D"$1" shift case $arg in -*=3D*) optarg=3D`$echo "X$arg" | $Xsed -e 's/[-_a-zA-Z0-9]*=3D//'` ;; *) optarg=3D ;; esac # If the previous option needs an argument, assign it. if test -n "$prev"; then case $prev in execute_dlfiles) execute_dlfiles=3D"$execute_dlfiles $arg" ;; tag) tagname=3D"$arg" preserve_args=3D"${preserve_args}=3D$arg" # Check whether tagname contains only valid characters case $tagname in *[!-_A-Za-z0-9,/]*) $echo "$progname: invalid tag name: $tagname" 1>&2 exit 1 ;; esac case $tagname in CC) # Don't test for the "default" C tag, as we know, it's there, but # not specially marked. ;; *) if grep "^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$" < "$0" > /dev/null; t= hen taglist=3D"$taglist $tagname" # Evaluate the configuration. eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$tagname'$/,/^# = ### END LIBTOOL TAG CONFIG: '$tagname'$/p' < $0`" else $echo "$progname: ignoring unknown tag $tagname" 1>&2 fi ;; esac ;; *) eval "$prev=3D\$arg" ;; esac prev=3D prevopt=3D continue fi # Have we seen a non-optional argument yet? case $arg in --help) show_help=3Dyes ;; --version) $echo "$PROGRAM (GNU $PACKAGE) $VERSION$TIMESTAMP" $echo $echo "Copyright (C) 2003 Free Software Foundation, Inc." $echo "This is free software; see the source for copying conditions. T= here is NO" $echo "warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICUL= AR PURPOSE." exit 0 ;; --config) ${SED} -e '1,/^# ### BEGIN LIBTOOL CONFIG/d' -e '/^# ### END LIBTOOL CO= NFIG/,$d' $0 # Now print the configurations for the tags. for tagname in $taglist; do ${SED} -n -e "/^# ### BEGIN LIBTOOL TAG CONFIG: $tagname$/,/^# ### EN= D LIBTOOL TAG CONFIG: $tagname$/p" < "$0" done exit 0 ;; --debug) $echo "$progname: enabling shell trace mode" set -x preserve_args=3D"$preserve_args $arg" ;; --dry-run | -n) run=3D: ;; --features) $echo "host: $host" if test "$build_libtool_libs" =3D yes; then $echo "enable shared libraries" else $echo "disable shared libraries" fi if test "$build_old_libs" =3D yes; then $echo "enable static libraries" else $echo "disable static libraries" fi exit 0 ;; --finish) mode=3D"finish" ;; --mode) prevopt=3D"--mode" prev=3Dmode ;; --mode=3D*) mode=3D"$optarg" ;; --preserve-dup-deps) duplicate_deps=3D"yes" ;; --quiet | --silent) show=3D: preserve_args=3D"$preserve_args $arg" ;; --tag) prevopt=3D"--tag" prev=3Dtag ;; --tag=3D*) set tag "$optarg" ${1+"$@"} shift prev=3Dtag preserve_args=3D"$preserve_args --tag" ;; -dlopen) prevopt=3D"-dlopen" prev=3Dexecute_dlfiles ;; -*) $echo "$modename: unrecognized option \`$arg'" 1>&2 $echo "$help" 1>&2 exit 1 ;; *) nonopt=3D"$arg" break ;; esac done if test -n "$prevopt"; then $echo "$modename: option \`$prevopt' requires an argument" 1>&2 $echo "$help" 1>&2 exit 1 fi # If this variable is set in any of the actions, the command in it # will be execed at the end. This prevents here-documents from being # left over by shells. exec_cmd=3D if test -z "$show_help"; then # Infer the operation mode. if test -z "$mode"; then $echo "*** Warning: inferring the mode of operation is deprecated." 1>&2 $echo "*** Future versions of Libtool will require -mode=3DMODE be spec= ified." 1>&2 case $nonopt in *cc | cc* | *++ | gcc* | *-gcc* | g++* | xlc*) mode=3Dlink for arg do case $arg in -c) mode=3Dcompile break ;; esac done ;; *db | *dbx | *strace | *truss) mode=3Dexecute ;; *install*|cp|mv) mode=3Dinstall ;; *rm) mode=3Duninstall ;; *) # If we have no mode, but dlfiles were specified, then do execute mod= e. test -n "$execute_dlfiles" && mode=3Dexecute # Just use the default operation mode. if test -z "$mode"; then if test -n "$nonopt"; then $echo "$modename: warning: cannot infer operation mode from \`$nonopt'" = 1>&2 else $echo "$modename: warning: cannot infer operation mode without MODE-ARGS= " 1>&2 fi fi ;; esac fi # Only execute mode is allowed to have -dlopen flags. if test -n "$execute_dlfiles" && test "$mode" !=3D execute; then $echo "$modename: unrecognized option \`-dlopen'" 1>&2 $echo "$help" 1>&2 exit 1 fi # Change the help message to a mode-specific one. generic_help=3D"$help" help=3D"Try \`$modename --help --mode=3D$mode' for more information." # These modes are in order of execution frequency so that they run quickl= y. case $mode in # libtool compile mode compile) modename=3D"$modename: compile" # Get the compilation command and the source file. base_compile=3D srcfile=3D"$nonopt" # always keep a non-empty value in "srcfile" suppress_opt=3Dyes suppress_output=3D arg_mode=3Dnormal libobj=3D later=3D for arg do case "$arg_mode" in arg ) # do not "continue". Instead, add this to base_compile lastarg=3D"$arg" arg_mode=3Dnormal ;; target ) libobj=3D"$arg" arg_mode=3Dnormal continue ;; normal ) # Accept any command-line options. case $arg in -o) if test -n "$libobj" ; then $echo "$modename: you cannot specify \`-o' more than once" 1>&2 exit 1 fi arg_mode=3Dtarget continue ;; -static | -prefer-pic | -prefer-non-pic) later=3D"$later $arg" continue ;; -no-suppress) suppress_opt=3Dno continue ;; -Xcompiler) arg_mode=3Darg # the next one goes into the "base_compile" arg list continue # The current "srcfile" will either be retained or ;; # replaced later. I would guess that would be a bug. -Wc,*) args=3D`$echo "X$arg" | $Xsed -e "s/^-Wc,//"` lastarg=3D save_ifs=3D"$IFS"; IFS=3D',' for arg in $args; do IFS=3D"$save_ifs" # Double-quote args containing other shell metacharacters. # Many Bourne shells cannot handle close brackets correctly # in scan sets, so we specify it separately. case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") arg=3D"\"$arg\"" ;; esac lastarg=3D"$lastarg $arg" done IFS=3D"$save_ifs" lastarg=3D`$echo "X$lastarg" | $Xsed -e "s/^ //"` # Add the arguments to base_compile. base_compile=3D"$base_compile $lastarg" continue ;; * ) # Accept the current argument as the source file. # The previous "srcfile" becomes the current argument. # lastarg=3D"$srcfile" srcfile=3D"$arg" ;; esac # case $arg ;; esac # case $arg_mode # Aesthetically quote the previous argument. lastarg=3D`$echo "X$lastarg" | $Xsed -e "$sed_quote_subst"` case $lastarg in # Double-quote args containing other shell metacharacters. # Many Bourne shells cannot handle close brackets correctly # in scan sets, so we specify it separately. *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") lastarg=3D"\"$lastarg\"" ;; esac base_compile=3D"$base_compile $lastarg" done # for arg case $arg_mode in arg) $echo "$modename: you must specify an argument for -Xcompile" exit 1 ;; target) $echo "$modename: you must specify a target with \`-o'" 1>&2 exit 1 ;; *) # Get the name of the library object. [ -z "$libobj" ] && libobj=3D`$echo "X$srcfile" | $Xsed -e 's%^.*/%%'` ;; esac # Recognize several different file suffixes. # If the user specifies -o file.o, it is replaced with file.lo xform=3D'[cCFSifmso]' case $libobj in *.ada) xform=3Dada ;; *.adb) xform=3Dadb ;; *.ads) xform=3Dads ;; *.asm) xform=3Dasm ;; *.c++) xform=3Dc++ ;; *.cc) xform=3Dcc ;; *.ii) xform=3Dii ;; *.class) xform=3Dclass ;; *.cpp) xform=3Dcpp ;; *.cxx) xform=3Dcxx ;; *.f90) xform=3Df90 ;; *.for) xform=3Dfor ;; *.java) xform=3Djava ;; esac libobj=3D`$echo "X$libobj" | $Xsed -e "s/\.$xform$/.lo/"` case $libobj in *.lo) obj=3D`$echo "X$libobj" | $Xsed -e "$lo2o"` ;; *) $echo "$modename: cannot determine name of library object from \`$lib= obj'" 1>&2 exit 1 ;; esac # Infer tagged configuration to use if any are available and # if one wasn't chosen via the "--tag" command line option. # Only attempt this if the compiler in the base compile # command doesn't match the default compiler. if test -n "$available_tags" && test -z "$tagname"; then case $base_compile in # Blanks in the command may have been stripped by the calling shell, # but not from the CC environment variable when configure was run. " $CC "* | "$CC "* | " `$echo $CC` "* | "`$echo $CC` "*) ;; # Blanks at the start of $base_compile will cause this to fail # if we don't check for them as well. *) for z in $available_tags; do if grep "^# ### BEGIN LIBTOOL TAG CONFIG: $z$" < "$0" > /dev/null; then # Evaluate the configuration. eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### = END LIBTOOL TAG CONFIG: '$z'$/p' < $0`" case "$base_compile " in "$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*) # The compiler in the base compile command matches # the one in the tagged configuration. # Assume this is the tagged configuration we want. tagname=3D$z break ;; esac fi done # If $tagname still isn't set, then no tagged configuration # was found and let the user know that the "--tag" command # line option must be used. if test -z "$tagname"; then $echo "$modename: unable to infer tagged configuration" $echo "$modename: specify a tag with \`--tag'" 1>&2 exit 1 # else # $echo "$modename: using $tagname tagged configuration" fi ;; esac fi for arg in $later; do case $arg in -static) build_old_libs=3Dyes continue ;; -prefer-pic) pic_mode=3Dyes continue ;; -prefer-non-pic) pic_mode=3Dno continue ;; esac done objname=3D`$echo "X$obj" | $Xsed -e 's%^.*/%%'` xdir=3D`$echo "X$obj" | $Xsed -e 's%/[^/]*$%%'` if test "X$xdir" =3D "X$obj"; then xdir=3D else xdir=3D$xdir/ fi lobj=3D${xdir}$objdir/$objname if test -z "$base_compile"; then $echo "$modename: you must specify a compilation command" 1>&2 $echo "$help" 1>&2 exit 1 fi # Delete any leftover library objects. if test "$build_old_libs" =3D yes; then removelist=3D"$obj $lobj $libobj ${libobj}T" else removelist=3D"$lobj $libobj ${libobj}T" fi $run $rm $removelist trap "$run $rm $removelist; exit 1" 1 2 15 # On Cygwin there's no "real" PIC flag so we must build both object typ= es case $host_os in cygwin* | mingw* | pw32* | os2*) pic_mode=3Ddefault ;; esac if test "$pic_mode" =3D no && test "$deplibs_check_method" !=3D pass_al= l; then # non-PIC code in shared libraries is not supported pic_mode=3Ddefault fi # Calculate the filename of the output object if compiler does # not support -o with -c if test "$compiler_c_o" =3D no; then output_obj=3D`$echo "X$srcfile" | $Xsed -e 's%^.*/%%' -e 's%\.[^.]*$%= %'`.${objext} lockfile=3D"$output_obj.lock" removelist=3D"$removelist $output_obj $lockfile" trap "$run $rm $removelist; exit 1" 1 2 15 else output_obj=3D need_locks=3Dno lockfile=3D fi # Lock this critical section if it is needed # We use this script file to make the link, it avoids creating a new fi= le if test "$need_locks" =3D yes; then until $run ln "$0" "$lockfile" 2>/dev/null; do $show "Waiting for $lockfile to be removed" sleep 2 done elif test "$need_locks" =3D warn; then if test -f "$lockfile"; then $echo "\ *** ERROR, $lockfile exists and contains: `cat $lockfile 2>/dev/null` This indicates that another process is trying to use the same temporary object file, and libtool could not work around it because your compiler does not support \`-c' and \`-o' together. If you repeat this compilation, it may succeed, by chance, but you had better avoid parallel builds (make -j) in this platform, or get a better compiler." $run $rm $removelist exit 1 fi $echo $srcfile > "$lockfile" fi if test -n "$fix_srcfile_path"; then eval srcfile=3D\"$fix_srcfile_path\" fi $run $rm "$libobj" "${libobj}T" # Create a libtool object file (analogous to a ".la" file), # but don't create it if we're doing a dry run. test -z "$run" && cat > ${libobj}T </dev/null`" !=3D "X$srcfile"; then $echo "\ *** ERROR, $lockfile contains: `cat $lockfile 2>/dev/null` but it should contain: $srcfile This indicates that another process is trying to use the same temporary object file, and libtool could not work around it because your compiler does not support \`-c' and \`-o' together. If you repeat this compilation, it may succeed, by chance, but you had better avoid parallel builds (make -j) in this platform, or get a better compiler." $run $rm $removelist exit 1 fi # Just move the object if needed, then go on to compile the next one if test -n "$output_obj" && test "X$output_obj" !=3D "X$lobj"; then $show "$mv $output_obj $lobj" if $run $mv $output_obj $lobj; then : else error=3D$? $run $rm $removelist exit $error fi fi # Append the name of the PIC object to the libtool object file. test -z "$run" && cat >> ${libobj}T </dev/null 2>&1' fi else # No PIC object so indicate it doesn't exist in the libtool # object file. test -z "$run" && cat >> ${libobj}T </dev/null`" !=3D "X$srcfile"; then $echo "\ *** ERROR, $lockfile contains: `cat $lockfile 2>/dev/null` but it should contain: $srcfile This indicates that another process is trying to use the same temporary object file, and libtool could not work around it because your compiler does not support \`-c' and \`-o' together. If you repeat this compilation, it may succeed, by chance, but you had better avoid parallel builds (make -j) in this platform, or get a better compiler." $run $rm $removelist exit 1 fi # Just move the object if needed if test -n "$output_obj" && test "X$output_obj" !=3D "X$obj"; then $show "$mv $output_obj $obj" if $run $mv $output_obj $obj; then : else error=3D$? $run $rm $removelist exit $error fi fi # Append the name of the non-PIC object the libtool object file. # Only append if the libtool object file exists. test -z "$run" && cat >> ${libobj}T <> ${libobj}T < /dev/null; then # Evaluate the configuration. eval "`${SED} -n -e '/^# ### BEGIN LIBTOOL TAG CONFIG: '$z'$/,/^# ### = END LIBTOOL TAG CONFIG: '$z'$/p' < $0`" case $base_compile in "$CC "* | " $CC "* | "`$echo $CC` "* | " `$echo $CC` "*) # The compiler in $compile_command matches # the one in the tagged configuration. # Assume this is the tagged configuration we want. tagname=3D$z break ;; esac fi done # If $tagname still isn't set, then no tagged configuration # was found and let the user know that the "--tag" command # line option must be used. if test -z "$tagname"; then $echo "$modename: unable to infer tagged configuration" $echo "$modename: specify a tag with \`--tag'" 1>&2 exit 1 # else # $echo "$modename: using $tagname tagged configuration" fi ;; esac fi # We need to know -static, to get the right output filenames. for arg do case $arg in -all-static | -static) if test "X$arg" =3D "X-all-static"; then if test "$build_libtool_libs" =3D yes && test -z "$link_static_flag"; th= en $echo "$modename: warning: complete static linking is impossible in th= is configuration" 1>&2 fi if test -n "$link_static_flag"; then dlopen_self=3D$dlopen_self_static fi else if test -z "$pic_flag" && test -n "$link_static_flag"; then dlopen_self=3D$dlopen_self_static fi fi build_libtool_libs=3Dno build_old_libs=3Dyes prefer_static_libs=3Dyes break ;; esac done # See if our shared archives depend on static archives. test -n "$old_archive_from_new_cmds" && build_old_libs=3Dyes # Go through the arguments, transforming them on the way. while test "$#" -gt 0; do arg=3D"$1" shift case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") qarg=3D\"`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`\" ### testsuite: sk= ip nested quoting test ;; *) qarg=3D$arg ;; esac libtool_args=3D"$libtool_args $qarg" # If the previous option needs an argument, assign it. if test -n "$prev"; then case $prev in output) compile_command=3D"$compile_command @OUTPUT@" finalize_command=3D"$finalize_command @OUTPUT@" ;; esac case $prev in dlfiles|dlprefiles) if test "$preload" =3D no; then # Add the symbol object into the linking commands. compile_command=3D"$compile_command @SYMFILE@" finalize_command=3D"$finalize_command @SYMFILE@" preload=3Dyes fi case $arg in *.la | *.lo) ;; # We handle these cases below. force) if test "$dlself" =3D no; then dlself=3Dneedless export_dynamic=3Dyes fi prev=3D continue ;; self) if test "$prev" =3D dlprefiles; then dlself=3Dyes elif test "$prev" =3D dlfiles && test "$dlopen_self" !=3D yes; then dlself=3Dyes else dlself=3Dneedless export_dynamic=3Dyes fi prev=3D continue ;; *) if test "$prev" =3D dlfiles; then dlfiles=3D"$dlfiles $arg" else dlprefiles=3D"$dlprefiles $arg" fi prev=3D continue ;; esac ;; expsyms) export_symbols=3D"$arg" if test ! -f "$arg"; then $echo "$modename: symbol file \`$arg' does not exist" exit 1 fi prev=3D continue ;; expsyms_regex) export_symbols_regex=3D"$arg" prev=3D continue ;; inst_prefix) inst_prefix_dir=3D"$arg" prev=3D continue ;; precious_regex) precious_files_regex=3D"$arg" prev=3D continue ;; release) release=3D"-$arg" prev=3D continue ;; objectlist) if test -f "$arg"; then save_arg=3D$arg moreargs=3D for fil in `cat $save_arg` do # moreargs=3D"$moreargs $fil" arg=3D$fil # A libtool-controlled object. # Check to see that this really is a libtool object. if (${SED} -e '2q' $arg | grep "^# Generated by .*$PACKAGE") >/dev/n= ull 2>&1; then pic_object=3D non_pic_object=3D # Read the .lo file # If there is no directory component, then add one. case $arg in */* | *\\*) . $arg ;; *) . ./$arg ;; esac if test -z "$pic_object" || \ test -z "$non_pic_object" || test "$pic_object" =3D none && \ test "$non_pic_object" =3D none; then $echo "$modename: cannot find name of object for \`$arg'" 1>&2 exit 1 fi # Extract subdirectory from the argument. xdir=3D`$echo "X$arg" | $Xsed -e 's%/[^/]*$%%'` if test "X$xdir" =3D "X$arg"; then xdir=3D else xdir=3D"$xdir/" fi if test "$pic_object" !=3D none; then # Prepend the subdirectory the object is found in. pic_object=3D"$xdir$pic_object" if test "$prev" =3D dlfiles; then if test "$build_libtool_libs" =3D yes && test "$dlopen_support" =3D y= es; then dlfiles=3D"$dlfiles $pic_object" prev=3D continue else # If libtool objects are unsupported, then we need to preload. prev=3Ddlprefiles fi fi # CHECK ME: I think I busted this. -Ossama if test "$prev" =3D dlprefiles; then # Preload the old-style object. dlprefiles=3D"$dlprefiles $pic_object" prev=3D fi # A PIC object. libobjs=3D"$libobjs $pic_object" arg=3D"$pic_object" fi # Non-PIC object. if test "$non_pic_object" !=3D none; then # Prepend the subdirectory the object is found in. non_pic_object=3D"$xdir$non_pic_object" # A standard non-PIC object non_pic_objects=3D"$non_pic_objects $non_pic_object" if test -z "$pic_object" || test "$pic_object" =3D none ; then arg=3D"$non_pic_object" fi fi else # Only an error if not doing a dry-run. if test -z "$run"; then $echo "$modename: \`$arg' is not a valid libtool object" 1>&2 exit 1 else # Dry-run case. # Extract subdirectory from the argument. xdir=3D`$echo "X$arg" | $Xsed -e 's%/[^/]*$%%'` if test "X$xdir" =3D "X$arg"; then xdir=3D else xdir=3D"$xdir/" fi pic_object=3D`$echo "X${xdir}${objdir}/${arg}" | $Xsed -e "$lo2o"` non_pic_object=3D`$echo "X${xdir}${arg}" | $Xsed -e "$lo2o"` libobjs=3D"$libobjs $pic_object" non_pic_objects=3D"$non_pic_objects $non_pic_object" fi fi done else $echo "$modename: link input file \`$save_arg' does not exist" exit 1 fi arg=3D$save_arg prev=3D continue ;; rpath | xrpath) # We need an absolute path. case $arg in [\\/]* | [A-Za-z]:[\\/]*) ;; *) $echo "$modename: only absolute run-paths are allowed" 1>&2 exit 1 ;; esac if test "$prev" =3D rpath; then case "$rpath " in *" $arg "*) ;; *) rpath=3D"$rpath $arg" ;; esac else case "$xrpath " in *" $arg "*) ;; *) xrpath=3D"$xrpath $arg" ;; esac fi prev=3D continue ;; xcompiler) compiler_flags=3D"$compiler_flags $qarg" prev=3D compile_command=3D"$compile_command $qarg" finalize_command=3D"$finalize_command $qarg" continue ;; xlinker) linker_flags=3D"$linker_flags $qarg" compiler_flags=3D"$compiler_flags $wl$qarg" prev=3D compile_command=3D"$compile_command $wl$qarg" finalize_command=3D"$finalize_command $wl$qarg" continue ;; xcclinker) linker_flags=3D"$linker_flags $qarg" compiler_flags=3D"$compiler_flags $qarg" prev=3D compile_command=3D"$compile_command $qarg" finalize_command=3D"$finalize_command $qarg" continue ;; *) eval "$prev=3D\"\$arg\"" prev=3D continue ;; esac fi # test -n "$prev" prevarg=3D"$arg" case $arg in -all-static) if test -n "$link_static_flag"; then compile_command=3D"$compile_command $link_static_flag" finalize_command=3D"$finalize_command $link_static_flag" fi continue ;; -allow-undefined) # FIXME: remove this flag sometime in the future. $echo "$modename: \`-allow-undefined' is deprecated because it is the defa= ult" 1>&2 continue ;; -avoid-version) avoid_version=3Dyes continue ;; -dlopen) prev=3Ddlfiles continue ;; -dlpreopen) prev=3Ddlprefiles continue ;; -export-dynamic) export_dynamic=3Dyes continue ;; -export-symbols | -export-symbols-regex) if test -n "$export_symbols" || test -n "$export_symbols_regex"; then $echo "$modename: more than one -exported-symbols argument is not allowe= d" exit 1 fi if test "X$arg" =3D "X-export-symbols"; then prev=3Dexpsyms else prev=3Dexpsyms_regex fi continue ;; -inst-prefix-dir) prev=3Dinst_prefix continue ;; # The native IRIX linker understands -LANG:*, -LIST:* and -LNO:* # so, if we see these flags be careful not to treat them like -L -L[A-Z][A-Z]*:*) case $with_gcc/$host in no/*-*-irix* | /*-*-irix*) compile_command=3D"$compile_command $arg" finalize_command=3D"$finalize_command $arg" ;; esac continue ;; -L*) dir=3D`$echo "X$arg" | $Xsed -e 's/^-L//'` # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) ;; *) absdir=3D`cd "$dir" && pwd` if test -z "$absdir"; then $echo "$modename: cannot determine absolute directory name of \`$dir'"= 1>&2 exit 1 fi dir=3D"$absdir" ;; esac case "$deplibs " in *" -L$dir "*) ;; *) deplibs=3D"$deplibs -L$dir" lib_search_path=3D"$lib_search_path $dir" ;; esac case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*) case :$dllsearchpath: in *":$dir:"*) ;; *) dllsearchpath=3D"$dllsearchpath:$dir";; esac ;; esac continue ;; -l*) if test "X$arg" =3D "X-lc" || test "X$arg" =3D "X-lm"; then case $host in *-*-cygwin* | *-*-pw32* | *-*-beos*) # These systems don't actually have a C or math library (as such) continue ;; *-*-mingw* | *-*-os2*) # These systems don't actually have a C library (as such) test "X$arg" =3D "X-lc" && continue ;; *-*-openbsd* | *-*-freebsd*) # Do not include libc due to us having libc/libc_r. test "X$arg" =3D "X-lc" && continue ;; *-*-rhapsody* | *-*-darwin1.[012]) # Rhapsody C and math libraries are in the System framework deplibs=3D"$deplibs -framework System" continue esac elif test "X$arg" =3D "X-lc_r"; then case $host in *-*-openbsd* | *-*-freebsd*) # Do not include libc_r directly, use -pthread flag. continue ;; esac fi deplibs=3D"$deplibs $arg" continue ;; -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe) deplibs=3D"$deplibs $arg" continue ;; -module) module=3Dyes continue ;; # gcc -m* arguments should be passed to the linker via $compiler_flags # in order to pass architecture information to the linker # (e.g. 32 vs 64-bit). This may also be accomplished via -Wl,-mfoo # but this is not reliable with gcc because gcc may use -mfoo to # select a different linker, different libraries, etc, while # -Wl,-mfoo simply passes -mfoo to the linker. -m*) # Unknown arguments in both finalize_command and compile_command need # to be aesthetically quoted because they are evaled later. arg=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst"` case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") arg=3D"\"$arg\"" ;; esac compile_command=3D"$compile_command $arg" finalize_command=3D"$finalize_command $arg" if test "$with_gcc" =3D "yes" ; then compiler_flags=3D"$compiler_flags $arg" fi continue ;; -shrext) prev=3Dshrext continue ;; -no-fast-install) fast_install=3Dno continue ;; -no-install) case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*) # The PATH hackery in wrapper scripts is required on Windows # in order for the loader to find any dlls it needs. $echo "$modename: warning: \`-no-install' is ignored for $host" 1>&2 $echo "$modename: warning: assuming \`-no-fast-install' instead" 1>&2 fast_install=3Dno ;; *) no_install=3Dyes ;; esac continue ;; -no-undefined) allow_undefined=3Dno continue ;; -objectlist) prev=3Dobjectlist continue ;; -o) prev=3Doutput ;; -precious-files-regex) prev=3Dprecious_regex continue ;; -release) prev=3Drelease continue ;; -rpath) prev=3Drpath continue ;; -R) prev=3Dxrpath continue ;; -R*) dir=3D`$echo "X$arg" | $Xsed -e 's/^-R//'` # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) ;; *) $echo "$modename: only absolute run-paths are allowed" 1>&2 exit 1 ;; esac case "$xrpath " in *" $dir "*) ;; *) xrpath=3D"$xrpath $dir" ;; esac continue ;; -static) # The effects of -static are defined in a previous loop. # We used to do the same as -all-static on platforms that # didn't have a PIC flag, but the assumption that the effects # would be equivalent was wrong. It would break on at least # Digital Unix and AIX. continue ;; -thread-safe) thread_safe=3Dyes continue ;; -version-info) prev=3Dvinfo continue ;; -version-number) prev=3Dvinfo vinfo_number=3Dyes continue ;; -Wc,*) args=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst" -e 's/^-Wc,//'` arg=3D save_ifs=3D"$IFS"; IFS=3D',' for flag in $args; do IFS=3D"$save_ifs" case $flag in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") flag=3D"\"$flag\"" ;; esac arg=3D"$arg $wl$flag" compiler_flags=3D"$compiler_flags $flag" done IFS=3D"$save_ifs" arg=3D`$echo "X$arg" | $Xsed -e "s/^ //"` ;; -Wl,*) args=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst" -e 's/^-Wl,//'` arg=3D save_ifs=3D"$IFS"; IFS=3D',' for flag in $args; do IFS=3D"$save_ifs" case $flag in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") flag=3D"\"$flag\"" ;; esac arg=3D"$arg $wl$flag" compiler_flags=3D"$compiler_flags $wl$flag" linker_flags=3D"$linker_flags $flag" done IFS=3D"$save_ifs" arg=3D`$echo "X$arg" | $Xsed -e "s/^ //"` ;; -Xcompiler) prev=3Dxcompiler continue ;; -Xlinker) prev=3Dxlinker continue ;; -XCClinker) prev=3Dxcclinker continue ;; # Some other compiler flag. -* | +*) # Unknown arguments in both finalize_command and compile_command need # to be aesthetically quoted because they are evaled later. arg=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst"` case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") arg=3D"\"$arg\"" ;; esac ;; *.$objext) # A standard object. objs=3D"$objs $arg" ;; *.lo) # A libtool-controlled object. # Check to see that this really is a libtool object. if (${SED} -e '2q' $arg | grep "^# Generated by .*$PACKAGE") >/dev/null 2>= &1; then pic_object=3D non_pic_object=3D # Read the .lo file # If there is no directory component, then add one. case $arg in */* | *\\*) . $arg ;; *) . ./$arg ;; esac if test -z "$pic_object" || \ test -z "$non_pic_object" || test "$pic_object" =3D none && \ test "$non_pic_object" =3D none; then $echo "$modename: cannot find name of object for \`$arg'" 1>&2 exit 1 fi # Extract subdirectory from the argument. xdir=3D`$echo "X$arg" | $Xsed -e 's%/[^/]*$%%'` if test "X$xdir" =3D "X$arg"; then xdir=3D else xdir=3D"$xdir/" fi if test "$pic_object" !=3D none; then # Prepend the subdirectory the object is found in. pic_object=3D"$xdir$pic_object" if test "$prev" =3D dlfiles; then if test "$build_libtool_libs" =3D yes && test "$dlopen_support" =3D = yes; then dlfiles=3D"$dlfiles $pic_object" prev=3D continue else # If libtool objects are unsupported, then we need to preload. prev=3Ddlprefiles fi fi # CHECK ME: I think I busted this. -Ossama if test "$prev" =3D dlprefiles; then # Preload the old-style object. dlprefiles=3D"$dlprefiles $pic_object" prev=3D fi # A PIC object. libobjs=3D"$libobjs $pic_object" arg=3D"$pic_object" fi # Non-PIC object. if test "$non_pic_object" !=3D none; then # Prepend the subdirectory the object is found in. non_pic_object=3D"$xdir$non_pic_object" # A standard non-PIC object non_pic_objects=3D"$non_pic_objects $non_pic_object" if test -z "$pic_object" || test "$pic_object" =3D none ; then arg=3D"$non_pic_object" fi fi else # Only an error if not doing a dry-run. if test -z "$run"; then $echo "$modename: \`$arg' is not a valid libtool object" 1>&2 exit 1 else # Dry-run case. # Extract subdirectory from the argument. xdir=3D`$echo "X$arg" | $Xsed -e 's%/[^/]*$%%'` if test "X$xdir" =3D "X$arg"; then xdir=3D else xdir=3D"$xdir/" fi pic_object=3D`$echo "X${xdir}${objdir}/${arg}" | $Xsed -e "$lo2o"` non_pic_object=3D`$echo "X${xdir}${arg}" | $Xsed -e "$lo2o"` libobjs=3D"$libobjs $pic_object" non_pic_objects=3D"$non_pic_objects $non_pic_object" fi fi ;; *.$libext) # An archive. deplibs=3D"$deplibs $arg" old_deplibs=3D"$old_deplibs $arg" continue ;; *.la) # A libtool-controlled library. if test "$prev" =3D dlfiles; then # This library was specified with -dlopen. dlfiles=3D"$dlfiles $arg" prev=3D elif test "$prev" =3D dlprefiles; then # The library was specified with -dlpreopen. dlprefiles=3D"$dlprefiles $arg" prev=3D else deplibs=3D"$deplibs $arg" fi continue ;; # Some other compiler argument. *) # Unknown arguments in both finalize_command and compile_command need # to be aesthetically quoted because they are evaled later. arg=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst"` case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"") arg=3D"\"$arg\"" ;; esac ;; esac # arg # Now actually substitute the argument into the commands. if test -n "$arg"; then compile_command=3D"$compile_command $arg" finalize_command=3D"$finalize_command $arg" fi done # argument parsing loop if test -n "$prev"; then $echo "$modename: the \`$prevarg' option requires an argument" 1>&2 $echo "$help" 1>&2 exit 1 fi if test "$export_dynamic" =3D yes && test -n "$export_dynamic_flag_spec= "; then eval arg=3D\"$export_dynamic_flag_spec\" compile_command=3D"$compile_command $arg" finalize_command=3D"$finalize_command $arg" fi oldlibs=3D # calculate the name of the file, without its directory outputname=3D`$echo "X$output" | $Xsed -e 's%^.*/%%'` libobjs_save=3D"$libobjs" if test -n "$shlibpath_var"; then # get the directories listed in $shlibpath_var eval shlib_search_path=3D\`\$echo \"X\${$shlibpath_var}\" \| \$Xsed -= e \'s/:/ /g\'\` else shlib_search_path=3D fi eval sys_lib_search_path=3D\"$sys_lib_search_path_spec\" eval sys_lib_dlsearch_path=3D\"$sys_lib_dlsearch_path_spec\" output_objdir=3D`$echo "X$output" | $Xsed -e 's%/[^/]*$%%'` if test "X$output_objdir" =3D "X$output"; then output_objdir=3D"$objdir" else output_objdir=3D"$output_objdir/$objdir" fi # Create the object directory. if test ! -d "$output_objdir"; then $show "$mkdir $output_objdir" $run $mkdir $output_objdir status=3D$? if test "$status" -ne 0 && test ! -d "$output_objdir"; then exit $status fi fi # Determine the type of output case $output in "") $echo "$modename: you must specify an output file" 1>&2 $echo "$help" 1>&2 exit 1 ;; *.$libext) linkmode=3Doldlib ;; *.lo | *.$objext) linkmode=3Dobj ;; *.la) linkmode=3Dlib ;; *) linkmode=3Dprog ;; # Anything else should be a program. esac case $host in *cygwin* | *mingw* | *pw32*) # don't eliminate duplcations in $postdeps and $predeps duplicate_compiler_generated_deps=3Dyes ;; *) duplicate_compiler_generated_deps=3D$duplicate_deps ;; esac specialdeplibs=3D libs=3D # Find all interdependent deplibs by searching for libraries # that are linked more than once (e.g. -la -lb -la) for deplib in $deplibs; do if test "X$duplicate_deps" =3D "Xyes" ; then case "$libs " in *" $deplib "*) specialdeplibs=3D"$specialdeplibs $deplib" ;; esac fi libs=3D"$libs $deplib" done if test "$linkmode" =3D lib; then libs=3D"$predeps $libs $compiler_lib_search_path $postdeps" # Compute libraries that are listed more than once in $predeps # $postdeps and mark them as special (i.e., whose duplicates are # not to be eliminated). pre_post_deps=3D if test "X$duplicate_compiler_generated_deps" =3D "Xyes" ; then for pre_post_dep in $predeps $postdeps; do case "$pre_post_deps " in *" $pre_post_dep "*) specialdeplibs=3D"$specialdeplibs $pre_post_deps" ;; esac pre_post_deps=3D"$pre_post_deps $pre_post_dep" done fi pre_post_deps=3D fi deplibs=3D newdependency_libs=3D newlib_search_path=3D need_relink=3Dno # whether we're linking any uninstalled libtool librar= ies notinst_deplibs=3D # not-installed libtool libraries notinst_path=3D # paths that contain not-installed libtool libraries case $linkmode in lib) passes=3D"conv link" for file in $dlfiles $dlprefiles; do case $file in *.la) ;; *) $echo "$modename: libraries can \`-dlopen' only libtool libraries: $fi= le" 1>&2 exit 1 ;; esac done ;; prog) compile_deplibs=3D finalize_deplibs=3D alldeplibs=3Dno newdlfiles=3D newdlprefiles=3D passes=3D"conv scan dlopen dlpreopen link" ;; *) passes=3D"conv" ;; esac for pass in $passes; do if test "$linkmode,$pass" =3D "lib,link" || test "$linkmode,$pass" =3D "prog,scan"; then libs=3D"$deplibs" deplibs=3D fi if test "$linkmode" =3D prog; then case $pass in dlopen) libs=3D"$dlfiles" ;; dlpreopen) libs=3D"$dlprefiles" ;; link) libs=3D"$deplibs %DEPLIBS% $dependency_libs" ;; esac fi if test "$pass" =3D dlopen; then # Collect dlpreopened libraries save_deplibs=3D"$deplibs" deplibs=3D fi for deplib in $libs; do lib=3D found=3Dno case $deplib in -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe) if test "$linkmode,$pass" =3D "prog,link"; then compile_deplibs=3D"$deplib $compile_deplibs" finalize_deplibs=3D"$deplib $finalize_deplibs" else deplibs=3D"$deplib $deplibs" fi continue ;; -l*) if test "$linkmode" !=3D lib && test "$linkmode" !=3D prog; then $echo "$modename: warning: \`-l' is ignored for archives/objects" 1>&2 continue fi if test "$pass" =3D conv; then deplibs=3D"$deplib $deplibs" continue fi name=3D`$echo "X$deplib" | $Xsed -e 's/^-l//'` for searchdir in $newlib_search_path $lib_search_path $sys_lib_search_pa= th $shlib_search_path; do for search_ext in .la $shrext .so .a; do # Search the libtool library lib=3D"$searchdir/lib${name}${search_ext}" if test -f "$lib"; then if test "$search_ext" =3D ".la"; then found=3Dyes else found=3Dno fi break 2 fi done done if test "$found" !=3D yes; then # deplib doesn't seem to be a libtool library if test "$linkmode,$pass" =3D "prog,link"; then compile_deplibs=3D"$deplib $compile_deplibs" finalize_deplibs=3D"$deplib $finalize_deplibs" else deplibs=3D"$deplib $deplibs" test "$linkmode" =3D lib && newdependency_libs=3D"$deplib $newdepend= ency_libs" fi continue else # deplib is a libtool library # If $allow_libtool_libs_with_static_runtimes && $deplib is a stdlib, # We need to do some special things here, and not later. if test "X$allow_libtool_libs_with_static_runtimes" =3D "Xyes" ; then case " $predeps $postdeps " in *" $deplib "*) if (${SED} -e '2q' $lib | grep "^# Generated by .*$PACKAGE") >/dev/null 2>&1; then library_names=3D old_library=3D case $lib in */* | *\\*) . $lib ;; *) . ./$lib ;; esac for l in $old_library $library_names; do ll=3D"$l" done if test "X$ll" =3D "X$old_library" ; then # only static version availab= le found=3Dno ladir=3D`$echo "X$lib" | $Xsed -e 's%/[^/]*$%%'` test "X$ladir" =3D "X$lib" && ladir=3D"." lib=3D$ladir/$old_library if test "$linkmode,$pass" =3D "prog,link"; then compile_deplibs=3D"$deplib $compile_deplibs" finalize_deplibs=3D"$deplib $finalize_deplibs" else deplibs=3D"$deplib $deplibs" test "$linkmode" =3D lib && newdependency_libs=3D"$deplib $newdepen= dency_libs" fi continue fi fi ;; *) ;; esac fi fi ;; # -l -L*) case $linkmode in lib) deplibs=3D"$deplib $deplibs" test "$pass" =3D conv && continue newdependency_libs=3D"$deplib $newdependency_libs" newlib_search_path=3D"$newlib_search_path "`$echo "X$deplib" | $Xsed -= e 's/^-L//'` ;; prog) if test "$pass" =3D conv; then deplibs=3D"$deplib $deplibs" continue fi if test "$pass" =3D scan; then deplibs=3D"$deplib $deplibs" newlib_search_path=3D"$newlib_search_path "`$echo "X$deplib" | $Xsed= -e 's/^-L//'` else compile_deplibs=3D"$deplib $compile_deplibs" finalize_deplibs=3D"$deplib $finalize_deplibs" fi ;; *) $echo "$modename: warning: \`-L' is ignored for archives/objects" 1>&2 ;; esac # linkmode continue ;; # -L -R*) if test "$pass" =3D link; then dir=3D`$echo "X$deplib" | $Xsed -e 's/^-R//'` # Make sure the xrpath contains only unique directories. case "$xrpath " in *" $dir "*) ;; *) xrpath=3D"$xrpath $dir" ;; esac fi deplibs=3D"$deplib $deplibs" continue ;; *.la) lib=3D"$deplib" ;; *.$libext) if test "$pass" =3D conv; then deplibs=3D"$deplib $deplibs" continue fi case $linkmode in lib) if test "$deplibs_check_method" !=3D pass_all; then $echo $echo "*** Warning: Trying to link with static lib archive $deplib." $echo "*** I have the capability to make that library automatically = link in when" $echo "*** you link to this library. But I can only do this if you = have a" $echo "*** shared version of the library, which you do not appear to= have" $echo "*** because the file extensions .$libext of this argument mak= es me believe" $echo "*** that it is just a static archive that I should not used h= ere." else $echo $echo "*** Warning: Linking the shared library $output against the" $echo "*** static library $deplib is not portable!" deplibs=3D"$deplib $deplibs" fi continue ;; prog) if test "$pass" !=3D link; then deplibs=3D"$deplib $deplibs" else compile_deplibs=3D"$deplib $compile_deplibs" finalize_deplibs=3D"$deplib $finalize_deplibs" fi continue ;; esac # linkmode ;; # *.$libext *.lo | *.$objext) if test "$pass" =3D conv; then deplibs=3D"$deplib $deplibs" elif test "$linkmode" =3D prog; then if test "$pass" =3D dlpreopen || test "$dlopen_support" !=3D yes || te= st "$build_libtool_libs" =3D no; then # If there is no dlopen support or we're linking statically, # we need to preload. newdlprefiles=3D"$newdlprefiles $deplib" compile_deplibs=3D"$deplib $compile_deplibs" finalize_deplibs=3D"$deplib $finalize_deplibs" else newdlfiles=3D"$newdlfiles $deplib" fi fi continue ;; %DEPLIBS%) alldeplibs=3Dyes continue ;; esac # case $deplib if test "$found" =3D yes || test -f "$lib"; then : else $echo "$modename: cannot find the library \`$lib'" 1>&2 exit 1 fi # Check to see that this really is a libtool archive. if (${SED} -e '2q' $lib | grep "^# Generated by .*$PACKAGE") >/dev/null 2>= &1; then : else $echo "$modename: \`$lib' is not a valid libtool archive" 1>&2 exit 1 fi ladir=3D`$echo "X$lib" | $Xsed -e 's%/[^/]*$%%'` test "X$ladir" =3D "X$lib" && ladir=3D"." dlname=3D dlopen=3D dlpreopen=3D libdir=3D library_names=3D old_library=3D # If the library was installed with an old release of libtool, # it will not redefine variables installed, or shouldnotlink installed=3Dyes shouldnotlink=3Dno # Read the .la file case $lib in */* | *\\*) . $lib ;; *) . ./$lib ;; esac if test "$linkmode,$pass" =3D "lib,link" || test "$linkmode,$pass" =3D "prog,scan" || { test "$linkmode" !=3D prog && test "$linkmode" !=3D lib; }; then test -n "$dlopen" && dlfiles=3D"$dlfiles $dlopen" test -n "$dlpreopen" && dlprefiles=3D"$dlprefiles $dlpreopen" fi if test "$pass" =3D conv; then # Only check for convenience libraries deplibs=3D"$lib $deplibs" if test -z "$libdir"; then if test -z "$old_library"; then $echo "$modename: cannot find name of link library for \`$lib'" 1>&2 exit 1 fi # It is a libtool convenience library, so add in its objects. convenience=3D"$convenience $ladir/$objdir/$old_library" old_convenience=3D"$old_convenience $ladir/$objdir/$old_library" tmp_libs=3D for deplib in $dependency_libs; do deplibs=3D"$deplib $deplibs" if test "X$duplicate_deps" =3D "Xyes" ; then case "$tmp_libs " in *" $deplib "*) specialdeplibs=3D"$specialdeplibs $deplib" ;; esac fi tmp_libs=3D"$tmp_libs $deplib" done elif test "$linkmode" !=3D prog && test "$linkmode" !=3D lib; then $echo "$modename: \`$lib' is not a convenience library" 1>&2 exit 1 fi continue fi # $pass =3D conv =20 # Get the name of the library we link against. linklib=3D for l in $old_library $library_names; do linklib=3D"$l" done if test -z "$linklib"; then $echo "$modename: cannot find name of link library for \`$lib'" 1>&2 exit 1 fi # This library was specified with -dlopen. if test "$pass" =3D dlopen; then if test -z "$libdir"; then $echo "$modename: cannot -dlopen a convenience library: \`$lib'" 1>&2 exit 1 fi if test -z "$dlname" || test "$dlopen_support" !=3D yes || test "$build_= libtool_libs" =3D no; then # If there is no dlname, no dlopen support or we're linking # statically, we need to preload. We also need to preload any # dependent libraries so libltdl's deplib preloader doesn't # bomb out in the load deplibs phase. dlprefiles=3D"$dlprefiles $lib $dependency_libs" else newdlfiles=3D"$newdlfiles $lib" fi continue fi # $pass =3D dlopen # We need an absolute path. case $ladir in [\\/]* | [A-Za-z]:[\\/]*) abs_ladir=3D"$ladir" ;; *) abs_ladir=3D`cd "$ladir" && pwd` if test -z "$abs_ladir"; then $echo "$modename: warning: cannot determine absolute directory name of= \`$ladir'" 1>&2 $echo "$modename: passing it literally to the linker, although it migh= t fail" 1>&2 abs_ladir=3D"$ladir" fi ;; esac laname=3D`$echo "X$lib" | $Xsed -e 's%^.*/%%'` # Find the relevant object directory and library name. if test "X$installed" =3D Xyes; then if test ! -f "$libdir/$linklib" && test -f "$abs_ladir/$linklib"; then $echo "$modename: warning: library \`$lib' was moved." 1>&2 dir=3D"$ladir" absdir=3D"$abs_ladir" libdir=3D"$abs_ladir" else dir=3D"$libdir" absdir=3D"$libdir" fi else dir=3D"$ladir/$objdir" absdir=3D"$abs_ladir/$objdir" # Remove this search path later notinst_path=3D"$notinst_path $abs_ladir" fi # $installed =3D yes name=3D`$echo "X$laname" | $Xsed -e 's/\.la$//' -e 's/^lib//'` # This library was specified with -dlpreopen. if test "$pass" =3D dlpreopen; then if test -z "$libdir"; then $echo "$modename: cannot -dlpreopen a convenience library: \`$lib'" 1>= &2 exit 1 fi # Prefer using a static library (so that no silly _DYNAMIC symbols # are required to link). if test -n "$old_library"; then newdlprefiles=3D"$newdlprefiles $dir/$old_library" # Otherwise, use the dlname, so that lt_dlopen finds it. elif test -n "$dlname"; then newdlprefiles=3D"$newdlprefiles $dir/$dlname" else newdlprefiles=3D"$newdlprefiles $dir/$linklib" fi fi # $pass =3D dlpreopen if test -z "$libdir"; then # Link the convenience library if test "$linkmode" =3D lib; then deplibs=3D"$dir/$old_library $deplibs" elif test "$linkmode,$pass" =3D "prog,link"; then compile_deplibs=3D"$dir/$old_library $compile_deplibs" finalize_deplibs=3D"$dir/$old_library $finalize_deplibs" else deplibs=3D"$lib $deplibs" # used for prog,scan pass fi continue fi =20 if test "$linkmode" =3D prog && test "$pass" !=3D link; then newlib_search_path=3D"$newlib_search_path $ladir" deplibs=3D"$lib $deplibs" linkalldeplibs=3Dno if test "$link_all_deplibs" !=3D no || test -z "$library_names" || test "$build_libtool_libs" =3D no; then linkalldeplibs=3Dyes fi tmp_libs=3D for deplib in $dependency_libs; do case $deplib in -L*) newlib_search_path=3D"$newlib_search_path "`$echo "X$deplib" | $X= sed -e 's/^-L//'`;; ### testsuite: skip nested quoting test esac # Need to link against all dependency_libs? if test "$linkalldeplibs" =3D yes; then deplibs=3D"$deplib $deplibs" else # Need to hardcode shared library paths # or/and link against static libraries newdependency_libs=3D"$deplib $newdependency_libs" fi if test "X$duplicate_deps" =3D "Xyes" ; then case "$tmp_libs " in *" $deplib "*) specialdeplibs=3D"$specialdeplibs $deplib" ;; esac fi tmp_libs=3D"$tmp_libs $deplib" done # for deplib continue fi # $linkmode =3D prog... if test "$linkmode,$pass" =3D "prog,link"; then if test -n "$library_names" && { test "$prefer_static_libs" =3D no || test -z "$old_library"; }; then # We need to hardcode the library path if test -n "$shlibpath_var"; then # Make sure the rpath contains only unique directories. case "$temp_rpath " in *" $dir "*) ;; *" $absdir "*) ;; *) temp_rpath=3D"$temp_rpath $dir" ;; esac fi # Hardcode the library path. # Skip directories that are in the system default run-time # search path. case " $sys_lib_dlsearch_path " in *" $absdir "*) ;; *) case "$compile_rpath " in *" $absdir "*) ;; *) compile_rpath=3D"$compile_rpath $absdir" esac ;; esac case " $sys_lib_dlsearch_path " in *" $libdir "*) ;; *) case "$finalize_rpath " in *" $libdir "*) ;; *) finalize_rpath=3D"$finalize_rpath $libdir" esac ;; esac fi # $linkmode,$pass =3D prog,link... if test "$alldeplibs" =3D yes && { test "$deplibs_check_method" =3D pass_all || { test "$build_libtool_libs" =3D yes && test -n "$library_names"; }; }; then # We only need to search for static libraries continue fi fi link_static=3Dno # Whether the deplib will be linked statically if test -n "$library_names" && { test "$prefer_static_libs" =3D no || test -z "$old_library"; }; then if test "$installed" =3D no; then notinst_deplibs=3D"$notinst_deplibs $lib" need_relink=3Dyes fi # This is a shared library =09 # Warn about portability, can't link against -module's on some system= s (darwin) if test "$shouldnotlink" =3D yes && test "$pass" =3D link ; then $echo if test "$linkmode" =3D prog; then $echo "*** Warning: Linking the executable $output against the loada= ble module" else $echo "*** Warning: Linking the shared library $output against the l= oadable module" fi $echo "*** $linklib is not portable!" =20 fi =20 if test "$linkmode" =3D lib && test "$hardcode_into_libs" =3D yes; then # Hardcode the library path. # Skip directories that are in the system default run-time # search path. case " $sys_lib_dlsearch_path " in *" $absdir "*) ;; *) case "$compile_rpath " in *" $absdir "*) ;; *) compile_rpath=3D"$compile_rpath $absdir" esac ;; esac case " $sys_lib_dlsearch_path " in *" $libdir "*) ;; *) case "$finalize_rpath " in *" $libdir "*) ;; *) finalize_rpath=3D"$finalize_rpath $libdir" esac ;; esac fi if test -n "$old_archive_from_expsyms_cmds"; then # figure out the soname set dummy $library_names realname=3D"$2" shift; shift libname=3D`eval \\$echo \"$libname_spec\"` # use dlname if we got it. it's perfectly good, no? if test -n "$dlname"; then soname=3D"$dlname" elif test -n "$soname_spec"; then # bleh windows case $host in *cygwin* | mingw*) major=3D`expr $current - $age` versuffix=3D"-$major" ;; esac eval soname=3D\"$soname_spec\" else soname=3D"$realname" fi # Make a new name for the extract_expsyms_cmds to use soroot=3D"$soname" soname=3D`$echo $soroot | ${SED} -e 's/^.*\///'` newlib=3D"libimp-`$echo $soname | ${SED} 's/^lib//;s/\.dll$//'`.a" # If the library has no export list, then create one now if test -f "$output_objdir/$soname-def"; then : else $show "extracting exported symbol list from \`$soname'" save_ifs=3D"$IFS"; IFS=3D'~' cmds=3D$extract_expsyms_cmds for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" fi # Create $newlib if test -f "$output_objdir/$newlib"; then :; else $show "generating import library for \`$soname'" save_ifs=3D"$IFS"; IFS=3D'~' cmds=3D$old_archive_from_expsyms_cmds for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" fi # make sure the library variables are pointing to the new library dir=3D$output_objdir linklib=3D$newlib fi # test -n "$old_archive_from_expsyms_cmds" if test "$linkmode" =3D prog || test "$mode" !=3D relink; then add_shlibpath=3D add_dir=3D add=3D lib_linked=3Dyes case $hardcode_action in immediate | unsupported) if test "$hardcode_direct" =3D no; then add=3D"$dir/$linklib" case $host in *-*-sco3.2v5* ) add_dir=3D"-L$dir" ;; *-*-darwin* ) # if the lib is a module then we can not link against it, someone # is ignoring the new warnings I added if /usr/bin/file -L $add 2> /dev/null | grep "bundle" >/dev/null ; th= en $echo "** Warning, lib $linklib is a module, not a shared library" if test -z "$old_library" ; then $echo $echo "** And there doesn't seem to be a static archive available" $echo "** The link will probably fail, sorry" else add=3D"$dir/$old_library" fi=20 fi esac elif test "$hardcode_minus_L" =3D no; then case $host in *-*-sunos*) add_shlibpath=3D"$dir" ;; esac add_dir=3D"-L$dir" add=3D"-l$name" elif test "$hardcode_shlibpath_var" =3D no; then add_shlibpath=3D"$dir" add=3D"-l$name" else lib_linked=3Dno fi ;; relink) if test "$hardcode_direct" =3D yes; then add=3D"$dir/$linklib" elif test "$hardcode_minus_L" =3D yes; then add_dir=3D"-L$dir" # Try looking first in the location we're being installed to. if test -n "$inst_prefix_dir"; then case "$libdir" in [\\/]*) add_dir=3D"$add_dir -L$inst_prefix_dir$libdir" ;; esac fi add=3D"-l$name" elif test "$hardcode_shlibpath_var" =3D yes; then add_shlibpath=3D"$dir" add=3D"-l$name" else lib_linked=3Dno fi ;; *) lib_linked=3Dno ;; esac if test "$lib_linked" !=3D yes; then $echo "$modename: configuration error: unsupported hardcode properti= es" exit 1 fi if test -n "$add_shlibpath"; then case :$compile_shlibpath: in *":$add_shlibpath:"*) ;; *) compile_shlibpath=3D"$compile_shlibpath$add_shlibpath:" ;; esac fi if test "$linkmode" =3D prog; then test -n "$add_dir" && compile_deplibs=3D"$add_dir $compile_deplibs" test -n "$add" && compile_deplibs=3D"$add $compile_deplibs" else test -n "$add_dir" && deplibs=3D"$add_dir $deplibs" test -n "$add" && deplibs=3D"$add $deplibs" if test "$hardcode_direct" !=3D yes && \ test "$hardcode_minus_L" !=3D yes && \ test "$hardcode_shlibpath_var" =3D yes; then case :$finalize_shlibpath: in *":$libdir:"*) ;; *) finalize_shlibpath=3D"$finalize_shlibpath$libdir:" ;; esac fi fi fi if test "$linkmode" =3D prog || test "$mode" =3D relink; then add_shlibpath=3D add_dir=3D add=3D # Finalize command for both is simple: just hardcode it. if test "$hardcode_direct" =3D yes; then add=3D"$libdir/$linklib" elif test "$hardcode_minus_L" =3D yes; then add_dir=3D"-L$libdir" add=3D"-l$name" elif test "$hardcode_shlibpath_var" =3D yes; then case :$finalize_shlibpath: in *":$libdir:"*) ;; *) finalize_shlibpath=3D"$finalize_shlibpath$libdir:" ;; esac add=3D"-l$name" elif test "$hardcode_automatic" =3D yes; then if test -n "$inst_prefix_dir" && test -f "$inst_prefix_dir$libdir/$l= inklib" ; then add=3D"$inst_prefix_dir$libdir/$linklib" else add=3D"$libdir/$linklib" fi else # We cannot seem to hardcode it, guess we'll fake it. add_dir=3D"-L$libdir" # Try looking first in the location we're being installed to. if test -n "$inst_prefix_dir"; then case "$libdir" in [\\/]*) add_dir=3D"$add_dir -L$inst_prefix_dir$libdir" ;; esac fi add=3D"-l$name" fi if test "$linkmode" =3D prog; then test -n "$add_dir" && finalize_deplibs=3D"$add_dir $finalize_deplibs" test -n "$add" && finalize_deplibs=3D"$add $finalize_deplibs" else test -n "$add_dir" && deplibs=3D"$add_dir $deplibs" test -n "$add" && deplibs=3D"$add $deplibs" fi fi elif test "$linkmode" =3D prog; then # Here we assume that one of hardcode_direct or hardcode_minus_L # is not unsupported. This is valid on all known static and # shared platforms. if test "$hardcode_direct" !=3D unsupported; then test -n "$old_library" && linklib=3D"$old_library" compile_deplibs=3D"$dir/$linklib $compile_deplibs" finalize_deplibs=3D"$dir/$linklib $finalize_deplibs" else compile_deplibs=3D"-l$name -L$dir $compile_deplibs" finalize_deplibs=3D"-l$name -L$dir $finalize_deplibs" fi elif test "$build_libtool_libs" =3D yes; then # Not a shared library if test "$deplibs_check_method" !=3D pass_all; then # We're trying link a shared library against a static one # but the system doesn't support it. # Just print a warning and add the library to dependency_libs so # that the program can be linked against the static library. $echo $echo "*** Warning: This system can not link to static lib archive $li= b." $echo "*** I have the capability to make that library automatically li= nk in when" $echo "*** you link to this library. But I can only do this if you ha= ve a" $echo "*** shared version of the library, which you do not appear to h= ave." if test "$module" =3D yes; then $echo "*** But as you try to build a module library, libtool will st= ill create " $echo "*** a static module, that should work as long as the dlopenin= g application" $echo "*** is linked with the -dlopen flag to resolve symbols at run= time." if test -z "$global_symbol_pipe"; then $echo $echo "*** However, this would only work if libtool was able to extract s= ymbol" $echo "*** lists from a program, using \`nm' or equivalent, but libtool c= ould" $echo "*** not find such a program. So, this module is probably useless." $echo "*** \`nm' from GNU binutils and a full rebuild may help." fi if test "$build_old_libs" =3D no; then build_libtool_libs=3Dmodule build_old_libs=3Dyes else build_libtool_libs=3Dno fi fi else convenience=3D"$convenience $dir/$old_library" old_convenience=3D"$old_convenience $dir/$old_library" deplibs=3D"$dir/$old_library $deplibs" link_static=3Dyes fi fi # link shared/static library? if test "$linkmode" =3D lib; then if test -n "$dependency_libs" && { test "$hardcode_into_libs" !=3D yes || test "$build_old_libs" =3D y= es || test "$link_static" =3D yes; }; then # Extract -R from dependency_libs temp_deplibs=3D for libdir in $dependency_libs; do case $libdir in -R*) temp_xrpath=3D`$echo "X$libdir" | $Xsed -e 's/^-R//'` case " $xrpath " in *" $temp_xrpath "*) ;; *) xrpath=3D"$xrpath $temp_xrpath";; esac;; *) temp_deplibs=3D"$temp_deplibs $libdir";; esac done dependency_libs=3D"$temp_deplibs" fi newlib_search_path=3D"$newlib_search_path $absdir" # Link against this library test "$link_static" =3D no && newdependency_libs=3D"$abs_ladir/$laname $= newdependency_libs" # ... and its dependency_libs tmp_libs=3D for deplib in $dependency_libs; do newdependency_libs=3D"$deplib $newdependency_libs" if test "X$duplicate_deps" =3D "Xyes" ; then case "$tmp_libs " in *" $deplib "*) specialdeplibs=3D"$specialdeplibs $deplib" ;; esac fi tmp_libs=3D"$tmp_libs $deplib" done if test "$link_all_deplibs" !=3D no; then # Add the search paths of all dependency libraries for deplib in $dependency_libs; do case $deplib in -L*) path=3D"$deplib" ;; *.la) dir=3D`$echo "X$deplib" | $Xsed -e 's%/[^/]*$%%'` test "X$dir" =3D "X$deplib" && dir=3D"." # We need an absolute path. case $dir in [\\/]* | [A-Za-z]:[\\/]*) absdir=3D"$dir" ;; *) absdir=3D`cd "$dir" && pwd` if test -z "$absdir"; then $echo "$modename: warning: cannot determine absolute directory name o= f \`$dir'" 1>&2 absdir=3D"$dir" fi ;; esac if grep "^installed=3Dno" $deplib > /dev/null; then path=3D"$absdir/$objdir" else eval libdir=3D`${SED} -n -e 's/^libdir=3D\(.*\)$/\1/p' $deplib` if test -z "$libdir"; then $echo "$modename: \`$deplib' is not a valid libtool archive" 1>&2 exit 1 fi if test "$absdir" !=3D "$libdir"; then $echo "$modename: warning: \`$deplib' seems to be moved" 1>&2 fi path=3D"$absdir" fi depdepl=3D case $host in *-*-darwin*) # we do not want to link against static libs, but need to link against = shared eval deplibrary_names=3D`${SED} -n -e 's/^library_names=3D\(.*\)$/\1/p'= $deplib` if test -n "$deplibrary_names" ; then for tmp in $deplibrary_names ; do depdepl=3D$tmp done if test -f "$path/$depdepl" ; then depdepl=3D"$path/$depdepl" fi # do not add paths which are already there case " $newlib_search_path " in *" $path "*) ;; *) newlib_search_path=3D"$newlib_search_path $path";; esac fi path=3D"" ;; *) path=3D"-L$path" ;; esac=20 =09 ;; -l*) case $host in *-*-darwin*) # Again, we only want to link against shared libraries eval tmp_libs=3D`$echo "X$deplib" | $Xsed -e "s,^\-l,,"` for tmp in $newlib_search_path ; do if test -f "$tmp/lib$tmp_libs.dylib" ; then eval depdepl=3D"$tmp/lib$tmp_libs.dylib" break fi =20 done path=3D"" ;; *) continue ;; esac =20 ;; *) continue ;; esac case " $deplibs " in *" $depdepl "*) ;; *) deplibs=3D"$deplibs $depdepl" ;; esac =20 case " $deplibs " in *" $path "*) ;; *) deplibs=3D"$deplibs $path" ;; esac done fi # link_all_deplibs !=3D no fi # linkmode =3D lib done # for deplib in $libs dependency_libs=3D"$newdependency_libs" if test "$pass" =3D dlpreopen; then # Link the dlpreopened libraries before other libraries for deplib in $save_deplibs; do deplibs=3D"$deplib $deplibs" done fi if test "$pass" !=3D dlopen; then if test "$pass" !=3D conv; then # Make sure lib_search_path contains only unique directories. lib_search_path=3D for dir in $newlib_search_path; do case "$lib_search_path " in *" $dir "*) ;; *) lib_search_path=3D"$lib_search_path $dir" ;; esac done newlib_search_path=3D fi if test "$linkmode,$pass" !=3D "prog,link"; then vars=3D"deplibs" else vars=3D"compile_deplibs finalize_deplibs" fi for var in $vars dependency_libs; do # Add libraries to $var in reverse order eval tmp_libs=3D\"\$$var\" new_libs=3D for deplib in $tmp_libs; do # FIXME: Pedantically, this is the right thing to do, so # that some nasty dependency loop isn't accidentally # broken: #new_libs=3D"$deplib $new_libs" # Pragmatically, this seems to cause very few problems in # practice: case $deplib in -L*) new_libs=3D"$deplib $new_libs" ;; -R*) ;; *) # And here is the reason: when a library appears more # than once as an explicit dependence of a library, or # is implicitly linked in more than once by the # compiler, it is considered special, and multiple # occurrences thereof are not removed. Compare this # with having the same library being listed as a # dependency of multiple other libraries: in this case, # we know (pedantically, we assume) the library does not # need to be listed more than once, so we keep only the # last copy. This is not always right, but it is rare # enough that we require users that really mean to play # such unportable linking tricks to link the library # using -Wl,-lname, so that libtool does not consider it # for duplicate removal. case " $specialdeplibs " in *" $deplib "*) new_libs=3D"$deplib $new_libs" ;; *) case " $new_libs " in *" $deplib "*) ;; *) new_libs=3D"$deplib $new_libs" ;; esac ;; esac ;; esac done tmp_libs=3D for deplib in $new_libs; do case $deplib in -L*) case " $tmp_libs " in *" $deplib "*) ;; *) tmp_libs=3D"$tmp_libs $deplib" ;; esac ;; *) tmp_libs=3D"$tmp_libs $deplib" ;; esac done eval $var=3D\"$tmp_libs\" done # for var fi # Last step: remove runtime libs from dependency_libs (they stay in d= eplibs) tmp_libs=3D for i in $dependency_libs ; do case " $predeps $postdeps $compiler_lib_search_path " in *" $i "*) i=3D"" ;; esac if test -n "$i" ; then tmp_libs=3D"$tmp_libs $i" fi done dependency_libs=3D$tmp_libs done # for pass if test "$linkmode" =3D prog; then dlfiles=3D"$newdlfiles" dlprefiles=3D"$newdlprefiles" fi case $linkmode in oldlib) if test -n "$deplibs"; then $echo "$modename: warning: \`-l' and \`-L' are ignored for archives" 1>&2 fi if test -n "$dlfiles$dlprefiles" || test "$dlself" !=3D no; then $echo "$modename: warning: \`-dlopen' is ignored for archives" 1>&2 fi if test -n "$rpath"; then $echo "$modename: warning: \`-rpath' is ignored for archives" 1>&2 fi if test -n "$xrpath"; then $echo "$modename: warning: \`-R' is ignored for archives" 1>&2 fi if test -n "$vinfo"; then $echo "$modename: warning: \`-version-info/-version-number' is ignored for= archives" 1>&2 fi if test -n "$release"; then $echo "$modename: warning: \`-release' is ignored for archives" 1>&2 fi if test -n "$export_symbols" || test -n "$export_symbols_regex"; then $echo "$modename: warning: \`-export-symbols' is ignored for archives" 1>&2 fi # Now set the variables for building old libraries. build_libtool_libs=3Dno oldlibs=3D"$output" objs=3D"$objs$old_deplibs" ;; lib) # Make sure we only generate libraries of the form `libNAME.la'. case $outputname in lib*) name=3D`$echo "X$outputname" | $Xsed -e 's/\.la$//' -e 's/^lib//'` eval shared_ext=3D\"$shrext\" eval libname=3D\"$libname_spec\" ;; *) if test "$module" =3D no; then $echo "$modename: libtool library \`$output' must begin with \`lib'" 1>&2 $echo "$help" 1>&2 exit 1 fi if test "$need_lib_prefix" !=3D no; then # Add the "lib" prefix for modules if required name=3D`$echo "X$outputname" | $Xsed -e 's/\.la$//'` eval shared_ext=3D\"$shrext\" eval libname=3D\"$libname_spec\" else libname=3D`$echo "X$outputname" | $Xsed -e 's/\.la$//'` fi ;; esac if test -n "$objs"; then if test "$deplibs_check_method" !=3D pass_all; then $echo "$modename: cannot build libtool library \`$output' from non-libto= ol objects on this host:$objs" 2>&1 exit 1 else $echo $echo "*** Warning: Linking the shared library $output against the non-l= ibtool" $echo "*** objects $objs is not portable!" libobjs=3D"$libobjs $objs" fi fi if test "$dlself" !=3D no; then $echo "$modename: warning: \`-dlopen self' is ignored for libtool librarie= s" 1>&2 fi set dummy $rpath if test "$#" -gt 2; then $echo "$modename: warning: ignoring multiple \`-rpath's for a libtool libr= ary" 1>&2 fi install_libdir=3D"$2" oldlibs=3D if test -z "$rpath"; then if test "$build_libtool_libs" =3D yes; then # Building a libtool convenience library. # Some compilers have problems with a `.al' extension so # convenience libraries should have the same extension an # archive normally would. oldlibs=3D"$output_objdir/$libname.$libext $oldlibs" build_libtool_libs=3Dconvenience build_old_libs=3Dyes fi if test -n "$vinfo"; then $echo "$modename: warning: \`-version-info/-version-number' is ignored f= or convenience libraries" 1>&2 fi if test -n "$release"; then $echo "$modename: warning: \`-release' is ignored for convenience librar= ies" 1>&2 fi else # Parse the version information argument. save_ifs=3D"$IFS"; IFS=3D':' set dummy $vinfo 0 0 0 IFS=3D"$save_ifs" if test -n "$8"; then $echo "$modename: too many parameters to \`-version-info'" 1>&2 $echo "$help" 1>&2 exit 1 fi # convert absolute version numbers to libtool ages # this retains compatibility with .la files and attempts # to make the code below a bit more comprehensible =09 case $vinfo_number in yes) number_major=3D"$2" number_minor=3D"$3" number_revision=3D"$4" # # There are really only two kinds -- those that # use the current revision as the major version # and those that subtract age and use age as # a minor version. But, then there is irix # which has an extra 1 added just for fun # case $version_type in darwin|linux|osf|windows) current=3D`expr $number_major + $number_minor` age=3D"$number_minor" revision=3D"$number_revision" ;; freebsd-aout|freebsd-elf|sunos) current=3D"$number_major" revision=3D"$number_minor" age=3D"0" ;; irix|nonstopux) current=3D`expr $number_major + $number_minor - 1` age=3D"$number_minor" revision=3D"$number_minor" ;; esac ;; no) current=3D"$2" revision=3D"$3" age=3D"$4" ;; esac # Check that each of the things are valid numbers. case $current in 0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;; *) $echo "$modename: CURRENT \`$current' is not a nonnegative integer" 1>&2 $echo "$modename: \`$vinfo' is not valid version information" 1>&2 exit 1 ;; esac case $revision in 0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;; *) $echo "$modename: REVISION \`$revision' is not a nonnegative integer" 1>= &2 $echo "$modename: \`$vinfo' is not valid version information" 1>&2 exit 1 ;; esac case $age in 0 | [1-9] | [1-9][0-9] | [1-9][0-9][0-9]) ;; *) $echo "$modename: AGE \`$age' is not a nonnegative integer" 1>&2 $echo "$modename: \`$vinfo' is not valid version information" 1>&2 exit 1 ;; esac if test "$age" -gt "$current"; then $echo "$modename: AGE \`$age' is greater than the current interface numb= er \`$current'" 1>&2 $echo "$modename: \`$vinfo' is not valid version information" 1>&2 exit 1 fi # Calculate the version variables. major=3D versuffix=3D verstring=3D case $version_type in none) ;; darwin) # Like Linux, but with the current version available in # verstring for coding it into the library header major=3D.`expr $current - $age` versuffix=3D"$major.$age.$revision" # Darwin ld doesn't like 0 for these options... minor_current=3D`expr $current + 1` verstring=3D"-compatibility_version $minor_current -current_version $min= or_current.$revision" ;; freebsd-aout) major=3D".$current" versuffix=3D".$current.$revision"; ;; freebsd-elf) major=3D".$current" versuffix=3D".$current"; ;; irix | nonstopux) major=3D`expr $current - $age + 1` case $version_type in nonstopux) verstring_prefix=3Dnonstopux ;; *) verstring_prefix=3Dsgi ;; esac verstring=3D"$verstring_prefix$major.$revision" # Add in all the interfaces that we are compatible with. loop=3D$revision while test "$loop" -ne 0; do iface=3D`expr $revision - $loop` loop=3D`expr $loop - 1` verstring=3D"$verstring_prefix$major.$iface:$verstring" done # Before this point, $major must not contain `.'. major=3D.$major versuffix=3D"$major.$revision" ;; linux) major=3D.`expr $current - $age` versuffix=3D"$major.$age.$revision" ;; osf) major=3D.`expr $current - $age` versuffix=3D".$current.$age.$revision" verstring=3D"$current.$age.$revision" # Add in all the interfaces that we are compatible with. loop=3D$age while test "$loop" -ne 0; do iface=3D`expr $current - $loop` loop=3D`expr $loop - 1` verstring=3D"$verstring:${iface}.0" done # Make executables depend on our current version. verstring=3D"$verstring:${current}.0" ;; sunos) major=3D".$current" versuffix=3D".$current.$revision" ;; windows) # Use '-' rather than '.', since we only want one # extension on DOS 8.3 filesystems. major=3D`expr $current - $age` versuffix=3D"-$major" ;; *) $echo "$modename: unknown library version type \`$version_type'" 1>&2 $echo "Fatal configuration error. See the $PACKAGE docs for more inform= ation." 1>&2 exit 1 ;; esac # Clear the version info if we defaulted, and they specified a release. if test -z "$vinfo" && test -n "$release"; then major=3D case $version_type in darwin) # we can't check for "0.0" in archive_cmds due to quoting # problems, so we reset it completely verstring=3D ;; *) verstring=3D"0.0" ;; esac if test "$need_version" =3D no; then versuffix=3D else versuffix=3D".0.0" fi fi # Remove version info from name if versioning should be avoided if test "$avoid_version" =3D yes && test "$need_version" =3D no; then major=3D versuffix=3D verstring=3D"" fi # Check to see if the archive will have undefined symbols. if test "$allow_undefined" =3D yes; then if test "$allow_undefined_flag" =3D unsupported; then $echo "$modename: warning: undefined symbols not allowed in $host shar= ed libraries" 1>&2 build_libtool_libs=3Dno build_old_libs=3Dyes fi else # Don't allow undefined symbols. allow_undefined_flag=3D"$no_undefined_flag" fi fi if test "$mode" !=3D relink; then # Remove our outputs, but don't remove object files since they # may have been created when compiling PIC objects. removelist=3D tempremovelist=3D`$echo "$output_objdir/*"` for p in $tempremovelist; do case $p in *.$objext) ;; $output_objdir/$outputname | $output_objdir/$libname.* | $output_objdi= r/${libname}${release}.*) if echo $p | $EGREP -e "$precious_files_regex" >/dev/null 2>&1 then continue fi removelist=3D"$removelist $p" ;; *) ;; esac done if test -n "$removelist"; then $show "${rm}r $removelist" $run ${rm}r $removelist fi fi # Now set the variables for building old libraries. if test "$build_old_libs" =3D yes && test "$build_libtool_libs" !=3D = convenience ; then oldlibs=3D"$oldlibs $output_objdir/$libname.$libext" # Transform .lo files to .o files. oldobjs=3D"$objs "`$echo "X$libobjs" | $SP2NL | $Xsed -e '/\.'${libext}'$/= d' -e "$lo2o" | $NL2SP` fi # Eliminate all temporary directories. for path in $notinst_path; do lib_search_path=3D`$echo "$lib_search_path " | ${SED} -e 's% $path % %g'` deplibs=3D`$echo "$deplibs " | ${SED} -e 's% -L$path % %g'` dependency_libs=3D`$echo "$dependency_libs " | ${SED} -e 's% -L$path % %g'` done if test -n "$xrpath"; then # If the user specified any rpath flags, then add them. temp_xrpath=3D for libdir in $xrpath; do temp_xrpath=3D"$temp_xrpath -R$libdir" case "$finalize_rpath " in *" $libdir "*) ;; *) finalize_rpath=3D"$finalize_rpath $libdir" ;; esac done if test "$hardcode_into_libs" !=3D yes || test "$build_old_libs" =3D yes; = then dependency_libs=3D"$temp_xrpath $dependency_libs" fi fi # Make sure dlfiles contains only unique files that won't be dlpreope= ned old_dlfiles=3D"$dlfiles" dlfiles=3D for lib in $old_dlfiles; do case " $dlprefiles $dlfiles " in *" $lib "*) ;; *) dlfiles=3D"$dlfiles $lib" ;; esac done # Make sure dlprefiles contains only unique files old_dlprefiles=3D"$dlprefiles" dlprefiles=3D for lib in $old_dlprefiles; do case "$dlprefiles " in *" $lib "*) ;; *) dlprefiles=3D"$dlprefiles $lib" ;; esac done if test "$build_libtool_libs" =3D yes; then if test -n "$rpath"; then case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-beos*) # these systems don't actually have a c library (as such)! ;; *-*-rhapsody* | *-*-darwin1.[012]) # Rhapsody C library is in the System framework deplibs=3D"$deplibs -framework System" ;; *-*-netbsd*) # Don't link with libc until the a.out ld.so is fixed. ;; *-*-openbsd* | *-*-freebsd*) # Do not include libc due to us having libc/libc_r. test "X$arg" =3D "X-lc" && continue ;; *) # Add libc to deplibs on all other systems if necessary. if test "$build_libtool_need_lc" =3D "yes"; then deplibs=3D"$deplibs -lc" fi ;; esac fi # Transform deplibs into only deplibs that can be linked in shared. name_save=3D$name libname_save=3D$libname release_save=3D$release versuffix_save=3D$versuffix major_save=3D$major # I'm not sure if I'm treating the release correctly. I think # release should show up in the -l (ie -lgmp5) so we don't want to # add it in twice. Is that correct? release=3D"" versuffix=3D"" major=3D"" newdeplibs=3D droppeddeps=3Dno case $deplibs_check_method in pass_all) # Don't check for shared/static. Everything works. # This might be a little naive. We might want to check # whether the library exists or not. But this is on # osf3 & osf4 and I'm not really sure... Just # implementing what was already the behavior. newdeplibs=3D$deplibs ;; test_compile) # This code stresses the "libraries are programs" paradigm to its # limits. Maybe even breaks it. We compile a program, linking it # against the deplibs as a proxy for the library. Then we can check # whether they linked in statically or dynamically with ldd. $rm conftest.c cat > conftest.c </dev/null` for potent_lib in $potential_libs; do # Follow soft links. if ls -lLd "$potent_lib" 2>/dev/null \ | grep " -> " >/dev/null; then continue fi # The statement above tries to avoid entering an # endless loop below, in case of cyclic links. # We might still enter an endless loop, since a link # loop can be closed while we follow links, # but so what? potlib=3D"$potent_lib" while test -h "$potlib" 2>/dev/null; do potliblink=3D`ls -ld $potlib | ${SED} 's/.* -> //'` case $potliblink in [\\/]* | [A-Za-z]:[\\/]*) potlib=3D"$potliblink";; *) potlib=3D`$echo "X$potlib" | $Xsed -e 's,[^/]*$,,'`"$potliblink";; esac done if eval $file_magic_cmd \"\$potlib\" 2>/dev/null \ | ${SED} 10q \ | $EGREP "$file_magic_regex" > /dev/null; then newdeplibs=3D"$newdeplibs $a_deplib" a_deplib=3D"" break 2 fi done done fi if test -n "$a_deplib" ; then droppeddeps=3Dyes $echo $echo "*** Warning: linker path does not have real file for library $a_de= plib." $echo "*** I have the capability to make that library automatically link = in when" $echo "*** you link to this library. But I can only do this if you have = a" $echo "*** shared version of the library, which you do not appear to have" $echo "*** because I did check the linker path looking for a file startin= g" if test -z "$potlib" ; then $echo "*** with $libname but no candidates were found. (...for file mag= ic test)" else $echo "*** with $libname and none of the candidates passed a file forma= t test" $echo "*** using a file magic. Last file checked: $potlib" fi fi else # Add a -L argument. newdeplibs=3D"$newdeplibs $a_deplib" fi done # Gone through all deplibs. ;; match_pattern*) set dummy $deplibs_check_method match_pattern_regex=3D`expr "$deplibs_check_method" : "$2 \(.*\)"` for a_deplib in $deplibs; do name=3D"`expr $a_deplib : '-l\(.*\)'`" # If $name is empty we are operating on a -L argument. if test -n "$name" && test "$name" !=3D "0"; then if test "X$allow_libtool_libs_with_static_runtimes" =3D "Xyes" ; then case " $predeps $postdeps " in *" $a_deplib "*) newdeplibs=3D"$newdeplibs $a_deplib" a_deplib=3D"" ;; esac fi if test -n "$a_deplib" ; then libname=3D`eval \\$echo \"$libname_spec\"` for i in $lib_search_path $sys_lib_search_path $shlib_search_path; do potential_libs=3D`ls $i/$libname[.-]* 2>/dev/null` for potent_lib in $potential_libs; do potlib=3D"$potent_lib" # see symlink-check above in file_magic test if eval $echo \"$potent_lib\" 2>/dev/null \ | ${SED} 10q \ | $EGREP "$match_pattern_regex" > /dev/null; then newdeplibs=3D"$newdeplibs $a_deplib" a_deplib=3D"" break 2 fi done done fi if test -n "$a_deplib" ; then droppeddeps=3Dyes $echo $echo "*** Warning: linker path does not have real file for library $a_de= plib." $echo "*** I have the capability to make that library automatically link = in when" $echo "*** you link to this library. But I can only do this if you have = a" $echo "*** shared version of the library, which you do not appear to have" $echo "*** because I did check the linker path looking for a file startin= g" if test -z "$potlib" ; then $echo "*** with $libname but no candidates were found. (...for regex pa= ttern test)" else $echo "*** with $libname and none of the candidates passed a file forma= t test" $echo "*** using a regex pattern. Last file checked: $potlib" fi fi else # Add a -L argument. newdeplibs=3D"$newdeplibs $a_deplib" fi done # Gone through all deplibs. ;; none | unknown | *) newdeplibs=3D"" tmp_deplibs=3D`$echo "X $deplibs" | $Xsed -e 's/ -lc$//' \ -e 's/ -[LR][^ ]*//g'` if test "X$allow_libtool_libs_with_static_runtimes" =3D "Xyes" ; then for i in $predeps $postdeps ; do # can't use Xsed below, because $i might contain '/' tmp_deplibs=3D`$echo "X $tmp_deplibs" | ${SED} -e "1s,^X,," -e "s,$i= ,,"` done fi if $echo "X $tmp_deplibs" | $Xsed -e 's/[ ]//g' \ | grep . >/dev/null; then $echo if test "X$deplibs_check_method" =3D "Xnone"; then $echo "*** Warning: inter-library dependencies are not supported in = this platform." else $echo "*** Warning: inter-library dependencies are not known to be s= upported." fi $echo "*** All declared inter-library dependencies are being dropped." droppeddeps=3Dyes fi ;; esac versuffix=3D$versuffix_save major=3D$major_save release=3D$release_save libname=3D$libname_save name=3D$name_save case $host in *-*-rhapsody* | *-*-darwin1.[012]) # On Rhapsody replace the C library is the System framework newdeplibs=3D`$echo "X $newdeplibs" | $Xsed -e 's/ -lc / -framework Syst= em /'` ;; esac if test "$droppeddeps" =3D yes; then if test "$module" =3D yes; then $echo $echo "*** Warning: libtool could not satisfy all declared inter-libra= ry" $echo "*** dependencies of module $libname. Therefore, libtool will c= reate" $echo "*** a static module, that should work as long as the dlopening" $echo "*** application is linked with the -dlopen flag." if test -z "$global_symbol_pipe"; then $echo $echo "*** However, this would only work if libtool was able to extr= act symbol" $echo "*** lists from a program, using \`nm' or equivalent, but libt= ool could" $echo "*** not find such a program. So, this module is probably use= less." $echo "*** \`nm' from GNU binutils and a full rebuild may help." fi if test "$build_old_libs" =3D no; then oldlibs=3D"$output_objdir/$libname.$libext" build_libtool_libs=3Dmodule build_old_libs=3Dyes else build_libtool_libs=3Dno fi else $echo "*** The inter-library dependencies that have been dropped here = will be" $echo "*** automatically added whenever a program is linked with this = library" $echo "*** or is declared to -dlopen it." if test "$allow_undefined" =3D no; then $echo $echo "*** Since this library must not contain undefined symbols," $echo "*** because either the platform does not support them or" $echo "*** it was explicitly requested with -no-undefined," $echo "*** libtool will only create a static version of it." if test "$build_old_libs" =3D no; then oldlibs=3D"$output_objdir/$libname.$libext" build_libtool_libs=3Dmodule build_old_libs=3Dyes else build_libtool_libs=3Dno fi fi fi fi # Done checking deplibs! deplibs=3D$newdeplibs fi # All the library-specific variables (install_libdir is set above). library_names=3D old_library=3D dlname=3D # Test again, we may have decided not to build it any more if test "$build_libtool_libs" =3D yes; then if test "$hardcode_into_libs" =3D yes; then # Hardcode the library paths hardcode_libdirs=3D dep_rpath=3D rpath=3D"$finalize_rpath" test "$mode" !=3D relink && rpath=3D"$compile_rpath$rpath" for libdir in $rpath; do if test -n "$hardcode_libdir_flag_spec"; then if test -n "$hardcode_libdir_separator"; then if test -z "$hardcode_libdirs"; then hardcode_libdirs=3D"$libdir" else # Just accumulate the unique libdirs. case $hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_separa= tor in *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*) ;; *) hardcode_libdirs=3D"$hardcode_libdirs$hardcode_libdir_separator$libdi= r" ;; esac fi else eval flag=3D\"$hardcode_libdir_flag_spec\" dep_rpath=3D"$dep_rpath $flag" fi elif test -n "$runpath_var"; then case "$perm_rpath " in *" $libdir "*) ;; *) perm_rpath=3D"$perm_rpath $libdir" ;; esac fi done # Substitute the hardcoded libdirs into the rpath. if test -n "$hardcode_libdir_separator" && test -n "$hardcode_libdirs"; then libdir=3D"$hardcode_libdirs" if test -n "$hardcode_libdir_flag_spec_ld"; then eval dep_rpath=3D\"$hardcode_libdir_flag_spec_ld\" else eval dep_rpath=3D\"$hardcode_libdir_flag_spec\" fi fi if test -n "$runpath_var" && test -n "$perm_rpath"; then # We should set the runpath_var. rpath=3D for dir in $perm_rpath; do rpath=3D"$rpath$dir:" done eval "$runpath_var=3D'$rpath\$$runpath_var'; export $runpath_var" fi test -n "$dep_rpath" && deplibs=3D"$dep_rpath $deplibs" fi shlibpath=3D"$finalize_shlibpath" test "$mode" !=3D relink && shlibpath=3D"$compile_shlibpath$shlibpath" if test -n "$shlibpath"; then eval "$shlibpath_var=3D'$shlibpath\$$shlibpath_var'; export $shlibpath_v= ar" fi # Get the real and link names of the library. eval shared_ext=3D\"$shrext\" eval library_names=3D\"$library_names_spec\" set dummy $library_names realname=3D"$2" shift; shift if test -n "$soname_spec"; then eval soname=3D\"$soname_spec\" else soname=3D"$realname" fi if test -z "$dlname"; then dlname=3D$soname fi lib=3D"$output_objdir/$realname" for link do linknames=3D"$linknames $link" done # Use standard objects if they are pic test -z "$pic_flag" && libobjs=3D`$echo "X$libobjs" | $SP2NL | $Xsed -e "$= lo2o" | $NL2SP` # Prepare the list of exported symbols if test -z "$export_symbols"; then if test "$always_export_symbols" =3D yes || test -n "$export_symbols_reg= ex"; then $show "generating symbol list for \`$libname.la'" export_symbols=3D"$output_objdir/$libname.exp" $run $rm $export_symbols cmds=3D$export_symbols_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" if len=3D`expr "X$cmd" : ".*"` && test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then $show "$cmd" $run eval "$cmd" || exit $? skipped_export=3Dfalse else # The command line is too long to execute in one step. $show "using reloadable object file for export list..." skipped_export=3D: fi done IFS=3D"$save_ifs" if test -n "$export_symbols_regex"; then $show "$EGREP -e \"$export_symbols_regex\" \"$export_symbols\" > \"$= {export_symbols}T\"" $run eval '$EGREP -e "$export_symbols_regex" "$export_symbols" > "${= export_symbols}T"' $show "$mv \"${export_symbols}T\" \"$export_symbols\"" $run eval '$mv "${export_symbols}T" "$export_symbols"' fi fi fi if test -n "$export_symbols" && test -n "$include_expsyms"; then $run eval '$echo "X$include_expsyms" | $SP2NL >> "$export_symbols"' fi tmp_deplibs=3D for test_deplib in $deplibs; do case " $convenience " in *" $test_deplib "*) ;; *)=20 tmp_deplibs=3D"$tmp_deplibs $test_deplib" ;; esac done deplibs=3D"$tmp_deplibs"=20 if test -n "$convenience"; then if test -n "$whole_archive_flag_spec"; then save_libobjs=3D$libobjs eval libobjs=3D\"\$libobjs $whole_archive_flag_spec\" else gentop=3D"$output_objdir/${outputname}x" $show "${rm}r $gentop" $run ${rm}r "$gentop" $show "$mkdir $gentop" $run $mkdir "$gentop" status=3D$? if test "$status" -ne 0 && test ! -d "$gentop"; then exit $status fi generated=3D"$generated $gentop" for xlib in $convenience; do # Extract the objects. case $xlib in [\\/]* | [A-Za-z]:[\\/]*) xabs=3D"$xlib" ;; *) xabs=3D`pwd`"/$xlib" ;; esac xlib=3D`$echo "X$xlib" | $Xsed -e 's%^.*/%%'` xdir=3D"$gentop/$xlib" $show "${rm}r $xdir" $run ${rm}r "$xdir" $show "$mkdir $xdir" $run $mkdir "$xdir" status=3D$? if test "$status" -ne 0 && test ! -d "$xdir"; then exit $status fi # We will extract separately just the conflicting names and we will = no # longer touch any unique names. It is faster to leave these extract # automatically by $AR in one run. $show "(cd $xdir && $AR x $xabs)" $run eval "(cd \$xdir && $AR x \$xabs)" || exit $? if ($AR t "$xabs" | sort | sort -uc >/dev/null 2>&1); then : else $echo "$modename: warning: object name conflicts; renaming object files" = 1>&2 $echo "$modename: warning: to ensure that they will not overwrite" 1>&2 $AR t "$xabs" | sort | uniq -cd | while read -r count name do i=3D1 while test "$i" -le "$count" do # Put our $i before any first dot (extension) # Never overwrite any file name_to=3D"$name" while test "X$name_to" =3D "X$name" || test -f "$xdir/$name_to" do name_to=3D`$echo "X$name_to" | $Xsed -e "s/\([^.]*\)/\1-$i/"` done $show "(cd $xdir && $AR xN $i $xabs '$name' && $mv '$name' '$name_to')" $run eval "(cd \$xdir && $AR xN $i \$xabs '$name' && $mv '$name' '$nam= e_to')" || exit $? i=3D`expr $i + 1` done done fi libobjs=3D"$libobjs "`find $xdir -name \*.$objext -print -o -name \*= =2Elo -print | $NL2SP` done fi fi if test "$thread_safe" =3D yes && test -n "$thread_safe_flag_spec"; then eval flag=3D\"$thread_safe_flag_spec\" linker_flags=3D"$linker_flags $flag" fi # Make a backup of the uninstalled library when relinking if test "$mode" =3D relink; then $run eval '(cd $output_objdir && $rm ${realname}U && $mv $realname ${rea= lname}U)' || exit $? fi # Do each of the archive commands. if test "$module" =3D yes && test -n "$module_cmds" ; then if test -n "$export_symbols" && test -n "$module_expsym_cmds"; then eval test_cmds=3D\"$module_expsym_cmds\" cmds=3D$module_expsym_cmds else eval test_cmds=3D\"$module_cmds\" cmds=3D$module_cmds fi else if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then eval test_cmds=3D\"$archive_expsym_cmds\" cmds=3D$archive_expsym_cmds else eval test_cmds=3D\"$archive_cmds\" cmds=3D$archive_cmds fi fi if test "X$skipped_export" !=3D "X:" && len=3D`expr "X$test_cmds" : ".*"` = && test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then : else # The command line is too long to link in one step, link piecewise. $echo "creating reloadable object files..." # Save the value of $output and $libobjs because we want to # use them later. If we have whole_archive_flag_spec, we # want to use save_libobjs as it was before # whole_archive_flag_spec was expanded, because we can't # assume the linker understands whole_archive_flag_spec. # This may have to be revisited, in case too many # convenience libraries get linked in and end up exceeding # the spec. if test -z "$convenience" || test -z "$whole_archive_flag_spec"; then save_libobjs=3D$libobjs fi save_output=3D$output # Clear the reloadable object creation command queue and # initialize k to one. test_cmds=3D concat_cmds=3D objlist=3D delfiles=3D last_robj=3D k=3D1 output=3D$output_objdir/$save_output-${k}.$objext # Loop over the list of objects to be linked. for obj in $save_libobjs do eval test_cmds=3D\"$reload_cmds $objlist $last_robj\" if test "X$objlist" =3D X || { len=3D`expr "X$test_cmds" : ".*"` && test "$len" -le "$max_cmd_len"; }; then objlist=3D"$objlist $obj" else # The command $test_cmds is almost too long, add a # command to the queue. if test "$k" -eq 1 ; then # The first file doesn't have a previous command to add. eval concat_cmds=3D\"$reload_cmds $objlist $last_robj\" else # All subsequent reloadable object files will link in # the last one created. eval concat_cmds=3D\"\$concat_cmds~$reload_cmds $objlist $last_robj\" fi last_robj=3D$output_objdir/$save_output-${k}.$objext k=3D`expr $k + 1` output=3D$output_objdir/$save_output-${k}.$objext objlist=3D$obj len=3D1 fi done # Handle the remaining objects by creating one last # reloadable object file. All subsequent reloadable object # files will link in the last one created. test -z "$concat_cmds" || concat_cmds=3D$concat_cmds~ eval concat_cmds=3D\"\${concat_cmds}$reload_cmds $objlist $last_robj\" if ${skipped_export-false}; then $show "generating symbol list for \`$libname.la'" export_symbols=3D"$output_objdir/$libname.exp" $run $rm $export_symbols libobjs=3D$output # Append the command to create the export file. eval concat_cmds=3D\"\$concat_cmds~$export_symbols_cmds\" fi # Set up a command to remove the reloadale object files # after they are used. i=3D0 while test "$i" -lt "$k" do i=3D`expr $i + 1` delfiles=3D"$delfiles $output_objdir/$save_output-${i}.$objext" done $echo "creating a temporary reloadable object file: $output" # Loop through the commands generated above and execute them. save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $concat_cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" libobjs=3D$output # Restore the value of output. output=3D$save_output if test -n "$convenience" && test -n "$whole_archive_flag_spec"; then eval libobjs=3D\"\$libobjs $whole_archive_flag_spec\" fi # Expand the library linking commands again to reset the # value of $libobjs for piecewise linking. # Do each of the archive commands. if test "$module" =3D yes && test -n "$module_cmds" ; then if test -n "$export_symbols" && test -n "$module_expsym_cmds"; then cmds=3D$module_expsym_cmds else cmds=3D$module_cmds fi else if test -n "$export_symbols" && test -n "$archive_expsym_cmds"; then cmds=3D$archive_expsym_cmds else cmds=3D$archive_cmds fi fi # Append the command to remove the reloadable object files # to the just-reset $cmds. eval cmds=3D\"\$cmds~\$rm $delfiles\" fi save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" # Restore the uninstalled library and exit if test "$mode" =3D relink; then $run eval '(cd $output_objdir && $rm ${realname}T && $mv $realname ${rea= lname}T && $mv "$realname"U $realname)' || exit $? exit 0 fi # Create links to the real library. for linkname in $linknames; do if test "$realname" !=3D "$linkname"; then $show "(cd $output_objdir && $rm $linkname && $LN_S $realname $linknam= e)" $run eval '(cd $output_objdir && $rm $linkname && $LN_S $realname $lin= kname)' || exit $? fi done # If -module or -export-dynamic was specified, set the dlname. if test "$module" =3D yes || test "$export_dynamic" =3D yes; then # On all known operating systems, these are identical. dlname=3D"$soname" fi fi ;; obj) if test -n "$deplibs"; then $echo "$modename: warning: \`-l' and \`-L' are ignored for objects" 1>&2 fi if test -n "$dlfiles$dlprefiles" || test "$dlself" !=3D no; then $echo "$modename: warning: \`-dlopen' is ignored for objects" 1>&2 fi if test -n "$rpath"; then $echo "$modename: warning: \`-rpath' is ignored for objects" 1>&2 fi if test -n "$xrpath"; then $echo "$modename: warning: \`-R' is ignored for objects" 1>&2 fi if test -n "$vinfo"; then $echo "$modename: warning: \`-version-info' is ignored for objects" 1>&2 fi if test -n "$release"; then $echo "$modename: warning: \`-release' is ignored for objects" 1>&2 fi case $output in *.lo) if test -n "$objs$old_deplibs"; then $echo "$modename: cannot build library object \`$output' from non-libtoo= l objects" 1>&2 exit 1 fi libobj=3D"$output" obj=3D`$echo "X$output" | $Xsed -e "$lo2o"` ;; *) libobj=3D obj=3D"$output" ;; esac # Delete the old objects. $run $rm $obj $libobj # Objects from convenience libraries. This assumes # single-version convenience libraries. Whenever we create # different ones for PIC/non-PIC, this we'll have to duplicate # the extraction. reload_conv_objs=3D gentop=3D # reload_cmds runs $LD directly, so let us get rid of # -Wl from whole_archive_flag_spec wl=3D if test -n "$convenience"; then if test -n "$whole_archive_flag_spec"; then eval reload_conv_objs=3D\"\$reload_objs $whole_archive_flag_spec\" else gentop=3D"$output_objdir/${obj}x" $show "${rm}r $gentop" $run ${rm}r "$gentop" $show "$mkdir $gentop" $run $mkdir "$gentop" status=3D$? if test "$status" -ne 0 && test ! -d "$gentop"; then exit $status fi generated=3D"$generated $gentop" for xlib in $convenience; do # Extract the objects. case $xlib in [\\/]* | [A-Za-z]:[\\/]*) xabs=3D"$xlib" ;; *) xabs=3D`pwd`"/$xlib" ;; esac xlib=3D`$echo "X$xlib" | $Xsed -e 's%^.*/%%'` xdir=3D"$gentop/$xlib" $show "${rm}r $xdir" $run ${rm}r "$xdir" $show "$mkdir $xdir" $run $mkdir "$xdir" status=3D$? if test "$status" -ne 0 && test ! -d "$xdir"; then exit $status fi # We will extract separately just the conflicting names and we will no # longer touch any unique names. It is faster to leave these extract # automatically by $AR in one run. $show "(cd $xdir && $AR x $xabs)" $run eval "(cd \$xdir && $AR x \$xabs)" || exit $? if ($AR t "$xabs" | sort | sort -uc >/dev/null 2>&1); then : else $echo "$modename: warning: object name conflicts; renaming object fi= les" 1>&2 $echo "$modename: warning: to ensure that they will not overwrite" 1= >&2 $AR t "$xabs" | sort | uniq -cd | while read -r count name do i=3D1 while test "$i" -le "$count" do # Put our $i before any first dot (extension) # Never overwrite any file name_to=3D"$name" while test "X$name_to" =3D "X$name" || test -f "$xdir/$name_to" do name_to=3D`$echo "X$name_to" | $Xsed -e "s/\([^.]*\)/\1-$i/"` done $show "(cd $xdir && $AR xN $i $xabs '$name' && $mv '$name' '$name_to')" $run eval "(cd \$xdir && $AR xN $i \$xabs '$name' && $mv '$name' '$name_= to')" || exit $? i=3D`expr $i + 1` done done fi reload_conv_objs=3D"$reload_objs "`find $xdir -name \*.$objext -print = -o -name \*.lo -print | $NL2SP` done fi fi # Create the old-style object. reload_objs=3D"$objs$old_deplibs "`$echo "X$libobjs" | $SP2NL | $Xsed= -e '/\.'${libext}$'/d' -e '/\.lib$/d' -e "$lo2o" | $NL2SP`" $reload_conv_o= bjs" ### testsuite: skip nested quoting test output=3D"$obj" cmds=3D$reload_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" # Exit if we aren't doing a library object file. if test -z "$libobj"; then if test -n "$gentop"; then $show "${rm}r $gentop" $run ${rm}r $gentop fi exit 0 fi if test "$build_libtool_libs" !=3D yes; then if test -n "$gentop"; then $show "${rm}r $gentop" $run ${rm}r $gentop fi # Create an invalid libtool object if no PIC, so that we don't # accidentally link it into a program. # $show "echo timestamp > $libobj" # $run eval "echo timestamp > $libobj" || exit $? exit 0 fi if test -n "$pic_flag" || test "$pic_mode" !=3D default; then # Only do commands if we really have different PIC objects. reload_objs=3D"$libobjs $reload_conv_objs" output=3D"$libobj" cmds=3D$reload_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" fi if test -n "$gentop"; then $show "${rm}r $gentop" $run ${rm}r $gentop fi exit 0 ;; prog) case $host in *cygwin*) output=3D`$echo $output | ${SED} -e 's,.exe$,,;s,$,.exe,'` ;; esac if test -n "$vinfo"; then $echo "$modename: warning: \`-version-info' is ignored for programs" 1>&2 fi if test -n "$release"; then $echo "$modename: warning: \`-release' is ignored for programs" 1>&2 fi if test "$preload" =3D yes; then if test "$dlopen_support" =3D unknown && test "$dlopen_self" =3D unknown && test "$dlopen_self_static" =3D unknown; then $echo "$modename: warning: \`AC_LIBTOOL_DLOPEN' not used. Assuming no dl= open support." fi fi case $host in *-*-rhapsody* | *-*-darwin1.[012]) # On Rhapsody replace the C library is the System framework compile_deplibs=3D`$echo "X $compile_deplibs" | $Xsed -e 's/ -lc / -framew= ork System /'` finalize_deplibs=3D`$echo "X $finalize_deplibs" | $Xsed -e 's/ -lc / -fram= ework System /'` ;; esac case $host in *darwin*) # Don't allow lazy linking, it breaks C++ global constructors if test "$tagname" =3D CXX ; then compile_command=3D"$compile_command ${wl}-bind_at_load" finalize_command=3D"$finalize_command ${wl}-bind_at_load" fi ;; esac compile_command=3D"$compile_command $compile_deplibs" finalize_command=3D"$finalize_command $finalize_deplibs" if test -n "$rpath$xrpath"; then # If the user specified any rpath flags, then add them. for libdir in $rpath $xrpath; do # This is the magic to use -rpath. case "$finalize_rpath " in *" $libdir "*) ;; *) finalize_rpath=3D"$finalize_rpath $libdir" ;; esac done fi # Now hardcode the library paths rpath=3D hardcode_libdirs=3D for libdir in $compile_rpath $finalize_rpath; do if test -n "$hardcode_libdir_flag_spec"; then if test -n "$hardcode_libdir_separator"; then if test -z "$hardcode_libdirs"; then hardcode_libdirs=3D"$libdir" else # Just accumulate the unique libdirs. case $hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_sep= arator in *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*) ;; *) hardcode_libdirs=3D"$hardcode_libdirs$hardcode_libdir_separator$libdir" ;; esac fi else eval flag=3D\"$hardcode_libdir_flag_spec\" rpath=3D"$rpath $flag" fi elif test -n "$runpath_var"; then case "$perm_rpath " in *" $libdir "*) ;; *) perm_rpath=3D"$perm_rpath $libdir" ;; esac fi case $host in *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*) case :$dllsearchpath: in *":$libdir:"*) ;; *) dllsearchpath=3D"$dllsearchpath:$libdir";; esac ;; esac done # Substitute the hardcoded libdirs into the rpath. if test -n "$hardcode_libdir_separator" && test -n "$hardcode_libdirs"; then libdir=3D"$hardcode_libdirs" eval rpath=3D\" $hardcode_libdir_flag_spec\" fi compile_rpath=3D"$rpath" rpath=3D hardcode_libdirs=3D for libdir in $finalize_rpath; do if test -n "$hardcode_libdir_flag_spec"; then if test -n "$hardcode_libdir_separator"; then if test -z "$hardcode_libdirs"; then hardcode_libdirs=3D"$libdir" else # Just accumulate the unique libdirs. case $hardcode_libdir_separator$hardcode_libdirs$hardcode_libdir_sep= arator in *"$hardcode_libdir_separator$libdir$hardcode_libdir_separator"*) ;; *) hardcode_libdirs=3D"$hardcode_libdirs$hardcode_libdir_separator$libdir" ;; esac fi else eval flag=3D\"$hardcode_libdir_flag_spec\" rpath=3D"$rpath $flag" fi elif test -n "$runpath_var"; then case "$finalize_perm_rpath " in *" $libdir "*) ;; *) finalize_perm_rpath=3D"$finalize_perm_rpath $libdir" ;; esac fi done # Substitute the hardcoded libdirs into the rpath. if test -n "$hardcode_libdir_separator" && test -n "$hardcode_libdirs"; then libdir=3D"$hardcode_libdirs" eval rpath=3D\" $hardcode_libdir_flag_spec\" fi finalize_rpath=3D"$rpath" if test -n "$libobjs" && test "$build_old_libs" =3D yes; then # Transform all the library objects into standard objects. compile_command=3D`$echo "X$compile_command" | $SP2NL | $Xsed -e "$lo2o" |= $NL2SP` finalize_command=3D`$echo "X$finalize_command" | $SP2NL | $Xsed -e "$lo2o"= | $NL2SP` fi dlsyms=3D if test -n "$dlfiles$dlprefiles" || test "$dlself" !=3D no; then if test -n "$NM" && test -n "$global_symbol_pipe"; then dlsyms=3D"${outputname}S.c" else $echo "$modename: not configured to extract global symbols from dlpreope= ned files" 1>&2 fi fi if test -n "$dlsyms"; then case $dlsyms in "") ;; *.c) # Discover the nlist of each of the dlfiles. nlist=3D"$output_objdir/${outputname}.nm" $show "$rm $nlist ${nlist}S ${nlist}T" $run $rm "$nlist" "${nlist}S" "${nlist}T" # Parse the name list into a source file. $show "creating $output_objdir/$dlsyms" test -z "$run" && $echo > "$output_objdir/$dlsyms" "\ /* $dlsyms - symbol resolution table for \`$outputname' dlsym emulation. */ /* Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP */ #ifdef __cplusplus extern \"C\" { #endif /* Prevent the only kind of declaration conflicts we can make. */ #define lt_preloaded_symbols some_other_symbol /* External symbol declarations for the compiler. */\ " if test "$dlself" =3D yes; then $show "generating symbol list for \`$output'" test -z "$run" && $echo ': @PROGRAM@ ' > "$nlist" # Add our own program objects to the symbol list. progfiles=3D`$echo "X$objs$old_deplibs" | $SP2NL | $Xsed -e "$lo2o" | = $NL2SP` for arg in $progfiles; do $show "extracting global C symbols from \`$arg'" $run eval "$NM $arg | $global_symbol_pipe >> '$nlist'" done if test -n "$exclude_expsyms"; then $run eval '$EGREP -v " ($exclude_expsyms)$" "$nlist" > "$nlist"T' $run eval '$mv "$nlist"T "$nlist"' fi if test -n "$export_symbols_regex"; then $run eval '$EGREP -e "$export_symbols_regex" "$nlist" > "$nlist"T' $run eval '$mv "$nlist"T "$nlist"' fi # Prepare the list of exported symbols if test -z "$export_symbols"; then export_symbols=3D"$output_objdir/$output.exp" $run $rm $export_symbols $run eval "${SED} -n -e '/^: @PROGRAM@$/d' -e 's/^.* \(.*\)$/\1/p' "= '< "$nlist" > "$export_symbols"' else $run eval "${SED} -e 's/\([][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'= "' < "$export_symbols" > "$output_objdir/$output.exp"' $run eval 'grep -f "$output_objdir/$output.exp" < "$nlist" > "$nlist= "T' $run eval 'mv "$nlist"T "$nlist"' fi fi for arg in $dlprefiles; do $show "extracting global C symbols from \`$arg'" name=3D`$echo "$arg" | ${SED} -e 's%^.*/%%'` $run eval '$echo ": $name " >> "$nlist"' $run eval "$NM $arg | $global_symbol_pipe >> '$nlist'" done if test -z "$run"; then # Make sure we have at least an empty file. test -f "$nlist" || : > "$nlist" if test -n "$exclude_expsyms"; then $EGREP -v " ($exclude_expsyms)$" "$nlist" > "$nlist"T $mv "$nlist"T "$nlist" fi # Try sorting and uniquifying the output. if grep -v "^: " < "$nlist" | if sort -k 3 /dev/null 2>&1; then sort -k 3 else sort +2 fi | uniq > "$nlist"S; then : else grep -v "^: " < "$nlist" > "$nlist"S fi if test -f "$nlist"S; then eval "$global_symbol_to_cdecl"' < "$nlist"S >> "$output_objdir/$dlsy= ms"' else $echo '/* NONE */' >> "$output_objdir/$dlsyms" fi $echo >> "$output_objdir/$dlsyms" "\ #undef lt_preloaded_symbols #if defined (__STDC__) && __STDC__ # define lt_ptr void * #else # define lt_ptr char * # define const #endif /* The mapping between symbol names and symbols. */ const struct { const char *name; lt_ptr address; } lt_preloaded_symbols[] =3D {\ " eval "$global_symbol_to_c_name_address" < "$nlist" >> "$output_objdir/= $dlsyms" $echo >> "$output_objdir/$dlsyms" "\ {0, (lt_ptr) 0} }; /* This works around a problem in FreeBSD linker */ #ifdef FREEBSD_WORKAROUND static const void *lt_preloaded_setup() { return lt_preloaded_symbols; } #endif #ifdef __cplusplus } #endif\ " fi pic_flag_for_symtable=3D case $host in # compiling the symbol table file with pic_flag works around # a FreeBSD bug that causes programs to crash when -lm is # linked before any other PIC object. But we must not use # pic_flag when linking with -static. The problem exists in # FreeBSD 2.2.6 and is fixed in FreeBSD 3.1. *-*-freebsd2*|*-*-freebsd3.0*|*-*-freebsdelf3.0*) case "$compile_command " in *" -static "*) ;; *) pic_flag_for_symtable=3D" $pic_flag -DFREEBSD_WORKAROUND";; esac;; *-*-hpux*) case "$compile_command " in *" -static "*) ;; *) pic_flag_for_symtable=3D" $pic_flag";; esac esac # Now compile the dynamic symbol file. $show "(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symta= ble \"$dlsyms\")" $run eval '(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_s= ymtable "$dlsyms")' || exit $? # Clean up the generated files. $show "$rm $output_objdir/$dlsyms $nlist ${nlist}S ${nlist}T" $run $rm "$output_objdir/$dlsyms" "$nlist" "${nlist}S" "${nlist}T" # Transform the symbol file into the correct name. compile_command=3D`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$ou= tput_objdir/${outputname}S.${objext}%"` finalize_command=3D`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$= output_objdir/${outputname}S.${objext}%"` ;; *) $echo "$modename: unknown suffix for \`$dlsyms'" 1>&2 exit 1 ;; esac else # We keep going just in case the user didn't refer to # lt_preloaded_symbols. The linker will fail if global_symbol_pipe # really was required. # Nullify the symbol file. compile_command=3D`$echo "X$compile_command" | $Xsed -e "s% @SYMFILE@%%"` finalize_command=3D`$echo "X$finalize_command" | $Xsed -e "s% @SYMFILE@%%"` fi if test "$need_relink" =3D no || test "$build_libtool_libs" !=3D yes;= then # Replace the output file specification. compile_command=3D`$echo "X$compile_command" | $Xsed -e 's%@OUTPUT@%'"$out= put"'%g'` link_command=3D"$compile_command$compile_rpath" # We have no uninstalled library dependencies, so finalize right now. $show "$link_command" $run eval "$link_command" status=3D$? # Delete the generated files. if test -n "$dlsyms"; then $show "$rm $output_objdir/${outputname}S.${objext}" $run $rm "$output_objdir/${outputname}S.${objext}" fi exit $status fi if test -n "$shlibpath_var"; then # We should set the shlibpath_var rpath=3D for dir in $temp_rpath; do case $dir in [\\/]* | [A-Za-z]:[\\/]*) # Absolute path. rpath=3D"$rpath$dir:" ;; *) # Relative path: add a thisdir entry. rpath=3D"$rpath\$thisdir/$dir:" ;; esac done temp_rpath=3D"$rpath" fi if test -n "$compile_shlibpath$finalize_shlibpath"; then compile_command=3D"$shlibpath_var=3D\"$compile_shlibpath$finalize_shlibpat= h\$$shlibpath_var\" $compile_command" fi if test -n "$finalize_shlibpath"; then finalize_command=3D"$shlibpath_var=3D\"$finalize_shlibpath\$$shlibpath_var= \" $finalize_command" fi compile_var=3D finalize_var=3D if test -n "$runpath_var"; then if test -n "$perm_rpath"; then # We should set the runpath_var. rpath=3D for dir in $perm_rpath; do rpath=3D"$rpath$dir:" done compile_var=3D"$runpath_var=3D\"$rpath\$$runpath_var\" " fi if test -n "$finalize_perm_rpath"; then # We should set the runpath_var. rpath=3D for dir in $finalize_perm_rpath; do rpath=3D"$rpath$dir:" done finalize_var=3D"$runpath_var=3D\"$rpath\$$runpath_var\" " fi fi if test "$no_install" =3D yes; then # We don't need to create a wrapper script. link_command=3D"$compile_var$compile_command$compile_rpath" # Replace the output file specification. link_command=3D`$echo "X$link_command" | $Xsed -e 's%@OUTPUT@%'"$output"'%= g'` # Delete the old output file. $run $rm $output # Link the executable and exit $show "$link_command" $run eval "$link_command" || exit $? exit 0 fi if test "$hardcode_action" =3D relink; then # Fast installation is not supported link_command=3D"$compile_var$compile_command$compile_rpath" relink_command=3D"$finalize_var$finalize_command$finalize_rpath" $echo "$modename: warning: this platform does not like uninstalled shared = libraries" 1>&2 $echo "$modename: \`$output' will be relinked during installation" 1>&2 else if test "$fast_install" !=3D no; then link_command=3D"$finalize_var$compile_command$finalize_rpath" if test "$fast_install" =3D yes; then relink_command=3D`$echo "X$compile_var$compile_command$compile_rpath" = | $Xsed -e 's%@OUTPUT@%\$progdir/\$file%g'` else # fast_install is set to needless relink_command=3D fi else link_command=3D"$compile_var$compile_command$compile_rpath" relink_command=3D"$finalize_var$finalize_command$finalize_rpath" fi fi # Replace the output file specification. link_command=3D`$echo "X$link_command" | $Xsed -e 's%@OUTPUT@%'"$outp= ut_objdir/$outputname"'%g'` # Delete the old output files. $run $rm $output $output_objdir/$outputname $output_objdir/lt-$output= name $show "$link_command" $run eval "$link_command" || exit $? # Now create the wrapper script. $show "creating $output" # Quote the relink command for shipping. if test -n "$relink_command"; then # Preserve any variables that may affect compiler behavior for var in $variables_saved_for_relink; do if eval test -z \"\${$var+set}\"; then relink_command=3D"{ test -z \"\${$var+set}\" || unset $var || { $var= =3D; export $var; }; }; $relink_command" elif eval var_value=3D\$$var; test -z "$var_value"; then relink_command=3D"$var=3D; export $var; $relink_command" else var_value=3D`$echo "X$var_value" | $Xsed -e "$sed_quote_subst"` relink_command=3D"$var=3D\"$var_value\"; export $var; $relink_command" fi done relink_command=3D"(cd `pwd`; $relink_command)" relink_command=3D`$echo "X$relink_command" | $Xsed -e "$sed_quote_subst"` fi # Quote $echo for shipping. if test "X$echo" =3D "X$SHELL $0 --fallback-echo"; then case $0 in [\\/]* | [A-Za-z]:[\\/]*) qecho=3D"$SHELL $0 --fallback-echo";; *) qecho=3D"$SHELL `pwd`/$0 --fallback-echo";; esac qecho=3D`$echo "X$qecho" | $Xsed -e "$sed_quote_subst"` else qecho=3D`$echo "X$echo" | $Xsed -e "$sed_quote_subst"` fi # Only actually do things if our run command is non-null. if test -z "$run"; then # win32 will think the script is a binary if it has # a .exe suffix, so we strip it off here. case $output in *.exe) output=3D`$echo $output|${SED} 's,.exe$,,'` ;; esac # test for cygwin because mv fails w/o .exe extensions case $host in *cygwin*) exeext=3D.exe outputname=3D`$echo $outputname|${SED} 's,.exe$,,'` ;; *) exeext=3D ;; esac case $host in *cygwin* | *mingw* ) cwrappersource=3D`$echo ${objdir}/lt-${output}.c` cwrapper=3D`$echo ${output}.exe` $rm $cwrappersource $cwrapper trap "$rm $cwrappersource $cwrapper; exit 1" 1 2 15 cat > $cwrappersource <> $cwrappersource<<"EOF" #include #include #include #include #include #include #if defined(PATH_MAX) # define LT_PATHMAX PATH_MAX #elif defined(MAXPATHLEN) # define LT_PATHMAX MAXPATHLEN #else # define LT_PATHMAX 1024 #endif #ifndef DIR_SEPARATOR #define DIR_SEPARATOR '/' #endif #if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \ defined (__OS2__) #define HAVE_DOS_BASED_FILE_SYSTEM #ifndef DIR_SEPARATOR_2=20 #define DIR_SEPARATOR_2 '\\' #endif #endif #ifndef DIR_SEPARATOR_2 # define IS_DIR_SEPARATOR(ch) ((ch) =3D=3D DIR_SEPARATOR) #else /* DIR_SEPARATOR_2 */ # define IS_DIR_SEPARATOR(ch) \ (((ch) =3D=3D DIR_SEPARATOR) || ((ch) =3D=3D DIR_SEPARATOR_2)) #endif /* DIR_SEPARATOR_2 */ #define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type))) #define XFREE(stale) do { \ if (stale) { free ((void *) stale); stale =3D 0; } \ } while (0) const char *program_name =3D NULL; void * xmalloc (size_t num); char * xstrdup (const char *string); char * basename (const char *name); char * fnqualify(const char *path); char * strendzap(char *str, const char *pat); void lt_fatal (const char *message, ...); int main (int argc, char *argv[]) { char **newargz; int i; =20 program_name =3D (char *) xstrdup ((char *) basename (argv[0])); newargz =3D XMALLOC(char *, argc+2); EOF cat >> $cwrappersource <> $cwrappersource <<"EOF" newargz[1] =3D fnqualify(argv[0]); /* we know the script has the same name, without the .exe */ /* so make sure newargz[1] doesn't end in .exe */ strendzap(newargz[1],".exe");=20 for (i =3D 1; i < argc; i++) newargz[i+1] =3D xstrdup(argv[i]); newargz[argc+1] =3D NULL; EOF cat >> $cwrappersource <> $cwrappersource <<"EOF" } void * xmalloc (size_t num) { void * p =3D (void *) malloc (num); if (!p) lt_fatal ("Memory exhausted"); return p; } char *=20 xstrdup (const char *string) { return string ? strcpy ((char *) xmalloc (strlen (string) + 1), string) := NULL ; } char * basename (const char *name) { const char *base; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) /* Skip over the disk name in MSDOS pathnames. */ if (isalpha (name[0]) && name[1] =3D=3D ':')=20 name +=3D 2; #endif for (base =3D name; *name; name++) if (IS_DIR_SEPARATOR (*name)) base =3D name + 1; return (char *) base; } char *=20 fnqualify(const char *path) { size_t size; char *p; char tmp[LT_PATHMAX + 1]; assert(path !=3D NULL); /* Is it qualified already? */ #if defined (HAVE_DOS_BASED_FILE_SYSTEM) if (isalpha (path[0]) && path[1] =3D=3D ':') return xstrdup (path); #endif if (IS_DIR_SEPARATOR (path[0])) return xstrdup (path); /* prepend the current directory */ /* doesn't handle '~' */ if (getcwd (tmp, LT_PATHMAX) =3D=3D NULL) lt_fatal ("getcwd failed"); size =3D strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */ p =3D XMALLOC(char, size); sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path); return p; } char * strendzap(char *str, const char *pat)=20 { size_t len, patlen; assert(str !=3D NULL); assert(pat !=3D NULL); len =3D strlen(str); patlen =3D strlen(pat); if (patlen <=3D len) { str +=3D len - patlen; if (strcmp(str, pat) =3D=3D 0) *str =3D '\0'; } return str; } static void lt_error_core (int exit_status, const char * mode,=20 const char * message, va_list ap) { fprintf (stderr, "%s: %s: ", program_name, mode); vfprintf (stderr, message, ap); fprintf (stderr, ".\n"); if (exit_status >=3D 0) exit (exit_status); } void lt_fatal (const char *message, ...) { va_list ap; va_start (ap, message); lt_error_core (EXIT_FAILURE, "FATAL", message, ap); va_end (ap); } EOF # we should really use a build-platform specific compiler # here, but OTOH, the wrappers (shell script and this C one) # are only useful if you want to execute the "real" binary. # Since the "real" binary is built for $host, then this # wrapper might as well be built for $host, too. $run $LTCC -s -o $cwrapper $cwrappersource ;; esac $rm $output trap "$rm $output; exit 1" 1 2 15 $echo > $output "\ #! $SHELL # $output - temporary wrapper script for $objdir/$outputname # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # # The $output program cannot be directly executed until all the libtool # libraries that it depends on are installed. # # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. # Sed substitution that helps us do robust quoting. It backslashifies # metacharacters that are still active within double-quoted strings. Xsed=3D'${SED} -e 1s/^X//' sed_quote_subst=3D'$sed_quote_subst' # The HP-UX ksh and POSIX shell print the target directory to stdout # if CDPATH is set. if test \"\${CDPATH+set}\" =3D set; then CDPATH=3D:; export CDPATH; fi relink_command=3D\"$relink_command\" # This environment variable determines our operation mode. if test \"\$libtool_install_magic\" =3D \"$magic\"; then # install mode needs the following variable: notinst_deplibs=3D'$notinst_deplibs' else # When we are sourced in execute mode, \$file and \$echo are already set. if test \"\$libtool_execute_magic\" !=3D \"$magic\"; then echo=3D\"$qecho\" file=3D\"\$0\" # Make sure echo works. if test \"X\$1\" =3D X--no-reexec; then # Discard the --no-reexec flag, and continue. shift elif test \"X\`(\$echo '\t') 2>/dev/null\`\" =3D 'X\t'; then # Yippee, \$echo works! : else # Restart under the correct shell, and then maybe \$echo will work. exec $SHELL \"\$0\" --no-reexec \${1+\"\$@\"} fi fi\ " $echo >> $output "\ # Find the directory that this script lives in. thisdir=3D\`\$echo \"X\$file\" | \$Xsed -e 's%/[^/]*$%%'\` test \"x\$thisdir\" =3D \"x\$file\" && thisdir=3D. # Follow symbolic links until we get to the real thisdir. file=3D\`ls -ld \"\$file\" | ${SED} -n 's/.*-> //p'\` while test -n \"\$file\"; do destdir=3D\`\$echo \"X\$file\" | \$Xsed -e 's%/[^/]*\$%%'\` # If there was a directory component, then change thisdir. if test \"x\$destdir\" !=3D \"x\$file\"; then case \"\$destdir\" in [\\\\/]* | [A-Za-z]:[\\\\/]*) thisdir=3D\"\$destdir\" ;; *) thisdir=3D\"\$thisdir/\$destdir\" ;; esac fi file=3D\`\$echo \"X\$file\" | \$Xsed -e 's%^.*/%%'\` file=3D\`ls -ld \"\$thisdir/\$file\" | ${SED} -n 's/.*-> //p'\` done # Try to get the absolute directory name. absdir=3D\`cd \"\$thisdir\" && pwd\` test -n \"\$absdir\" && thisdir=3D\"\$absdir\" " if test "$fast_install" =3D yes; then $echo >> $output "\ program=3Dlt-'$outputname'$exeext progdir=3D\"\$thisdir/$objdir\" if test ! -f \"\$progdir/\$program\" || \\ { file=3D\`ls -1dt \"\$progdir/\$program\" \"\$progdir/../\$program\" = 2>/dev/null | ${SED} 1q\`; \\ test \"X\$file\" !=3D \"X\$progdir/\$program\"; }; then file=3D\"\$\$-\$program\" if test ! -d \"\$progdir\"; then $mkdir \"\$progdir\" else $rm \"\$progdir/\$file\" fi" $echo >> $output "\ # relink executable if necessary if test -n \"\$relink_command\"; then if relink_command_output=3D\`eval \$relink_command 2>&1\`; then : else $echo \"\$relink_command_output\" >&2 $rm \"\$progdir/\$file\" exit 1 fi fi $mv \"\$progdir/\$file\" \"\$progdir/\$program\" 2>/dev/null || { $rm \"\$progdir/\$program\"; $mv \"\$progdir/\$file\" \"\$progdir/\$program\"; } $rm \"\$progdir/\$file\" fi" else $echo >> $output "\ program=3D'$outputname' progdir=3D\"\$thisdir/$objdir\" " fi $echo >> $output "\ if test -f \"\$progdir/\$program\"; then" # Export our shlibpath_var if we have one. if test "$shlibpath_overrides_runpath" =3D yes && test -n "$shlibpath_var"= && test -n "$temp_rpath"; then $echo >> $output "\ # Add our own library path to $shlibpath_var $shlibpath_var=3D\"$temp_rpath\$$shlibpath_var\" # Some systems cannot cope with colon-terminated $shlibpath_var # The second colon is a workaround for a bug in BeOS R4 sed $shlibpath_var=3D\`\$echo \"X\$$shlibpath_var\" | \$Xsed -e 's/::*\$//'= \` export $shlibpath_var " fi # fixup the dll searchpath if we need to. if test -n "$dllsearchpath"; then $echo >> $output "\ # Add the dll search path components to the executable PATH PATH=3D$dllsearchpath:\$PATH " fi $echo >> $output "\ if test \"\$libtool_execute_magic\" !=3D \"$magic\"; then # Run the actual program with our arguments. " case $host in # Backslashes separate directories on plain windows *-*-mingw | *-*-os2*) $echo >> $output "\ exec \$progdir\\\\\$program \${1+\"\$@\"} " ;; *) $echo >> $output "\ exec \$progdir/\$program \${1+\"\$@\"} " ;; esac $echo >> $output "\ \$echo \"\$0: cannot exec \$program \${1+\"\$@\"}\" exit 1 fi else # The program doesn't exist. \$echo \"\$0: error: \$progdir/\$program does not exist\" 1>&2 \$echo \"This script is just a wrapper for \$program.\" 1>&2 $echo \"See the $PACKAGE documentation for more information.\" 1>&2 exit 1 fi fi\ " chmod +x $output fi exit 0 ;; esac # See if we need to build an old-fashioned archive. for oldlib in $oldlibs; do if test "$build_libtool_libs" =3D convenience; then oldobjs=3D"$libobjs_save" addlibs=3D"$convenience" build_libtool_libs=3Dno else if test "$build_libtool_libs" =3D module; then oldobjs=3D"$libobjs_save" build_libtool_libs=3Dno else oldobjs=3D"$old_deplibs $non_pic_objects" fi addlibs=3D"$old_convenience" fi if test -n "$addlibs"; then gentop=3D"$output_objdir/${outputname}x" $show "${rm}r $gentop" $run ${rm}r "$gentop" $show "$mkdir $gentop" $run $mkdir "$gentop" status=3D$? if test "$status" -ne 0 && test ! -d "$gentop"; then exit $status fi generated=3D"$generated $gentop" # Add in members from convenience archives. for xlib in $addlibs; do # Extract the objects. case $xlib in [\\/]* | [A-Za-z]:[\\/]*) xabs=3D"$xlib" ;; *) xabs=3D`pwd`"/$xlib" ;; esac xlib=3D`$echo "X$xlib" | $Xsed -e 's%^.*/%%'` xdir=3D"$gentop/$xlib" $show "${rm}r $xdir" $run ${rm}r "$xdir" $show "$mkdir $xdir" $run $mkdir "$xdir" status=3D$? if test "$status" -ne 0 && test ! -d "$xdir"; then exit $status fi # We will extract separately just the conflicting names and we will no # longer touch any unique names. It is faster to leave these extract # automatically by $AR in one run. $show "(cd $xdir && $AR x $xabs)" $run eval "(cd \$xdir && $AR x \$xabs)" || exit $? if ($AR t "$xabs" | sort | sort -uc >/dev/null 2>&1); then : else $echo "$modename: warning: object name conflicts; renaming object file= s" 1>&2 $echo "$modename: warning: to ensure that they will not overwrite" 1>&2 $AR t "$xabs" | sort | uniq -cd | while read -r count name do i=3D1 while test "$i" -le "$count" do # Put our $i before any first dot (extension) # Never overwrite any file name_to=3D"$name" while test "X$name_to" =3D "X$name" || test -f "$xdir/$name_to" do name_to=3D`$echo "X$name_to" | $Xsed -e "s/\([^.]*\)/\1-$i/"` done $show "(cd $xdir && $AR xN $i $xabs '$name' && $mv '$name' '$name_t= o')" $run eval "(cd \$xdir && $AR xN $i \$xabs '$name' && $mv '$name' '$= name_to')" || exit $? i=3D`expr $i + 1` done done fi oldobjs=3D"$oldobjs "`find $xdir -name \*.${objext} -print -o -name \*.l= o -print | $NL2SP` done fi # Do each command in the archive commands. if test -n "$old_archive_from_new_cmds" && test "$build_libtool_libs"= =3D yes; then cmds=3D$old_archive_from_new_cmds else eval cmds=3D\"$old_archive_cmds\" if len=3D`expr "X$cmds" : ".*"` && test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then cmds=3D$old_archive_cmds else # the command line is too long to link in one step, link in parts $echo "using piecewise archive linking..." save_RANLIB=3D$RANLIB RANLIB=3D: objlist=3D concat_cmds=3D save_oldobjs=3D$oldobjs # GNU ar 2.10+ was changed to match POSIX; thus no paths are # encoded into archives. This makes 'ar r' malfunction in # this piecewise linking case whenever conflicting object # names appear in distinct ar calls; check, warn and compensate. if (for obj in $save_oldobjs do $echo "X$obj" | $Xsed -e 's%^.*/%%' done | sort | sort -uc >/dev/null 2>&1); then : else $echo "$modename: warning: object name conflicts; overriding AR_FLAGS = to 'cq'" 1>&2 $echo "$modename: warning: to ensure that POSIX-compatible ar will wor= k" 1>&2 AR_FLAGS=3Dcq fi # Is there a better way of finding the last object in the list? for obj in $save_oldobjs do last_oldobj=3D$obj done =20 for obj in $save_oldobjs do oldobjs=3D"$objlist $obj" objlist=3D"$objlist $obj" eval test_cmds=3D\"$old_archive_cmds\" if len=3D`expr "X$test_cmds" : ".*"` && test "$len" -le "$max_cmd_len"; then : else # the above command should be used before it gets too long oldobjs=3D$objlist if test "$obj" =3D "$last_oldobj" ; then RANLIB=3D$save_RANLIB fi =20 test -z "$concat_cmds" || concat_cmds=3D$concat_cmds~ eval concat_cmds=3D\"\${concat_cmds}$old_archive_cmds\" objlist=3D fi done RANLIB=3D$save_RANLIB oldobjs=3D$objlist if test "X$oldobjs" =3D "X" ; then eval cmds=3D\"\$concat_cmds\" else eval cmds=3D\"\$concat_cmds~\$old_archive_cmds\" fi fi fi save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do eval cmd=3D\"$cmd\" IFS=3D"$save_ifs" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" done if test -n "$generated"; then $show "${rm}r$generated" $run ${rm}r$generated fi # Now create the libtool archive. case $output in *.la) old_library=3D test "$build_old_libs" =3D yes && old_library=3D"$libname.$libext" $show "creating $output" # Preserve any variables that may affect compiler behavior for var in $variables_saved_for_relink; do if eval test -z \"\${$var+set}\"; then relink_command=3D"{ test -z \"\${$var+set}\" || unset $var || { $var=3D;= export $var; }; }; $relink_command" elif eval var_value=3D\$$var; test -z "$var_value"; then relink_command=3D"$var=3D; export $var; $relink_command" else var_value=3D`$echo "X$var_value" | $Xsed -e "$sed_quote_subst"` relink_command=3D"$var=3D\"$var_value\"; export $var; $relink_command" fi done # Quote the link command for shipping. relink_command=3D"(cd `pwd`; $SHELL $0 $preserve_args --mode=3Drelink= $libtool_args @inst_prefix_dir@)" relink_command=3D`$echo "X$relink_command" | $Xsed -e "$sed_quote_sub= st"` if test "$hardcode_automatic" =3D yes ; then relink_command=3D fi =20 # Only create the output if not a dry run. if test -z "$run"; then for installed in no yes; do if test "$installed" =3D yes; then if test -z "$install_libdir"; then break fi output=3D"$output_objdir/$outputname"i # Replace all uninstalled libtool libraries with the installed ones newdependency_libs=3D for deplib in $dependency_libs; do case $deplib in *.la) name=3D`$echo "X$deplib" | $Xsed -e 's%^.*/%%'` eval libdir=3D`${SED} -n -e 's/^libdir=3D\(.*\)$/\1/p' $deplib` if test -z "$libdir"; then $echo "$modename: \`$deplib' is not a valid libtool archive" 1>&2 exit 1 fi newdependency_libs=3D"$newdependency_libs $libdir/$name" ;; *) newdependency_libs=3D"$newdependency_libs $deplib" ;; esac done dependency_libs=3D"$newdependency_libs" newdlfiles=3D for lib in $dlfiles; do name=3D`$echo "X$lib" | $Xsed -e 's%^.*/%%'` eval libdir=3D`${SED} -n -e 's/^libdir=3D\(.*\)$/\1/p' $lib` if test -z "$libdir"; then $echo "$modename: \`$lib' is not a valid libtool archive" 1>&2 exit 1 fi newdlfiles=3D"$newdlfiles $libdir/$name" done dlfiles=3D"$newdlfiles" newdlprefiles=3D for lib in $dlprefiles; do name=3D`$echo "X$lib" | $Xsed -e 's%^.*/%%'` eval libdir=3D`${SED} -n -e 's/^libdir=3D\(.*\)$/\1/p' $lib` if test -z "$libdir"; then $echo "$modename: \`$lib' is not a valid libtool archive" 1>&2 exit 1 fi newdlprefiles=3D"$newdlprefiles $libdir/$name" done dlprefiles=3D"$newdlprefiles" else newdlfiles=3D for lib in $dlfiles; do case $lib in=20 [\\/]* | [A-Za-z]:[\\/]*) abs=3D"$lib" ;; *) abs=3D`pwd`"/$lib" ;; esac newdlfiles=3D"$newdlfiles $abs" done dlfiles=3D"$newdlfiles" newdlprefiles=3D for lib in $dlprefiles; do case $lib in=20 [\\/]* | [A-Za-z]:[\\/]*) abs=3D"$lib" ;; *) abs=3D`pwd`"/$lib" ;; esac newdlprefiles=3D"$newdlprefiles $abs" done dlprefiles=3D"$newdlprefiles" fi $rm $output # place dlname in correct position for cygwin tdlname=3D$dlname case $host,$output,$installed,$module,$dlname in *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll) tdlname=3D../b= in/$dlname ;; esac $echo > $output "\ # $outputname - a libtool library file # Generated by $PROGRAM - GNU $PACKAGE $VERSION$TIMESTAMP # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname=3D'$tdlname' # Names of this library. library_names=3D'$library_names' # The name of the static archive. old_library=3D'$old_library' # Libraries that this one depends upon. dependency_libs=3D'$dependency_libs' # Version information for $libname. current=3D$current age=3D$age revision=3D$revision # Is this an already installed library? installed=3D$installed # Should we warn about portability when linking against -modules? shouldnotlink=3D$module # Files to dlopen/dlpreopen dlopen=3D'$dlfiles' dlpreopen=3D'$dlprefiles' # Directory that this library needs to be installed in: libdir=3D'$install_libdir'" if test "$installed" =3D no && test "$need_relink" =3D yes; then $echo >> $output "\ relink_command=3D\"$relink_command\"" fi done fi # Do a symbolic link so that the libtool archive can be found in # LD_LIBRARY_PATH before the program is installed. $show "(cd $output_objdir && $rm $outputname && $LN_S ../$outputname = $outputname)" $run eval '(cd $output_objdir && $rm $outputname && $LN_S ../$outputn= ame $outputname)' || exit $? ;; esac exit 0 ;; # libtool install mode install) modename=3D"$modename: install" # There may be an optional sh(1) argument at the beginning of # install_prog (especially on Windows NT). if test "$nonopt" =3D "$SHELL" || test "$nonopt" =3D /bin/sh || # Allow the use of GNU shtool's install command. $echo "X$nonopt" | $Xsed | grep shtool > /dev/null; then # Aesthetically quote it. arg=3D`$echo "X$nonopt" | $Xsed -e "$sed_quote_subst"` case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*) arg=3D"\"$arg\"" ;; esac install_prog=3D"$arg " arg=3D"$1" shift else install_prog=3D arg=3D"$nonopt" fi # The real first argument should be the name of the installation progra= m. # Aesthetically quote it. arg=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst"` case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*) arg=3D"\"$arg\"" ;; esac install_prog=3D"$install_prog$arg" # We need to accept at least all the BSD install flags. dest=3D files=3D opts=3D prev=3D install_type=3D isdir=3Dno stripme=3D for arg do if test -n "$dest"; then files=3D"$files $dest" dest=3D"$arg" continue fi case $arg in -d) isdir=3Dyes ;; -f) prev=3D"-f" ;; -g) prev=3D"-g" ;; -m) prev=3D"-m" ;; -o) prev=3D"-o" ;; -s) stripme=3D" -s" continue ;; -*) ;; *) # If the previous option needed an argument, then skip it. if test -n "$prev"; then prev=3D else dest=3D"$arg" continue fi ;; esac # Aesthetically quote the argument. arg=3D`$echo "X$arg" | $Xsed -e "$sed_quote_subst"` case $arg in *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*) arg=3D"\"$arg\"" ;; esac install_prog=3D"$install_prog $arg" done if test -z "$install_prog"; then $echo "$modename: you must specify an install program" 1>&2 $echo "$help" 1>&2 exit 1 fi if test -n "$prev"; then $echo "$modename: the \`$prev' option requires an argument" 1>&2 $echo "$help" 1>&2 exit 1 fi if test -z "$files"; then if test -z "$dest"; then $echo "$modename: no file or destination specified" 1>&2 else $echo "$modename: you must specify a destination" 1>&2 fi $echo "$help" 1>&2 exit 1 fi # Strip any trailing slash from the destination. dest=3D`$echo "X$dest" | $Xsed -e 's%/$%%'` # Check to see that the destination is a directory. test -d "$dest" && isdir=3Dyes if test "$isdir" =3D yes; then destdir=3D"$dest" destname=3D else destdir=3D`$echo "X$dest" | $Xsed -e 's%/[^/]*$%%'` test "X$destdir" =3D "X$dest" && destdir=3D. destname=3D`$echo "X$dest" | $Xsed -e 's%^.*/%%'` # Not a directory, so check to see that there is only one file specif= ied. set dummy $files if test "$#" -gt 2; then $echo "$modename: \`$dest' is not a directory" 1>&2 $echo "$help" 1>&2 exit 1 fi fi case $destdir in [\\/]* | [A-Za-z]:[\\/]*) ;; *) for file in $files; do case $file in *.lo) ;; *) $echo "$modename: \`$destdir' must be an absolute directory name" 1>&2 $echo "$help" 1>&2 exit 1 ;; esac done ;; esac # This variable tells wrapper scripts just to set variables rather # than running their programs. libtool_install_magic=3D"$magic" staticlibs=3D future_libdirs=3D current_libdirs=3D for file in $files; do # Do each installation. case $file in *.$libext) # Do the static libraries later. staticlibs=3D"$staticlibs $file" ;; *.la) # Check to see that this really is a libtool archive. if (${SED} -e '2q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2= >&1; then : else $echo "$modename: \`$file' is not a valid libtool archive" 1>&2 $echo "$help" 1>&2 exit 1 fi library_names=3D old_library=3D relink_command=3D # If there is no directory component, then add one. case $file in */* | *\\*) . $file ;; *) . ./$file ;; esac # Add the libdir to current_libdirs if it is the destination. if test "X$destdir" =3D "X$libdir"; then case "$current_libdirs " in *" $libdir "*) ;; *) current_libdirs=3D"$current_libdirs $libdir" ;; esac else # Note the libdir as a future libdir. case "$future_libdirs " in *" $libdir "*) ;; *) future_libdirs=3D"$future_libdirs $libdir" ;; esac fi dir=3D`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'`/ test "X$dir" =3D "X$file/" && dir=3D dir=3D"$dir$objdir" if test -n "$relink_command"; then # Determine the prefix the user has applied to our future dir. inst_prefix_dir=3D`$echo "$destdir" | $SED "s%$libdir\$%%"` # Don't allow the user to place us outside of our expected # location b/c this prevents finding dependent libraries that # are installed to the same prefix. # At present, this check doesn't affect windows .dll's that # are installed into $libdir/../bin (currently, that works fine) # but it's something to keep an eye on. if test "$inst_prefix_dir" =3D "$destdir"; then $echo "$modename: error: cannot install \`$file' to a directory not en= ding in $libdir" 1>&2 exit 1 fi if test -n "$inst_prefix_dir"; then # Stick the inst_prefix_dir data into the link command. relink_command=3D`$echo "$relink_command" | $SED "s%@inst_prefix_dir@%= -inst-prefix-dir $inst_prefix_dir%"` else relink_command=3D`$echo "$relink_command" | $SED "s%@inst_prefix_dir@%= %"` fi $echo "$modename: warning: relinking \`$file'" 1>&2 $show "$relink_command" if $run eval "$relink_command"; then : else $echo "$modename: error: relink \`$file' with the above command before= installing it" 1>&2 exit 1 fi fi # See the names of the shared library. set dummy $library_names if test -n "$2"; then realname=3D"$2" shift shift srcname=3D"$realname" test -n "$relink_command" && srcname=3D"$realname"T # Install the shared library and build the symlinks. $show "$install_prog $dir/$srcname $destdir/$realname" $run eval "$install_prog $dir/$srcname $destdir/$realname" || exit $? if test -n "$stripme" && test -n "$striplib"; then $show "$striplib $destdir/$realname" $run eval "$striplib $destdir/$realname" || exit $? fi if test "$#" -gt 0; then # Delete the old symlinks, and create new ones. for linkname do if test "$linkname" !=3D "$realname"; then $show "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)" $run eval "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)" fi done fi # Do each command in the postinstall commands. lib=3D"$destdir/$realname" cmds=3D$postinstall_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" fi # Install the pseudo-library for information purposes. name=3D`$echo "X$file" | $Xsed -e 's%^.*/%%'` instname=3D"$dir/$name"i $show "$install_prog $instname $destdir/$name" $run eval "$install_prog $instname $destdir/$name" || exit $? # Maybe install the static library, too. test -n "$old_library" && staticlibs=3D"$staticlibs $dir/$old_library" ;; *.lo) # Install (i.e. copy) a libtool object. # Figure out destination file name, if it wasn't already specified. if test -n "$destname"; then destfile=3D"$destdir/$destname" else destfile=3D`$echo "X$file" | $Xsed -e 's%^.*/%%'` destfile=3D"$destdir/$destfile" fi # Deduce the name of the destination old-style object file. case $destfile in *.lo) staticdest=3D`$echo "X$destfile" | $Xsed -e "$lo2o"` ;; *.$objext) staticdest=3D"$destfile" destfile=3D ;; *) $echo "$modename: cannot copy a libtool object to \`$destfile'" 1>&2 $echo "$help" 1>&2 exit 1 ;; esac # Install the libtool object if requested. if test -n "$destfile"; then $show "$install_prog $file $destfile" $run eval "$install_prog $file $destfile" || exit $? fi # Install the old object if enabled. if test "$build_old_libs" =3D yes; then # Deduce the name of the old-style object file. staticobj=3D`$echo "X$file" | $Xsed -e "$lo2o"` $show "$install_prog $staticobj $staticdest" $run eval "$install_prog \$staticobj \$staticdest" || exit $? fi exit 0 ;; *) # Figure out destination file name, if it wasn't already specified. if test -n "$destname"; then destfile=3D"$destdir/$destname" else destfile=3D`$echo "X$file" | $Xsed -e 's%^.*/%%'` destfile=3D"$destdir/$destfile" fi # If the file is missing, and there is a .exe on the end, strip it # because it is most likely a libtool script we actually want to # install stripped_ext=3D"" case $file in *.exe) if test ! -f "$file"; then file=3D`$echo $file|${SED} 's,.exe$,,'` stripped_ext=3D".exe" fi ;; esac # Do a test to see if this is really a libtool program. case $host in *cygwin*|*mingw*) wrapper=3D`$echo $file | ${SED} -e 's,.exe$,,'` ;; *) wrapper=3D$file ;; esac if (${SED} -e '4q' $wrapper | grep "^# Generated by .*$PACKAGE")>/dev/null= 2>&1; then notinst_deplibs=3D relink_command=3D # To insure that "foo" is sourced, and not "foo.exe", # finese the cygwin/MSYS system by explicitly sourcing "foo." # which disallows the automatic-append-.exe behavior. case $build in *cygwin* | *mingw*) wrapperdot=3D${wrapper}. ;; *) wrapperdot=3D${wrapper} ;; esac # If there is no directory component, then add one. case $file in */* | *\\*) . ${wrapperdot} ;; *) . ./${wrapperdot} ;; esac # Check the variables that should have been set. if test -z "$notinst_deplibs"; then $echo "$modename: invalid libtool wrapper script \`$wrapper'" 1>&2 exit 1 fi finalize=3Dyes for lib in $notinst_deplibs; do # Check to see that each library is installed. libdir=3D if test -f "$lib"; then # If there is no directory component, then add one. case $lib in */* | *\\*) . $lib ;; *) . ./$lib ;; esac fi libfile=3D"$libdir/"`$echo "X$lib" | $Xsed -e 's%^.*/%%g'` ### testsui= te: skip nested quoting test if test -n "$libdir" && test ! -f "$libfile"; then $echo "$modename: warning: \`$lib' has not been installed in \`$libd= ir'" 1>&2 finalize=3Dno fi done relink_command=3D # To insure that "foo" is sourced, and not "foo.exe", # finese the cygwin/MSYS system by explicitly sourcing "foo." # which disallows the automatic-append-.exe behavior. case $build in *cygwin* | *mingw*) wrapperdot=3D${wrapper}. ;; *) wrapperdot=3D${wrapper} ;; esac # If there is no directory component, then add one. case $file in */* | *\\*) . ${wrapperdot} ;; *) . ./${wrapperdot} ;; esac outputname=3D if test "$fast_install" =3D no && test -n "$relink_command"; then if test "$finalize" =3D yes && test -z "$run"; then tmpdir=3D"/tmp" test -n "$TMPDIR" && tmpdir=3D"$TMPDIR" tmpdir=3D"$tmpdir/libtool-$$" if $mkdir "$tmpdir" && chmod 700 "$tmpdir"; then : else $echo "$modename: error: cannot create temporary directory \`$tmpdir'" 1>= &2 continue fi file=3D`$echo "X$file$stripped_ext" | $Xsed -e 's%^.*/%%'` outputname=3D"$tmpdir/$file" # Replace the output file specification. relink_command=3D`$echo "X$relink_command" | $Xsed -e 's%@OUTPUT@%'"= $outputname"'%g'` $show "$relink_command" if $run eval "$relink_command"; then : else $echo "$modename: error: relink \`$file' with the above command before in= stalling it" 1>&2 ${rm}r "$tmpdir" continue fi file=3D"$outputname" else $echo "$modename: warning: cannot relink \`$file'" 1>&2 fi else # Install the binary that we compiled earlier. file=3D`$echo "X$file$stripped_ext" | $Xsed -e "s%\([^/]*\)$%$objdir/\= 1%"` fi fi # remove .exe since cygwin /usr/bin/install will append another # one anyways case $install_prog,$host in */usr/bin/install*,*cygwin*) case $file:$destfile in *.exe:*.exe) # this is ok ;; *.exe:*) destfile=3D$destfile.exe ;; *:*.exe) destfile=3D`$echo $destfile | ${SED} -e 's,.exe$,,'` ;; esac ;; esac $show "$install_prog$stripme $file $destfile" $run eval "$install_prog\$stripme \$file \$destfile" || exit $? test -n "$outputname" && ${rm}r "$tmpdir" ;; esac done for file in $staticlibs; do name=3D`$echo "X$file" | $Xsed -e 's%^.*/%%'` # Set up the ranlib parameters. oldlib=3D"$destdir/$name" $show "$install_prog $file $oldlib" $run eval "$install_prog \$file \$oldlib" || exit $? if test -n "$stripme" && test -n "$old_striplib"; then $show "$old_striplib $oldlib" $run eval "$old_striplib $oldlib" || exit $? fi # Do each command in the postinstall commands. cmds=3D$old_postinstall_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || exit $? done IFS=3D"$save_ifs" done if test -n "$future_libdirs"; then $echo "$modename: warning: remember to run \`$progname --finish$futur= e_libdirs'" 1>&2 fi if test -n "$current_libdirs"; then # Maybe just do a dry run. test -n "$run" && current_libdirs=3D" -n$current_libdirs" exec_cmd=3D'$SHELL $0 $preserve_args --finish$current_libdirs' else exit 0 fi ;; # libtool finish mode finish) modename=3D"$modename: finish" libdirs=3D"$nonopt" admincmds=3D if test -n "$finish_cmds$finish_eval" && test -n "$libdirs"; then for dir do libdirs=3D"$libdirs $dir" done for libdir in $libdirs; do if test -n "$finish_cmds"; then # Do each command in the finish commands. cmds=3D$finish_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" || admincmds=3D"$admincmds $cmd" done IFS=3D"$save_ifs" fi if test -n "$finish_eval"; then # Do the single finish_eval. eval cmds=3D\"$finish_eval\" $run eval "$cmds" || admincmds=3D"$admincmds $cmds" fi done fi # Exit here if they wanted silent mode. test "$show" =3D : && exit 0 $echo "----------------------------------------------------------------= ------" $echo "Libraries have been installed in:" for libdir in $libdirs; do $echo " $libdir" done $echo $echo "If you ever happen to want to link against installed libraries" $echo "in a given directory, LIBDIR, you must either use libtool, and" $echo "specify the full pathname of the library, or use the \`-LLIBDIR'" $echo "flag during linking and do at least one of the following:" if test -n "$shlibpath_var"; then $echo " - add LIBDIR to the \`$shlibpath_var' environment variable" $echo " during execution" fi if test -n "$runpath_var"; then $echo " - add LIBDIR to the \`$runpath_var' environment variable" $echo " during linking" fi if test -n "$hardcode_libdir_flag_spec"; then libdir=3DLIBDIR eval flag=3D\"$hardcode_libdir_flag_spec\" $echo " - use the \`$flag' linker flag" fi if test -n "$admincmds"; then $echo " - have your system administrator run these commands:$adminc= mds" fi if test -f /etc/ld.so.conf; then $echo " - have your system administrator add LIBDIR to \`/etc/ld.so= =2Econf'" fi $echo $echo "See any operating system documentation about shared libraries fo= r" $echo "more information, such as the ld(1) and ld.so(8) manual pages." $echo "----------------------------------------------------------------= ------" exit 0 ;; # libtool execute mode execute) modename=3D"$modename: execute" # The first argument is the command name. cmd=3D"$nonopt" if test -z "$cmd"; then $echo "$modename: you must specify a COMMAND" 1>&2 $echo "$help" exit 1 fi # Handle -dlopen flags immediately. for file in $execute_dlfiles; do if test ! -f "$file"; then $echo "$modename: \`$file' is not a file" 1>&2 $echo "$help" 1>&2 exit 1 fi dir=3D case $file in *.la) # Check to see that this really is a libtool archive. if (${SED} -e '2q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2= >&1; then : else $echo "$modename: \`$lib' is not a valid libtool archive" 1>&2 $echo "$help" 1>&2 exit 1 fi # Read the libtool library. dlname=3D library_names=3D # If there is no directory component, then add one. case $file in */* | *\\*) . $file ;; *) . ./$file ;; esac # Skip this library if it cannot be dlopened. if test -z "$dlname"; then # Warn if it was a shared library. test -n "$library_names" && $echo "$modename: warning: \`$file' was not = linked with \`-export-dynamic'" continue fi dir=3D`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'` test "X$dir" =3D "X$file" && dir=3D. if test -f "$dir/$objdir/$dlname"; then dir=3D"$dir/$objdir" else $echo "$modename: cannot find \`$dlname' in \`$dir' or \`$dir/$objdir'" = 1>&2 exit 1 fi ;; *.lo) # Just add the directory containing the .lo file. dir=3D`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'` test "X$dir" =3D "X$file" && dir=3D. ;; *) $echo "$modename: warning \`-dlopen' is ignored for non-libtool libraries = and objects" 1>&2 continue ;; esac # Get the absolute pathname. absdir=3D`cd "$dir" && pwd` test -n "$absdir" && dir=3D"$absdir" # Now add the directory to shlibpath_var. if eval "test -z \"\$$shlibpath_var\""; then eval "$shlibpath_var=3D\"\$dir\"" else eval "$shlibpath_var=3D\"\$dir:\$$shlibpath_var\"" fi done # This variable tells wrapper scripts just to set shlibpath_var # rather than running their programs. libtool_execute_magic=3D"$magic" # Check if any of the arguments is a wrapper script. args=3D for file do case $file in -*) ;; *) # Do a test to see if this is really a libtool program. if (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2= >&1; then # If there is no directory component, then add one. case $file in */* | *\\*) . $file ;; *) . ./$file ;; esac # Transform arg to wrapped name. file=3D"$progdir/$program" fi ;; esac # Quote arguments (to preserve shell metacharacters). file=3D`$echo "X$file" | $Xsed -e "$sed_quote_subst"` args=3D"$args \"$file\"" done if test -z "$run"; then if test -n "$shlibpath_var"; then # Export the shlibpath_var. eval "export $shlibpath_var" fi # Restore saved environment variables if test "${save_LC_ALL+set}" =3D set; then LC_ALL=3D"$save_LC_ALL"; export LC_ALL fi if test "${save_LANG+set}" =3D set; then LANG=3D"$save_LANG"; export LANG fi # Now prepare to actually exec the command. exec_cmd=3D"\$cmd$args" else # Display what would be done. if test -n "$shlibpath_var"; then eval "\$echo \"\$shlibpath_var=3D\$$shlibpath_var\"" $echo "export $shlibpath_var" fi $echo "$cmd$args" exit 0 fi ;; # libtool clean and uninstall mode clean | uninstall) modename=3D"$modename: $mode" rm=3D"$nonopt" files=3D rmforce=3D exit_status=3D0 # This variable tells wrapper scripts just to set variables rather # than running their programs. libtool_install_magic=3D"$magic" for arg do case $arg in -f) rm=3D"$rm $arg"; rmforce=3Dyes ;; -*) rm=3D"$rm $arg" ;; *) files=3D"$files $arg" ;; esac done if test -z "$rm"; then $echo "$modename: you must specify an RM program" 1>&2 $echo "$help" 1>&2 exit 1 fi rmdirs=3D origobjdir=3D"$objdir" for file in $files; do dir=3D`$echo "X$file" | $Xsed -e 's%/[^/]*$%%'` if test "X$dir" =3D "X$file"; then dir=3D. objdir=3D"$origobjdir" else objdir=3D"$dir/$origobjdir" fi name=3D`$echo "X$file" | $Xsed -e 's%^.*/%%'` test "$mode" =3D uninstall && objdir=3D"$dir" # Remember objdir for removal later, being careful to avoid duplicates if test "$mode" =3D clean; then case " $rmdirs " in *" $objdir "*) ;; *) rmdirs=3D"$rmdirs $objdir" ;; esac fi # Don't error if the file doesn't exist and rm -f was used. if (test -L "$file") >/dev/null 2>&1 \ || (test -h "$file") >/dev/null 2>&1 \ || test -f "$file"; then : elif test -d "$file"; then exit_status=3D1 continue elif test "$rmforce" =3D yes; then continue fi rmfiles=3D"$file" case $name in *.la) # Possibly a libtool archive, so verify it. if (${SED} -e '2q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2= >&1; then . $dir/$name # Delete the libtool libraries and symlinks. for n in $library_names; do rmfiles=3D"$rmfiles $objdir/$n" done test -n "$old_library" && rmfiles=3D"$rmfiles $objdir/$old_library" test "$mode" =3D clean && rmfiles=3D"$rmfiles $objdir/$name $objdir/${na= me}i" if test "$mode" =3D uninstall; then if test -n "$library_names"; then # Do each command in the postuninstall commands. cmds=3D$postuninstall_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" if test "$?" -ne 0 && test "$rmforce" !=3D yes; then exit_status=3D1 fi done IFS=3D"$save_ifs" fi if test -n "$old_library"; then # Do each command in the old_postuninstall commands. cmds=3D$old_postuninstall_cmds save_ifs=3D"$IFS"; IFS=3D'~' for cmd in $cmds; do IFS=3D"$save_ifs" eval cmd=3D\"$cmd\" $show "$cmd" $run eval "$cmd" if test "$?" -ne 0 && test "$rmforce" !=3D yes; then exit_status=3D1 fi done IFS=3D"$save_ifs" fi # FIXME: should reinstall the best remaining shared library. fi fi ;; *.lo) # Possibly a libtool object, so verify it. if (${SED} -e '2q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null 2= >&1; then # Read the .lo file . $dir/$name # Add PIC object to the list of files to remove. if test -n "$pic_object" \ && test "$pic_object" !=3D none; then rmfiles=3D"$rmfiles $dir/$pic_object" fi # Add non-PIC object to the list of files to remove. if test -n "$non_pic_object" \ && test "$non_pic_object" !=3D none; then rmfiles=3D"$rmfiles $dir/$non_pic_object" fi fi ;; *) if test "$mode" =3D clean ; then noexename=3D$name case $file in *.exe)=20 file=3D`$echo $file|${SED} 's,.exe$,,'` noexename=3D`$echo $name|${SED} 's,.exe$,,'` # $file with .exe has already been added to rmfiles, # add $file without .exe rmfiles=3D"$rmfiles $file" ;; esac # Do a test to see if this is a libtool program. if (${SED} -e '4q' $file | grep "^# Generated by .*$PACKAGE") >/dev/null= 2>&1; then relink_command=3D . $dir/$noexename # note $name still contains .exe if it was in $file originally # as does the version of $file that was added into $rmfiles rmfiles=3D"$rmfiles $objdir/$name $objdir/${name}S.${objext}" if test "$fast_install" =3D yes && test -n "$relink_command"; then rmfiles=3D"$rmfiles $objdir/lt-$name" fi if test "X$noexename" !=3D "X$name" ; then rmfiles=3D"$rmfiles $objdir/lt-${noexename}.c" fi fi fi ;; esac $show "$rm $rmfiles" $run $rm $rmfiles || exit_status=3D1 done objdir=3D"$origobjdir" # Try to remove the ${objdir}s in the directories where we deleted files for dir in $rmdirs; do if test -d "$dir"; then $show "rmdir $dir" $run rmdir $dir >/dev/null 2>&1 fi done exit $exit_status ;; "") $echo "$modename: you must specify a MODE" 1>&2 $echo "$generic_help" 1>&2 exit 1 ;; esac if test -z "$exec_cmd"; then $echo "$modename: invalid operation mode \`$mode'" 1>&2 $echo "$generic_help" 1>&2 exit 1 fi fi # test -z "$show_help" if test -n "$exec_cmd"; then eval exec $exec_cmd exit 1 fi # We need to display help for each of the modes. case $mode in "") $echo \ "Usage: $modename [OPTION]... [MODE-ARG]... Provide generalized library-building support services. --config show all configuration variables --debug enable verbose shell tracing -n, --dry-run display commands without modifying any files --features display basic configuration information and exit --finish same as \`--mode=3Dfinish' --help display this help message and exit --mode=3DMODE use operation mode MODE [default=3Dinferred from MO= DE-ARGS] --quiet same as \`--silent' --silent don't print informational messages --tag=3DTAG use configuration variables from tag TAG --version print version information MODE must be one of the following: clean remove files from the build directory compile compile a source file into a libtool object execute automatically set library path, then run a program finish complete the installation of libtool libraries install install libraries or executables link create a library or an executable uninstall remove libraries from an installed directory MODE-ARGS vary depending on the MODE. Try \`$modename --help --mode=3DMODE= ' for a more detailed description of MODE. Report bugs to ." exit 0 ;; clean) $echo \ "Usage: $modename [OPTION]... --mode=3Dclean RM [RM-OPTION]... FILE... Remove files from the build directory. RM is the name of the program to use to delete files associated with each F= ILE (typically \`/bin/rm'). RM-OPTIONS are options (such as \`-f') to be passed to RM. If FILE is a libtool library, object or program, all the files associated with it are deleted. Otherwise, only FILE itself is deleted using RM." ;; compile) $echo \ "Usage: $modename [OPTION]... --mode=3Dcompile COMPILE-COMMAND... SOURCEFILE Compile a source file into a libtool library object. This mode accepts the following additional options: -o OUTPUT-FILE set the output file name to OUTPUT-FILE -prefer-pic try to building PIC objects only -prefer-non-pic try to building non-PIC objects only -static always build a \`.o' file suitable for static linking COMPILE-COMMAND is a command to be used in creating a \`standard' object fi= le =66rom the given SOURCEFILE. The output file name is determined by removing the directory component from SOURCEFILE, then substituting the C source code suffix \`.c' with the library object suffix, \`.lo'." ;; execute) $echo \ "Usage: $modename [OPTION]... --mode=3Dexecute COMMAND [ARGS]... Automatically set library path, then run a program. This mode accepts the following additional options: -dlopen FILE add the directory containing FILE to the library path This mode sets the library path environment variable according to \`-dlopen' flags. If any of the ARGS are libtool executable wrappers, then they are translated into their corresponding uninstalled binary, and any of their required libr= ary directories are added to the library path. Then, COMMAND is executed, with ARGS as arguments." ;; finish) $echo \ "Usage: $modename [OPTION]... --mode=3Dfinish [LIBDIR]... Complete the installation of libtool libraries. Each LIBDIR is a directory that contains libtool libraries. The commands that this mode executes may require superuser privileges. Use the \`--dry-run' option if you just want to see what would be executed." ;; install) $echo \ "Usage: $modename [OPTION]... --mode=3Dinstall INSTALL-COMMAND... Install executables or libraries. INSTALL-COMMAND is the installation command. The first component should be either the \`install' or \`cp' program. The rest of the components are interpreted as arguments to that command (on= ly BSD-compatible install options are recognized)." ;; link) $echo \ "Usage: $modename [OPTION]... --mode=3Dlink LINK-COMMAND... Link object files or libraries together to form another library, or to create an executable program. LINK-COMMAND is a command using the C compiler that you would use to create a program from several object files. The following components of LINK-COMMAND are treated specially: -all-static do not do any dynamic linking at all -avoid-version do not add a version suffix if possible -dlopen FILE \`-dlpreopen' FILE if it cannot be dlopened at runtime -dlpreopen FILE link in FILE and add its symbols to lt_preloaded_symbols -export-dynamic allow symbols from OUTPUT-FILE to be resolved with dlsy= m(3) -export-symbols SYMFILE try to export only the symbols listed in SYMFILE -export-symbols-regex REGEX try to export only the symbols matching REGEX -LLIBDIR search LIBDIR for required installed libraries -lNAME OUTPUT-FILE requires the installed library libNAME -module build a library that can dlopened -no-fast-install disable the fast-install mode -no-install link a not-installable executable -no-undefined declare that a library does not refer to external symbo= ls -o OUTPUT-FILE create OUTPUT-FILE from the specified objects -objectlist FILE Use a list of object files found in FILE to specify obj= ects -precious-files-regex REGEX don't remove output files matching REGEX -release RELEASE specify package release information -rpath LIBDIR the created library will eventually be installed in LIB= DIR -R[ ]LIBDIR add LIBDIR to the runtime path of programs and libraries -static do not do any dynamic linking of libtool libraries -version-info CURRENT[:REVISION[:AGE]] specify library version info [each variable defaults to 0] All other options (arguments beginning with \`-') are ignored. Every other argument is treated as a filename. Files ending in \`.la' are treated as uninstalled libtool libraries, other files are standard or libra= ry object files. If the OUTPUT-FILE ends in \`.la', then a libtool library is created, only library objects (\`.lo' files) may be specified, and \`-rpath' is required, except when creating a convenience library. If OUTPUT-FILE ends in \`.a' or \`.lib', then a standard library is created using \`ar' and \`ranlib', or on Windows using \`lib'. If OUTPUT-FILE ends in \`.lo' or \`.${objext}', then a reloadable object fi= le is created, otherwise an executable program is created." ;; uninstall) $echo \ "Usage: $modename [OPTION]... --mode=3Duninstall RM [RM-OPTION]... FILE... Remove libraries from an installation directory. RM is the name of the program to use to delete files associated with each F= ILE (typically \`/bin/rm'). RM-OPTIONS are options (such as \`-f') to be passed to RM. If FILE is a libtool library, all the files associated with it are deleted. Otherwise, only FILE itself is deleted using RM." ;; *) $echo "$modename: invalid operation mode \`$mode'" 1>&2 $echo "$help" 1>&2 exit 1 ;; esac $echo $echo "Try \`$modename --help' for more information about other modes." exit 0 # The TAGs below are defined such that we never get into a situation # in which we disable both kinds of libraries. Given conflicting # choices, we go for a static library, that is the most portable, # since we can't tell whether shared libraries were disabled because # the user asked for that or because the platform doesn't support # them. This is particularly important on AIX, because we don't # support having both static and shared libraries enabled at the same # time on that platform, so we default to a shared-only configuration. # If a disable-shared tag is given, we'll fallback to a static-only # configuration. But we'll never go from static-only to shared-only. # ### BEGIN LIBTOOL TAG CONFIG: disable-shared build_libtool_libs=3Dno build_old_libs=3Dyes # ### END LIBTOOL TAG CONFIG: disable-shared # ### BEGIN LIBTOOL TAG CONFIG: disable-static build_old_libs=3D`case $build_libtool_libs in yes) $echo no;; *) $echo yes;= ; esac` # ### END LIBTOOL TAG CONFIG: disable-static # Local Variables: # mode:shell-script # sh-indentation:2 # End: # ### BEGIN LIBTOOL TAG CONFIG: CXX # Libtool was configured on host descent.netsplit.com: # Shell to use when invoking shell scripts. SHELL=3D"/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=3Dyes # Whether or not to build static libraries. build_old_libs=3Dyes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=3Dno # Whether or not to disallow shared libs when runtime libs are static allow_libtool_libs_with_static_runtimes=3Dno # Whether or not to optimize for fast installation. fast_install=3Dyes # The host system. host_alias=3D host=3Di386-pc-linux-gnu # An echo program that does not interpret backslashes. echo=3D"echo" # The archiver. AR=3D"ar" AR_FLAGS=3D"cru" # A C compiler. LTCC=3D"gcc" # A language-specific compiler. CC=3D"g++" # Is the compiler the GNU C compiler? with_gcc=3Dyes # An ERE matcher. EGREP=3D"grep -E" # The linker used to build libraries. LD=3D"/usr/bin/ld" # Whether we need hard or soft links. LN_S=3D"ln -s" # A BSD-compatible nm program. NM=3D"/usr/bin/nm -B" # A symbol stripping program STRIP=3D"strip" # Used to examine libraries when file_magic_cmd begins "file" MAGIC_CMD=3Dfile # Used on cygwin: DLL creation program. DLLTOOL=3D"dlltool" # Used on cygwin: object dumper. OBJDUMP=3D"objdump" # Used on cygwin: assembler. AS=3D"as" # The name of the directory that contains temporary libtool files. objdir=3D.libs # How to create reloadable object files. reload_flag=3D" -r" reload_cmds=3D"\$LD\$reload_flag -o \$output\$reload_objs" # How to pass a linker flag through the compiler. wl=3D"-Wl," # Object file suffix (normally "o"). objext=3D"o" # Old archive suffix (normally "a"). libext=3D"a" # Shared library suffix (normally ".so"). shrext=3D'.so' # Executable file suffix (normally ""). exeext=3D"" # Additional compiler flags for building library objects. pic_flag=3D" -fPIC -DPIC" pic_mode=3Ddefault # What is the maximum length of a command? max_cmd_len=3D32768 # Does compiler simultaneously support -c and -o options? compiler_c_o=3D"yes" # Must we lock files when doing compilation ? need_locks=3D"no" # Do we need the lib prefix for modules? need_lib_prefix=3Dno # Do we need a version for libraries? need_version=3Dno # Whether dlopen is supported. dlopen_support=3Dyes # Whether dlopen of programs is supported. dlopen_self=3Dyes # Whether dlopen of statically linked programs is supported. dlopen_self_static=3Dyes # Compiler flag to prevent dynamic linking. link_static_flag=3D"-static" # Compiler flag to turn off builtin functions. no_builtin_flag=3D" -fno-builtin" # Compiler flag to allow reflexive dlopens. export_dynamic_flag_spec=3D"\${wl}--export-dynamic" # Compiler flag to generate shared objects directly from archives. whole_archive_flag_spec=3D"\${wl}--whole-archive\$convenience \${wl}--no-wh= ole-archive" # Compiler flag to generate thread-safe objects. thread_safe_flag_spec=3D"" # Library versioning type. version_type=3Dlinux # Format of library name prefix. libname_spec=3D"lib\$name" # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. library_names_spec=3D"\${libname}\${release}\${shared_ext}\$versuffix \${li= bname}\${release}\${shared_ext}\$major \$libname\${shared_ext}" # The coded name of the library, if different from the real name. soname_spec=3D"\${libname}\${release}\${shared_ext}\$major" # Commands used to build and install an old-style archive. RANLIB=3D"ranlib" old_archive_cmds=3D"\$AR \$AR_FLAGS \$oldlib\$oldobjs\$old_deplibs~\$RANLIB= \$oldlib" old_postinstall_cmds=3D"\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds=3D"" # Create an old-style archive from a shared archive. old_archive_from_new_cmds=3D"" # Create a temporary old-style archive to link instead of a shared archive. old_archive_from_expsyms_cmds=3D"" # Commands used to build and install a shared archive. archive_cmds=3D"\$CC -shared \$predep_objects \$libobjs \$deplibs \$postdep= _objects \$compiler_flags \${wl}-soname \$wl\$soname -o \$lib" archive_expsym_cmds=3D"\$CC -shared \$predep_objects \$libobjs \$deplibs \$= postdep_objects \$compiler_flags \${wl}-soname \$wl\$soname \${wl}-retain-s= ymbols-file \$wl\$export_symbols -o \$lib" postinstall_cmds=3D"" postuninstall_cmds=3D"" # Commands used to build a loadable module (assumed same as above if empty) module_cmds=3D"" module_expsym_cmds=3D"" # Commands to strip libraries. old_striplib=3D"strip --strip-debug" striplib=3D"strip --strip-unneeded" # Dependencies to place before the objects being linked to create a # shared library. predep_objects=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdep_objects=3D"" # Dependencies to place before the objects being linked to create a # shared library. predeps=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdeps=3D"-lstdc++ -lm -lgcc_s -lc -lgcc_s" # The library search path used internally by the compiler when linking # a shared library. compiler_lib_search_path=3D"" # Method to check whether dependent libraries are shared objects. deplibs_check_method=3D"pass_all" # Command to use when deplibs_check_method =3D=3D file_magic. file_magic_cmd=3D"\$MAGIC_CMD" # Flag that allows shared libraries with undefined symbols to be built. allow_undefined_flag=3D"" # Flag that forces no undefined symbols. no_undefined_flag=3D"" # Commands used to finish a libtool library installation in a directory. finish_cmds=3D"PATH=3D\\\"\\\$PATH:/sbin\\\" ldconfig -n \$libdir" # Same as above, but a single script fragment to be evaled but not shown. finish_eval=3D"" # Take the output of nm and produce a listing of raw symbols and C names. global_symbol_pipe=3D"sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ = ][ ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2\\3 \\3/p'" # Transform the output of nm in a proper C declaration global_symbol_to_cdecl=3D"sed -n -e 's/^. .* \\(.*\\)\$/extern int \\1;/p'" # Transform the output of nm in a C name address pair global_symbol_to_c_name_address=3D"sed -n -e 's/^: \\([^ ]*\\) \$/ {\\\"\\= 1\\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2= \", (lt_ptr) \\&\\2},/p'" # This is the shared library runtime path variable. runpath_var=3DLD_RUN_PATH # This is the shared library path variable. shlibpath_var=3DLD_LIBRARY_PATH # Is shlibpath searched before the hard-coded library search path? shlibpath_overrides_runpath=3Dno # How to hardcode a shared library path into an executable. hardcode_action=3Dimmediate # Whether we should hardcode library paths into libraries. hardcode_into_libs=3Dyes # Flag to hardcode $libdir into a binary during linking. # This must work even if $libdir does not exist. hardcode_libdir_flag_spec=3D"\${wl}--rpath \${wl}\$libdir" # If ld is used when linking, flag to hardcode $libdir into # a binary during linking. This must work even if $libdir does # not exist. hardcode_libdir_flag_spec_ld=3D"" # Whether we need a single -rpath flag with a separated argument. hardcode_libdir_separator=3D"" # Set to yes if using DIR/libNAME during linking hardcodes DIR into the # resulting binary. hardcode_direct=3Dno # Set to yes if using the -LDIR flag during linking hardcodes DIR into the # resulting binary. hardcode_minus_L=3Dno # Set to yes if using SHLIBPATH_VAR=3DDIR during linking hardcodes DIR into # the resulting binary. hardcode_shlibpath_var=3D # Set to yes if building a shared library automatically hardcodes DIR into = the library # and all subsequent libraries and executables linked against it. hardcode_automatic=3Dno # Variables whose values should be saved in libtool wrapper scripts and # restored at relink time. variables_saved_for_relink=3D"PATH LD_LIBRARY_PATH LD_RUN_PATH GCC_EXEC_PRE= FIX COMPILER_PATH LIBRARY_PATH" # Whether libtool must link a program against all its dependency libraries. link_all_deplibs=3Dunknown # Compile-time system search path for libraries sys_lib_search_path_spec=3D"/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib/" # Run-time system search path for libraries sys_lib_dlsearch_path_spec=3D"/lib /usr/lib /usr/X11R6/lib" # Fix the shell variable $srcfile for the compiler. fix_srcfile_path=3D"" # Set to yes if exported symbols are required. always_export_symbols=3Dno # The commands to list exported symbols. export_symbols_cmds=3D"\$NM \$libobjs \$convenience | \$global_symbol_pipe = | \$SED 's/.* //' | sort | uniq > \$export_symbols" # The commands to extract the exported symbol list from a shared archive. extract_expsyms_cmds=3D"" # Symbols that should not be listed in the preloaded symbols. exclude_expsyms=3D"" # Symbols that must always be exported. include_expsyms=3D"" # ### END LIBTOOL TAG CONFIG: CXX # ### BEGIN LIBTOOL TAG CONFIG: F77 # Libtool was configured on host descent.netsplit.com: # Shell to use when invoking shell scripts. SHELL=3D"/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=3Dyes # Whether or not to build static libraries. build_old_libs=3Dyes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=3Dno # Whether or not to disallow shared libs when runtime libs are static allow_libtool_libs_with_static_runtimes=3Dno # Whether or not to optimize for fast installation. fast_install=3Dyes # The host system. host_alias=3D host=3Di386-pc-linux-gnu # An echo program that does not interpret backslashes. echo=3D"echo" # The archiver. AR=3D"ar" AR_FLAGS=3D"cru" # A C compiler. LTCC=3D"gcc" # A language-specific compiler. CC=3D"g77" # Is the compiler the GNU C compiler? with_gcc=3Dyes # An ERE matcher. EGREP=3D"grep -E" # The linker used to build libraries. LD=3D"/usr/bin/ld" # Whether we need hard or soft links. LN_S=3D"ln -s" # A BSD-compatible nm program. NM=3D"/usr/bin/nm -B" # A symbol stripping program STRIP=3D"strip" # Used to examine libraries when file_magic_cmd begins "file" MAGIC_CMD=3Dfile # Used on cygwin: DLL creation program. DLLTOOL=3D"dlltool" # Used on cygwin: object dumper. OBJDUMP=3D"objdump" # Used on cygwin: assembler. AS=3D"as" # The name of the directory that contains temporary libtool files. objdir=3D.libs # How to create reloadable object files. reload_flag=3D" -r" reload_cmds=3D"\$LD\$reload_flag -o \$output\$reload_objs" # How to pass a linker flag through the compiler. wl=3D"-Wl," # Object file suffix (normally "o"). objext=3D"o" # Old archive suffix (normally "a"). libext=3D"a" # Shared library suffix (normally ".so"). shrext=3D'.so' # Executable file suffix (normally ""). exeext=3D"" # Additional compiler flags for building library objects. pic_flag=3D" -fPIC" pic_mode=3Ddefault # What is the maximum length of a command? max_cmd_len=3D32768 # Does compiler simultaneously support -c and -o options? compiler_c_o=3D"yes" # Must we lock files when doing compilation ? need_locks=3D"no" # Do we need the lib prefix for modules? need_lib_prefix=3Dno # Do we need a version for libraries? need_version=3Dno # Whether dlopen is supported. dlopen_support=3Dyes # Whether dlopen of programs is supported. dlopen_self=3Dyes # Whether dlopen of statically linked programs is supported. dlopen_self_static=3Dyes # Compiler flag to prevent dynamic linking. link_static_flag=3D"-static" # Compiler flag to turn off builtin functions. no_builtin_flag=3D"" # Compiler flag to allow reflexive dlopens. export_dynamic_flag_spec=3D"\${wl}--export-dynamic" # Compiler flag to generate shared objects directly from archives. whole_archive_flag_spec=3D"\${wl}--whole-archive\$convenience \${wl}--no-wh= ole-archive" # Compiler flag to generate thread-safe objects. thread_safe_flag_spec=3D"" # Library versioning type. version_type=3Dlinux # Format of library name prefix. libname_spec=3D"lib\$name" # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. library_names_spec=3D"\${libname}\${release}\${shared_ext}\$versuffix \${li= bname}\${release}\${shared_ext}\$major \$libname\${shared_ext}" # The coded name of the library, if different from the real name. soname_spec=3D"\${libname}\${release}\${shared_ext}\$major" # Commands used to build and install an old-style archive. RANLIB=3D"ranlib" old_archive_cmds=3D"\$AR \$AR_FLAGS \$oldlib\$oldobjs\$old_deplibs~\$RANLIB= \$oldlib" old_postinstall_cmds=3D"\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds=3D"" # Create an old-style archive from a shared archive. old_archive_from_new_cmds=3D"" # Create a temporary old-style archive to link instead of a shared archive. old_archive_from_expsyms_cmds=3D"" # Commands used to build and install a shared archive. archive_cmds=3D"\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-so= name \$wl\$soname -o \$lib" archive_expsym_cmds=3D"\$echo \\\"{ global:\\\" > \$output_objdir/\$libname= =2Ever~ cat \$export_symbols | sed -e \\\"s/\\\\(.*\\\\)/\\\\1;/\\\" >> \$output_ob= jdir/\$libname.ver~ \$echo \\\"local: *; };\\\" >> \$output_objdir/\$libname.ver~ \$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname \$w= l\$soname \${wl}-version-script \${wl}\$output_objdir/\$libname.ver -o \$li= b" postinstall_cmds=3D"" postuninstall_cmds=3D"" # Commands used to build a loadable module (assumed same as above if empty) module_cmds=3D"" module_expsym_cmds=3D"" # Commands to strip libraries. old_striplib=3D"strip --strip-debug" striplib=3D"strip --strip-unneeded" # Dependencies to place before the objects being linked to create a # shared library. predep_objects=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdep_objects=3D"" # Dependencies to place before the objects being linked to create a # shared library. predeps=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdeps=3D"" # The library search path used internally by the compiler when linking # a shared library. compiler_lib_search_path=3D"" # Method to check whether dependent libraries are shared objects. deplibs_check_method=3D"pass_all" # Command to use when deplibs_check_method =3D=3D file_magic. file_magic_cmd=3D"\$MAGIC_CMD" # Flag that allows shared libraries with undefined symbols to be built. allow_undefined_flag=3D"" # Flag that forces no undefined symbols. no_undefined_flag=3D"" # Commands used to finish a libtool library installation in a directory. finish_cmds=3D"PATH=3D\\\"\\\$PATH:/sbin\\\" ldconfig -n \$libdir" # Same as above, but a single script fragment to be evaled but not shown. finish_eval=3D"" # Take the output of nm and produce a listing of raw symbols and C names. global_symbol_pipe=3D"sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ = ][ ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2\\3 \\3/p'" # Transform the output of nm in a proper C declaration global_symbol_to_cdecl=3D"sed -n -e 's/^. .* \\(.*\\)\$/extern int \\1;/p'" # Transform the output of nm in a C name address pair global_symbol_to_c_name_address=3D"sed -n -e 's/^: \\([^ ]*\\) \$/ {\\\"\\= 1\\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2= \", (lt_ptr) \\&\\2},/p'" # This is the shared library runtime path variable. runpath_var=3DLD_RUN_PATH # This is the shared library path variable. shlibpath_var=3DLD_LIBRARY_PATH # Is shlibpath searched before the hard-coded library search path? shlibpath_overrides_runpath=3Dno # How to hardcode a shared library path into an executable. hardcode_action=3Dimmediate # Whether we should hardcode library paths into libraries. hardcode_into_libs=3Dyes # Flag to hardcode $libdir into a binary during linking. # This must work even if $libdir does not exist. hardcode_libdir_flag_spec=3D"\${wl}--rpath \${wl}\$libdir" # If ld is used when linking, flag to hardcode $libdir into # a binary during linking. This must work even if $libdir does # not exist. hardcode_libdir_flag_spec_ld=3D"" # Whether we need a single -rpath flag with a separated argument. hardcode_libdir_separator=3D"" # Set to yes if using DIR/libNAME during linking hardcodes DIR into the # resulting binary. hardcode_direct=3Dno # Set to yes if using the -LDIR flag during linking hardcodes DIR into the # resulting binary. hardcode_minus_L=3Dno # Set to yes if using SHLIBPATH_VAR=3DDIR during linking hardcodes DIR into # the resulting binary. hardcode_shlibpath_var=3Dunsupported # Set to yes if building a shared library automatically hardcodes DIR into = the library # and all subsequent libraries and executables linked against it. hardcode_automatic=3Dno # Variables whose values should be saved in libtool wrapper scripts and # restored at relink time. variables_saved_for_relink=3D"PATH LD_LIBRARY_PATH LD_RUN_PATH GCC_EXEC_PRE= FIX COMPILER_PATH LIBRARY_PATH" # Whether libtool must link a program against all its dependency libraries. link_all_deplibs=3Dunknown # Compile-time system search path for libraries sys_lib_search_path_spec=3D"/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib/" # Run-time system search path for libraries sys_lib_dlsearch_path_spec=3D"/lib /usr/lib /usr/X11R6/lib" # Fix the shell variable $srcfile for the compiler. fix_srcfile_path=3D"" # Set to yes if exported symbols are required. always_export_symbols=3Dno # The commands to list exported symbols. export_symbols_cmds=3D"\$NM \$libobjs \$convenience | \$global_symbol_pipe = | \$SED 's/.* //' | sort | uniq > \$export_symbols" # The commands to extract the exported symbol list from a shared archive. extract_expsyms_cmds=3D"" # Symbols that should not be listed in the preloaded symbols. exclude_expsyms=3D"_GLOBAL_OFFSET_TABLE_" # Symbols that must always be exported. include_expsyms=3D"" # ### END LIBTOOL TAG CONFIG: F77 # ### BEGIN LIBTOOL TAG CONFIG: GCJ # Libtool was configured on host descent.netsplit.com: # Shell to use when invoking shell scripts. SHELL=3D"/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=3Dyes # Whether or not to build static libraries. build_old_libs=3Dyes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=3Dno # Whether or not to disallow shared libs when runtime libs are static allow_libtool_libs_with_static_runtimes=3Dno # Whether or not to optimize for fast installation. fast_install=3Dyes # The host system. host_alias=3D host=3Di386-pc-linux-gnu # An echo program that does not interpret backslashes. echo=3D"echo" # The archiver. AR=3D"ar" AR_FLAGS=3D"cru" # A C compiler. LTCC=3D"gcc" # A language-specific compiler. CC=3D"gcj" # Is the compiler the GNU C compiler? with_gcc=3D # An ERE matcher. EGREP=3D"grep -E" # The linker used to build libraries. LD=3D"" # Whether we need hard or soft links. LN_S=3D"ln -s" # A BSD-compatible nm program. NM=3D"/usr/bin/nm -B" # A symbol stripping program STRIP=3D"strip" # Used to examine libraries when file_magic_cmd begins "file" MAGIC_CMD=3Dfile # Used on cygwin: DLL creation program. DLLTOOL=3D"dlltool" # Used on cygwin: object dumper. OBJDUMP=3D"objdump" # Used on cygwin: assembler. AS=3D"as" # The name of the directory that contains temporary libtool files. objdir=3D.libs # How to create reloadable object files. reload_flag=3D" -r" reload_cmds=3D"\$LD\$reload_flag -o \$output\$reload_objs" # How to pass a linker flag through the compiler. wl=3D"-Wl," # Object file suffix (normally "o"). objext=3D"o" # Old archive suffix (normally "a"). libext=3D"a" # Shared library suffix (normally ".so"). shrext=3D'.so' # Executable file suffix (normally ""). exeext=3D"" # Additional compiler flags for building library objects. pic_flag=3D" -fPIC" pic_mode=3Ddefault # What is the maximum length of a command? max_cmd_len=3D32768 # Does compiler simultaneously support -c and -o options? compiler_c_o=3D"yes" # Must we lock files when doing compilation ? need_locks=3D"no" # Do we need the lib prefix for modules? need_lib_prefix=3Dno # Do we need a version for libraries? need_version=3Dno # Whether dlopen is supported. dlopen_support=3Dyes # Whether dlopen of programs is supported. dlopen_self=3Dyes # Whether dlopen of statically linked programs is supported. dlopen_self_static=3Dyes # Compiler flag to prevent dynamic linking. link_static_flag=3D"-static" # Compiler flag to turn off builtin functions. no_builtin_flag=3D" -fno-builtin" # Compiler flag to allow reflexive dlopens. export_dynamic_flag_spec=3D"\${wl}--export-dynamic" # Compiler flag to generate shared objects directly from archives. whole_archive_flag_spec=3D"\${wl}--whole-archive\$convenience \${wl}--no-wh= ole-archive" # Compiler flag to generate thread-safe objects. thread_safe_flag_spec=3D"" # Library versioning type. version_type=3Dlinux # Format of library name prefix. libname_spec=3D"lib\$name" # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. library_names_spec=3D"\${libname}\${release}\${shared_ext}\$versuffix \${li= bname}\${release}\${shared_ext}\$major \$libname\${shared_ext}" # The coded name of the library, if different from the real name. soname_spec=3D"\${libname}\${release}\${shared_ext}\$major" # Commands used to build and install an old-style archive. RANLIB=3D"ranlib" old_archive_cmds=3D"" old_postinstall_cmds=3D"\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds=3D"" # Create an old-style archive from a shared archive. old_archive_from_new_cmds=3D"" # Create a temporary old-style archive to link instead of a shared archive. old_archive_from_expsyms_cmds=3D"" # Commands used to build and install a shared archive. archive_cmds=3D"\$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-so= name \$wl\$soname -o \$lib" archive_expsym_cmds=3D"\$echo \\\"{ global:\\\" > \$output_objdir/\$libname= =2Ever~ cat \$export_symbols | sed -e \\\"s/\\\\(.*\\\\)/\\\\1;/\\\" >> \$output_ob= jdir/\$libname.ver~ \$echo \\\"local: *; };\\\" >> \$output_objdir/\$libname.ver~ \$CC -shared \$libobjs \$deplibs \$compiler_flags \${wl}-soname \$w= l\$soname \${wl}-version-script \${wl}\$output_objdir/\$libname.ver -o \$li= b" postinstall_cmds=3D"" postuninstall_cmds=3D"" # Commands used to build a loadable module (assumed same as above if empty) module_cmds=3D"" module_expsym_cmds=3D"" # Commands to strip libraries. old_striplib=3D"strip --strip-debug" striplib=3D"strip --strip-unneeded" # Dependencies to place before the objects being linked to create a # shared library. predep_objects=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdep_objects=3D"" # Dependencies to place before the objects being linked to create a # shared library. predeps=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdeps=3D"" # The library search path used internally by the compiler when linking # a shared library. compiler_lib_search_path=3D"" # Method to check whether dependent libraries are shared objects. deplibs_check_method=3D"pass_all" # Command to use when deplibs_check_method =3D=3D file_magic. file_magic_cmd=3D"\$MAGIC_CMD" # Flag that allows shared libraries with undefined symbols to be built. allow_undefined_flag=3D"" # Flag that forces no undefined symbols. no_undefined_flag=3D"" # Commands used to finish a libtool library installation in a directory. finish_cmds=3D"PATH=3D\\\"\\\$PATH:/sbin\\\" ldconfig -n \$libdir" # Same as above, but a single script fragment to be evaled but not shown. finish_eval=3D"" # Take the output of nm and produce a listing of raw symbols and C names. global_symbol_pipe=3D"sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ = ][ ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2\\3 \\3/p'" # Transform the output of nm in a proper C declaration global_symbol_to_cdecl=3D"sed -n -e 's/^. .* \\(.*\\)\$/extern int \\1;/p'" # Transform the output of nm in a C name address pair global_symbol_to_c_name_address=3D"sed -n -e 's/^: \\([^ ]*\\) \$/ {\\\"\\= 1\\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2= \", (lt_ptr) \\&\\2},/p'" # This is the shared library runtime path variable. runpath_var=3DLD_RUN_PATH # This is the shared library path variable. shlibpath_var=3DLD_LIBRARY_PATH # Is shlibpath searched before the hard-coded library search path? shlibpath_overrides_runpath=3Dno # How to hardcode a shared library path into an executable. hardcode_action=3Dimmediate # Whether we should hardcode library paths into libraries. hardcode_into_libs=3Dyes # Flag to hardcode $libdir into a binary during linking. # This must work even if $libdir does not exist. hardcode_libdir_flag_spec=3D"\${wl}--rpath \${wl}\$libdir" # If ld is used when linking, flag to hardcode $libdir into # a binary during linking. This must work even if $libdir does # not exist. hardcode_libdir_flag_spec_ld=3D"" # Whether we need a single -rpath flag with a separated argument. hardcode_libdir_separator=3D"" # Set to yes if using DIR/libNAME during linking hardcodes DIR into the # resulting binary. hardcode_direct=3Dno # Set to yes if using the -LDIR flag during linking hardcodes DIR into the # resulting binary. hardcode_minus_L=3Dno # Set to yes if using SHLIBPATH_VAR=3DDIR during linking hardcodes DIR into # the resulting binary. hardcode_shlibpath_var=3Dunsupported # Set to yes if building a shared library automatically hardcodes DIR into = the library # and all subsequent libraries and executables linked against it. hardcode_automatic=3Dno # Variables whose values should be saved in libtool wrapper scripts and # restored at relink time. variables_saved_for_relink=3D"PATH LD_LIBRARY_PATH LD_RUN_PATH GCC_EXEC_PRE= FIX COMPILER_PATH LIBRARY_PATH" # Whether libtool must link a program against all its dependency libraries. link_all_deplibs=3Dunknown # Compile-time system search path for libraries sys_lib_search_path_spec=3D"/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib/" # Run-time system search path for libraries sys_lib_dlsearch_path_spec=3D"/lib /usr/lib /usr/X11R6/lib" # Fix the shell variable $srcfile for the compiler. fix_srcfile_path=3D"" # Set to yes if exported symbols are required. always_export_symbols=3Dno # The commands to list exported symbols. export_symbols_cmds=3D"\$NM \$libobjs \$convenience | \$global_symbol_pipe = | \$SED 's/.* //' | sort | uniq > \$export_symbols" # The commands to extract the exported symbol list from a shared archive. extract_expsyms_cmds=3D"" # Symbols that should not be listed in the preloaded symbols. exclude_expsyms=3D"_GLOBAL_OFFSET_TABLE_" # Symbols that must always be exported. include_expsyms=3D"" # ### END LIBTOOL TAG CONFIG: GCJ # ### BEGIN LIBTOOL TAG CONFIG: BINCC # A C compiler. LTCC=3D"cc" # A language-specific compiler. CC=3D"cc" # ### END LIBTOOL TAG CONFIG: BINCC # ### BEGIN LIBTOOL TAG CONFIG: BINCXX # Libtool was configured on host descent.netsplit.com: # Shell to use when invoking shell scripts. SHELL=3D"/bin/sh" # Whether or not to build shared libraries. build_libtool_libs=3Dyes # Whether or not to build static libraries. build_old_libs=3Dyes # Whether or not to add -lc for building shared libraries. build_libtool_need_lc=3Dno # Whether or not to disallow shared libs when runtime libs are static allow_libtool_libs_with_static_runtimes=3Dno # Whether or not to optimize for fast installation. fast_install=3Dyes # The host system. host_alias=3D host=3Di386-pc-linux-gnu # An echo program that does not interpret backslashes. echo=3D"echo" # The archiver. AR=3D"ar" AR_FLAGS=3D"cru" # A C compiler. LTCC=3D"gcc" # A language-specific compiler. CC=3D"c++" # Is the compiler the GNU C compiler? with_gcc=3Dyes # An ERE matcher. EGREP=3D"grep -E" # The linker used to build libraries. LD=3D"/usr/bin/ld" # Whether we need hard or soft links. LN_S=3D"ln -s" # A BSD-compatible nm program. NM=3D"/usr/bin/nm -B" # A symbol stripping program STRIP=3D"strip" # Used to examine libraries when file_magic_cmd begins "file" MAGIC_CMD=3Dfile # Used on cygwin: DLL creation program. DLLTOOL=3D"dlltool" # Used on cygwin: object dumper. OBJDUMP=3D"objdump" # Used on cygwin: assembler. AS=3D"as" # The name of the directory that contains temporary libtool files. objdir=3D.libs # How to create reloadable object files. reload_flag=3D" -r" reload_cmds=3D"\$LD\$reload_flag -o \$output\$reload_objs" # How to pass a linker flag through the compiler. wl=3D"-Wl," # Object file suffix (normally "o"). objext=3D"o" # Old archive suffix (normally "a"). libext=3D"a" # Shared library suffix (normally ".so"). shrext=3D'.so' # Executable file suffix (normally ""). exeext=3D"" # Additional compiler flags for building library objects. pic_flag=3D" -fPIC -DPIC" pic_mode=3Ddefault # What is the maximum length of a command? max_cmd_len=3D32768 # Does compiler simultaneously support -c and -o options? compiler_c_o=3D"yes" # Must we lock files when doing compilation ? need_locks=3D"no" # Do we need the lib prefix for modules? need_lib_prefix=3Dno # Do we need a version for libraries? need_version=3Dno # Whether dlopen is supported. dlopen_support=3Dyes # Whether dlopen of programs is supported. dlopen_self=3Dyes # Whether dlopen of statically linked programs is supported. dlopen_self_static=3Dyes # Compiler flag to prevent dynamic linking. link_static_flag=3D"-static" # Compiler flag to turn off builtin functions. no_builtin_flag=3D" -fno-builtin" # Compiler flag to allow reflexive dlopens. export_dynamic_flag_spec=3D"\${wl}--export-dynamic" # Compiler flag to generate shared objects directly from archives. whole_archive_flag_spec=3D"\${wl}--whole-archive\$convenience \${wl}--no-wh= ole-archive" # Compiler flag to generate thread-safe objects. thread_safe_flag_spec=3D"" # Library versioning type. version_type=3Dlinux # Format of library name prefix. libname_spec=3D"lib\$name" # List of archive names. First name is the real one, the rest are links. # The last name is the one that the linker finds with -lNAME. library_names_spec=3D"\${libname}\${release}\${shared_ext}\$versuffix \${li= bname}\${release}\${shared_ext}\$major \$libname\${shared_ext}" # The coded name of the library, if different from the real name. soname_spec=3D"\${libname}\${release}\${shared_ext}\$major" # Commands used to build and install an old-style archive. RANLIB=3D"ranlib" old_archive_cmds=3D"\$AR \$AR_FLAGS \$oldlib\$oldobjs\$old_deplibs~\$RANLIB= \$oldlib" old_postinstall_cmds=3D"\$RANLIB \$oldlib~chmod 644 \$oldlib" old_postuninstall_cmds=3D"" # Create an old-style archive from a shared archive. old_archive_from_new_cmds=3D"" # Create a temporary old-style archive to link instead of a shared archive. old_archive_from_expsyms_cmds=3D"" # Commands used to build and install a shared archive. archive_cmds=3D"\$CC -shared \$predep_objects \$libobjs \$deplibs \$postdep= _objects \$compiler_flags \${wl}-soname \$wl\$soname -o \$lib" archive_expsym_cmds=3D"\$CC -shared \$predep_objects \$libobjs \$deplibs \$= postdep_objects \$compiler_flags \${wl}-soname \$wl\$soname \${wl}-retain-s= ymbols-file \$wl\$export_symbols -o \$lib" postinstall_cmds=3D"" postuninstall_cmds=3D"" # Commands used to build a loadable module (assumed same as above if empty) module_cmds=3D"" module_expsym_cmds=3D"" # Commands to strip libraries. old_striplib=3D"strip --strip-debug" striplib=3D"strip --strip-unneeded" # Dependencies to place before the objects being linked to create a # shared library. predep_objects=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdep_objects=3D"" # Dependencies to place before the objects being linked to create a # shared library. predeps=3D"" # Dependencies to place after the objects being linked to create a # shared library. postdeps=3D"-lstdc++ -lm -lgcc_s -lc -lgcc_s" # The library search path used internally by the compiler when linking # a shared library. compiler_lib_search_path=3D"" # Method to check whether dependent libraries are shared objects. deplibs_check_method=3D"pass_all" # Command to use when deplibs_check_method =3D=3D file_magic. file_magic_cmd=3D"\$MAGIC_CMD" # Flag that allows shared libraries with undefined symbols to be built. allow_undefined_flag=3D"" # Flag that forces no undefined symbols. no_undefined_flag=3D"" # Commands used to finish a libtool library installation in a directory. finish_cmds=3D"PATH=3D\\\"\\\$PATH:/sbin\\\" ldconfig -n \$libdir" # Same as above, but a single script fragment to be evaled but not shown. finish_eval=3D"" # Take the output of nm and produce a listing of raw symbols and C names. global_symbol_pipe=3D"sed -n -e 's/^.*[ ]\\([ABCDGIRSTW][ABCDGIRSTW]*\\)[ = ][ ]*\\(\\)\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2\\3 \\3/p'" # Transform the output of nm in a proper C declaration global_symbol_to_cdecl=3D"sed -n -e 's/^. .* \\(.*\\)\$/extern int \\1;/p'" # Transform the output of nm in a C name address pair global_symbol_to_c_name_address=3D"sed -n -e 's/^: \\([^ ]*\\) \$/ {\\\"\\= 1\\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2= \", (lt_ptr) \\&\\2},/p'" # This is the shared library runtime path variable. runpath_var=3DLD_RUN_PATH # This is the shared library path variable. shlibpath_var=3DLD_LIBRARY_PATH # Is shlibpath searched before the hard-coded library search path? shlibpath_overrides_runpath=3Dno # How to hardcode a shared library path into an executable. hardcode_action=3Dimmediate # Whether we should hardcode library paths into libraries. hardcode_into_libs=3Dyes # Flag to hardcode $libdir into a binary during linking. # This must work even if $libdir does not exist. hardcode_libdir_flag_spec=3D"\${wl}--rpath \${wl}\$libdir" # If ld is used when linking, flag to hardcode $libdir into # a binary during linking. This must work even if $libdir does # not exist. hardcode_libdir_flag_spec_ld=3D"" # Whether we need a single -rpath flag with a separated argument. hardcode_libdir_separator=3D"" # Set to yes if using DIR/libNAME during linking hardcodes DIR into the # resulting binary. hardcode_direct=3Dno # Set to yes if using the -LDIR flag during linking hardcodes DIR into the # resulting binary. hardcode_minus_L=3Dno # Set to yes if using SHLIBPATH_VAR=3DDIR during linking hardcodes DIR into # the resulting binary. hardcode_shlibpath_var=3D # Set to yes if building a shared library automatically hardcodes DIR into = the library # and all subsequent libraries and executables linked against it. hardcode_automatic=3Dno # Variables whose values should be saved in libtool wrapper scripts and # restored at relink time. variables_saved_for_relink=3D"PATH LD_LIBRARY_PATH LD_RUN_PATH GCC_EXEC_PRE= FIX COMPILER_PATH LIBRARY_PATH" # Whether libtool must link a program against all its dependency libraries. link_all_deplibs=3Dunknown # Compile-time system search path for libraries sys_lib_search_path_spec=3D"/lib/ /usr/lib/ /usr/X11R6/lib/ /usr/local/lib/" # Run-time system search path for libraries sys_lib_dlsearch_path_spec=3D"/lib /usr/lib /usr/X11R6/lib" # Fix the shell variable $srcfile for the compiler. fix_srcfile_path=3D"" # Set to yes if exported symbols are required. always_export_symbols=3Dno # The commands to list exported symbols. export_symbols_cmds=3D"\$NM \$libobjs \$convenience | \$global_symbol_pipe = | \$SED 's/.* //' | sort | uniq > \$export_symbols" # The commands to extract the exported symbol list from a shared archive. extract_expsyms_cmds=3D"" # Symbols that should not be listed in the preloaded symbols. exclude_expsyms=3D"" # Symbols that must always be exported. include_expsyms=3D"" # ### END LIBTOOL TAG CONFIG: BINCXX --BOKacYhQ+x31HxR3-- From owner-linux-xfs@oss.sgi.com Sun Feb 22 17:25:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Feb 2004 17:26:08 -0800 (PST) Received: from mail.osdl.org (fw.osdl.org [65.172.181.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1N1PsKO024268 for ; Sun, 22 Feb 2004 17:25:55 -0800 Received: from mnm (build.pdx.osdl.net [172.20.1.2]) by mail.osdl.org (8.11.6/8.11.6) with ESMTP id i1N1PnE05142 for ; Sun, 22 Feb 2004 17:25:49 -0800 Date: Sun, 22 Feb 2004 17:26:33 -0800 From: Andrew Morton To: linux-xfs@oss.sgi.com Subject: Fw: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) Message-Id: <20040222172633.6ed10684.akpm@osdl.org> X-Mailer: Sylpheed version 0.9.4 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 2186 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: linux-xfs XFS went boom... Begin forwarded message: Date: Sun, 22 Feb 2004 16:49:41 +0100 From: Mikael Wahlberg To: linux-kernel@vger.kernel.org Subject: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) Description: On heavy FTP Load (About 1Gbit/s) running both reads and writes on two ServeRAID6m Raid5 controllers merged together to one filesystem with Raidtools we see the error below. The filesystem gets totally hanged up. Currently with XFS, but JFS gets the same problem (Actually even more often). Anybody has got a good idea what can be wrong? Distribution: RedHat 9.0 Hardware: IBM x345 2x2.4GHz Xeon 2xServeRAID6m Error: (/var/log/messages) Feb 22 15:00:51 mserv1 kernel: Unable to handle kernel NULL pointer dereference at virtual address 000002a6 Feb 22 15:00:52 mserv1 kernel: printing eip: Feb 22 15:00:52 mserv1 kernel: c011e5b5 Feb 22 15:00:52 mserv1 kernel: *pde = 00000000 Feb 22 15:00:52 mserv1 kernel: Oops: 0002 [#1] Feb 22 15:00:52 mserv1 kernel: CPU: 1 Feb 22 15:00:52 mserv1 kernel: EIP: 0060:[] Not tainted Feb 22 15:00:52 mserv1 kernel: EFLAGS: 00010003 Feb 22 15:00:52 mserv1 kernel: Process proftpd (pid: 7432, threadinfo=ee530000 task=ef59a6b0) Feb 22 15:00:52 mserv1 kernel: Stack: c011e54a ee531a28 00000003 00000000 ddcdfeec ee530000 ddcdfee8 00000292 Feb 22 15:00:53 mserv1 kernel: ee531a50 c011e5af ddcdfee8 00000003 00000001 00000000 ddcdfee0 ddcdfe50 Feb 22 15:00:53 mserv1 kernel: 00000000 f5e36000 c0259e62 c0259b00 000000c8 c023038e ddcdfee0 000b2f80 Feb 22 15:00:53 mserv1 kernel: Call Trace: Feb 22 15:00:53 mserv1 kernel: [] __wake_up_common+0x3a/0x60 Feb 22 15:00:53 mserv1 kernel: [] __wake_up+0x3f/0x70 Feb 22 15:00:53 mserv1 kernel: [] mrunlock+0x82/0xb0 Feb 22 15:00:53 mserv1 kernel: [] mraccessf+0xc0/0xe0 Feb 22 15:00:53 mserv1 kernel: [] xfs_iunlock+0x3e/0x80 Feb 22 15:00:53 mserv1 kernel: [] xfs_iomap+0x3bb/0x540 Feb 22 15:00:53 mserv1 kernel: [] bio_alloc+0xd7/0x1c0 Feb 22 15:00:53 mserv1 kernel: [] map_blocks+0x7a/0x170 Feb 22 15:00:53 mserv1 kernel: [] page_state_convert+0x52b/0x6d0 Feb 22 15:00:53 mserv1 kernel: [] xfs_imap_to_bmap+0x39/0x240 Feb 22 15:00:53 mserv1 kernel: [] linvfs_release_page+0xa8/0xb0 Feb 22 15:00:53 mserv1 kernel: [] linvfs_writepage+0x60/0x120 Feb 22 15:00:53 mserv1 kernel: [] shrink_list+0x41c/0x710 Feb 22 15:00:53 mserv1 kernel: [] shrink_cache+0x1f8/0x3d0 Feb 22 15:00:53 mserv1 kernel: [] journal_stop+0x220/0x330 Feb 22 15:00:53 mserv1 kernel: [] shrink_zone+0xbc/0xc0 Feb 22 15:00:53 mserv1 kernel: [] shrink_caches+0xc5/0xe0 Feb 22 15:00:54 mserv1 kernel: [] try_to_free_pages+0xbc/0x190 Feb 22 15:00:54 mserv1 kernel: [] __alloc_pages+0x203/0x370 Feb 22 15:00:54 mserv1 kernel: [] __get_free_pages+0x25/0x40 Feb 22 15:00:54 mserv1 kernel: [] __pollwait+0x41/0xd0 Feb 22 15:00:54 mserv1 kernel: [] tcp_poll+0x33/0x190 Feb 22 15:00:54 mserv1 kernel: [] sock_poll+0x29/0x40 Feb 22 15:00:54 mserv1 kernel: [] do_select+0x2f7/0x320 Feb 22 15:00:54 mserv1 kernel: [] __pollwait+0x0/0xd0 Feb 22 15:00:54 mserv1 kernel: [] sys_select+0x302/0x540 Feb 22 15:00:54 mserv1 kernel: [] syscall_call+0x7/0xb Feb 22 15:00:54 mserv1 kernel: Feb 22 15:00:54 mserv1 kernel: Code: ff 4b 14 8b 43 08 83 e0 08 75 0d 8b 5d f4 8b 75 f8 8b 7d fc Feb 22 15:00:54 mserv1 kernel: [] sys_select+0x302/0x540 Feb 22 15:00:54 mserv1 kernel: [] syscall_call+0x7/0xb Feb 22 15:00:54 mserv1 kernel: Feb 22 15:00:54 mserv1 kernel: Code: ff 4b 14 8b 43 08 83 e0 08 75 0d 8b 5d f4 8b 75 f8 8b 7d fc Feb 22 15:00:54 mserv1 kernel: <6>note: proftpd[7432] exited with preempt_count 2 Feb 22 15:00:54 mserv1 kernel: bad: scheduling while atomic! Feb 22 15:00:54 mserv1 kernel: Call Trace: Feb 22 15:00:54 mserv1 kernel: [] schedule+0x6ee/0x700 Feb 22 15:00:54 mserv1 kernel: [] zap_pmd_range+0x4b/0x70 Feb 22 15:00:54 mserv1 kernel: [] free_pages_and_swap_cache+0x6a/0xa0 Feb 22 15:00:54 mserv1 kernel: [] unmap_vmas+0x23c/0x2f0 Feb 22 15:00:54 mserv1 kernel: [] exit_mmap+0xf4/0x250 Feb 22 15:00:54 mserv1 kernel: [] mmput+0x6d/0xa0 Feb 22 15:00:54 mserv1 kernel: [] do_exit+0x1a3/0x500 Feb 22 15:00:54 mserv1 kernel: [] die+0xfc/0x100 Feb 22 15:00:54 mserv1 kernel: [] do_page_fault+0x1f9/0x523 Feb 22 15:00:54 mserv1 kernel: [] mempool_alloc+0x8b/0x190 Feb 22 15:00:54 mserv1 kernel: [] do_page_fault+0x0/0x523 Feb 22 15:00:54 mserv1 kernel: [] error_code+0x2d/0x38 Feb 22 15:00:54 mserv1 kernel: [] __wake_up+0x45/0x70 Feb 22 15:00:54 mserv1 kernel: [] __wake_up_common+0x3a/0x60 Feb 22 15:00:55 mserv1 kernel: [] __wake_up+0x3f/0x70 Feb 22 15:00:55 mserv1 kernel: [] mrunlock+0x82/0xb0 Feb 22 15:00:55 mserv1 kernel: [] mraccessf+0xc0/0xe0 Feb 22 15:00:55 mserv1 kernel: [] xfs_iunlock+0x3e/0x80 Feb 22 15:00:55 mserv1 kernel: [] xfs_iomap+0x3bb/0x540 Feb 22 15:00:55 mserv1 kernel: [] bio_alloc+0xd7/0x1c0 Feb 22 15:00:55 mserv1 kernel: [] map_blocks+0x7a/0x170 Feb 22 15:00:55 mserv1 kernel: [] page_state_convert+0x52b/0x6d0 Feb 22 15:00:55 mserv1 kernel: [] xfs_imap_to_bmap+0x39/0x240 Feb 22 15:00:55 mserv1 kernel: [] linvfs_release_page+0xa8/0xb0 Feb 22 15:00:55 mserv1 kernel: [] linvfs_writepage+0x60/0x120 Feb 22 15:00:55 mserv1 kernel: [] shrink_list+0x41c/0x710 Feb 22 15:00:55 mserv1 kernel: [] shrink_cache+0x1f8/0x3d0 Feb 22 15:00:55 mserv1 kernel: [] journal_stop+0x220/0x330 Feb 22 15:00:55 mserv1 kernel: [] shrink_zone+0xbc/0xc0 Feb 22 15:00:55 mserv1 kernel: [] shrink_caches+0xc5/0xe0 Feb 22 15:00:55 mserv1 kernel: [] try_to_free_pages+0xbc/0x190 Feb 22 15:00:55 mserv1 kernel: [] __alloc_pages+0x203/0x370 Feb 22 15:00:55 mserv1 kernel: [] __get_free_pages+0x25/0x40 Feb 22 15:00:55 mserv1 kernel: [] __pollwait+0x41/0xd0 Feb 22 15:00:55 mserv1 kernel: [] tcp_poll+0x33/0x190 Feb 22 15:00:55 mserv1 kernel: [] sock_poll+0x29/0x40 Feb 22 15:00:55 mserv1 kernel: [] do_select+0x2f7/0x320 Feb 22 15:00:55 mserv1 kernel: [] __pollwait+0x0/0xd0 Feb 22 15:00:55 mserv1 kernel: [] sys_select+0x302/0x540 Feb 22 15:00:55 mserv1 kernel: [] syscall_call+0x7/0xb Feb 22 15:00:55 mserv1 kernel: Feb 22 15:00:55 mserv1 kernel: Unable to handle kernel NULL pointer dereference at virtual address 000002a6 Feb 22 15:00:55 mserv1 kernel: printing eip: Feb 22 15:00:55 mserv1 kernel: c011e5b5 Feb 22 15:00:55 mserv1 kernel: *pde = 00000000 Feb 22 15:00:55 mserv1 kernel: Oops: 0002 [#2] Feb 22 15:00:55 mserv1 kernel: CPU: 1 Feb 22 15:00:55 mserv1 kernel: EIP: 0060:[] Not tainted Feb 22 15:00:55 mserv1 kernel: EFLAGS: 00010003 Feb 22 15:00:55 mserv1 kernel: EIP is at __wake_up+0x45/0x70 Feb 22 15:00:55 mserv1 kernel: eax: ee531a00 ebx: 00000292 ecx: 00000001 edx: 00000003 Feb 22 15:00:55 mserv1 kernel: esi: ddcdfee8 edi: 00000001 ebp: c2ae5d80 esp: c2ae5d60 Feb 22 15:00:55 mserv1 kernel: ds: 007b es: 007b ss: 0068 Feb 22 15:00:55 mserv1 kernel: Process pdflush (pid: 20, threadinfo=c2ae4000 task=c2aead20) Feb 22 15:00:55 mserv1 kernel: Stack: c011e54a ee531a28 00000003 00000000 ddcdfeec c2ae4000 ddcdfee8 00000296 Feb 22 15:00:55 mserv1 kernel: c2ae5da4 c011e5af ddcdfee8 00000003 00000001 00000000 ddcdfee0 ddcdfe50 Feb 22 15:00:56 mserv1 kernel: e25319a0 f5e36000 c0259e62 00000008 00000008 c023038e ddcdfee0 ddcdfe50 Feb 22 15:00:56 mserv1 kernel: Call Trace: Feb 22 15:00:56 mserv1 kernel: [] __wake_up_common+0x3a/0x60 Feb 22 15:00:56 mserv1 kernel: [] __wake_up+0x3f/0x70 Feb 22 15:00:56 mserv1 kernel: [] mrunlock+0x82/0xb0 Feb 22 15:00:56 mserv1 kernel: [] xfs_iunlock+0x3e/0x80 Feb 22 15:00:56 mserv1 kernel: [] xfs_iflush+0x36a/0x550 Feb 22 15:00:56 mserv1 kernel: [] xfs_inode_flush+0x255/0x2c0 Feb 22 15:00:56 mserv1 kernel: [] default_wake_function+0x0/0x20 Feb 22 15:00:56 mserv1 kernel: [] linvfs_writepage+0x0/0x120 Feb 22 15:00:56 mserv1 kernel: [] linvfs_write_inode+0x32/0x40 Feb 22 15:00:56 mserv1 kernel: [] write_inode+0x46/0x50 Feb 22 15:00:56 mserv1 kernel: [] __sync_single_inode+0x250/0x2a0 Feb 22 15:00:56 mserv1 kernel: [] sync_sb_inodes+0x1ac/0x2a0 Feb 22 15:00:56 mserv1 kernel: [] writeback_inodes+0x89/0x130 Feb 22 15:00:56 mserv1 kernel: [] background_writeout+0xb8/0x100 Feb 22 15:00:56 mserv1 kernel: [] __pdflush+0x10a/0x220 Feb 22 15:00:56 mserv1 kernel: [] pdflush+0x0/0x20 Feb 22 15:00:56 mserv1 kernel: [] pdflush+0xf/0x20 Feb 22 15:00:56 mserv1 kernel: [] background_writeout+0x0/0x100 Feb 22 15:00:56 mserv1 kernel: [] kernel_thread_helper+0x0/0xc Feb 22 15:00:56 mserv1 kernel: [] kernel_thread_helper+0x5/0xc Feb 22 15:00:56 mserv1 kernel: Feb 22 15:00:56 mserv1 kernel: Code: ff 4b 14 8b 43 08 83 e0 08 75 0d 8b 5d f4 8b 75 f8 8b 7d fc Feb 22 15:00:56 mserv1 kernel: <6>note: pdflush[20] exited with preempt_count 3 /Mikael -- ----------------------------------------------------------------------- Mikael Wahlberg, M.Sc. Ardendo Unit Manager Professional Services/ e-mail: mikael@ardendo.se Technical Project Manager GSM: +46 733 279 274 - 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/ From owner-linux-xfs@oss.sgi.com Sun Feb 22 23:46:07 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 22 Feb 2004 23:46:21 -0800 (PST) Received: from mail.tamiweb.com (mail.tamiweb.com [194.12.244.146]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1N7k2KO019072 for ; Sun, 22 Feb 2004 23:46:05 -0800 Received: (qmail 24579 invoked by uid 89); 23 Feb 2004 07:45:51 -0000 Received: from unknown (HELO tamiweb.com) (212.122.164.1) by 0 with SMTP; 23 Feb 2004 07:45:51 -0000 Message-ID: <4039AFA4.4020509@tamiweb.com> Date: Mon, 23 Feb 2004 09:45:40 +0200 From: Kostadin Karaivanov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031014 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: linux-xfs@oss.sgi.com Subject: Re: xfs-progs and libtool-1.5.2 issues References: <4034E1C9.9050103@tamiweb.com> <20040222232730.GA3213@frodo> In-Reply-To: <20040222232730.GA3213@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2187 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: larry@tamiweb.com Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > On Thu, Feb 19, 2004 at 06:18:17PM +0200, Kostadin Karaivanov wrote: > >>Recently I upgarded my libtool to 1.5.2 (slackware-current) >>nad I'm n unable to compile xfs-cms anymore >>following error is excerpt from >>make in xfs-cmds/attr >> >>make -C . default >>make[1]: Entering directory `/usr/src/xfs-cmds/attr' >>=== include === >>rm -f attr >>ln -s . attr >>=== libmisc === >>/usr/bin/libtool --mode=compile gcc -g -DDEBUG -funsigned-char -Wall >>-I../include -DVERSION=\"2.4.15\" -DLOCALEDIR=\"/usr/share/locale\" >>-DPACKAGE=\"attr\" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_REENTRANT >>-fno-strict-aliasing -c quote.c >>libtool: compile: unable to infer tagged configuration >>libtool: compile: specify a tag with `--tag' >>make[2]: *** [quote.lo] Error 1 >>make[1]: *** [default] Error 2 >>make[1]: Leaving directory `/usr/src/xfs-cmds/attr' >>make: *** [default] Error 2 >> > > > I have libtool 1.5.2 (Debian unstable), and it works fine here. > The libtool script is a bit of a rats nest, but from a quick > read it looks like you may have CC set to something other than > what libtool thinks the base compiler is..? You may be able It apears so.... > to find out more by running "sh -x libtool ..." from within the > Makefiles and then seeing where it gets confused. If you have > a working libtool script, might be easier to diff it with your > current version... (I've attached my /usr/bin/libtool - is it > any different to yours?) > > cheers. > > > After little diffing I found that the only noticeble difference between your libtool and mine is in the lines defining LTCC and CC. In Slackwares libtool they are defined as LTCC="i486-slackware-linux-gcc" CC="i486-slackware-linux-gcc" which in turn is hyperlink to gcc-3.3.3 both are present..... when I changed those definitions to simple "gcc" (which also is hyperlink to gcc-3.3.3) everything i OK again From owner-linux-xfs@oss.sgi.com Mon Feb 23 02:52:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 02:52:06 -0800 (PST) Received: from web25208.mail.ukl.yahoo.com (web25208.mail.ukl.yahoo.com [217.12.10.68]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NAq2KO027424 for ; Mon, 23 Feb 2004 02:52:03 -0800 Message-ID: <20040223105157.19881.qmail@web25208.mail.ukl.yahoo.com> Received: from [195.173.4.13] by web25208.mail.ukl.yahoo.com via HTTP; Mon, 23 Feb 2004 10:51:57 GMT Date: Mon, 23 Feb 2004 10:51:57 +0000 (GMT) From: =?iso-8859-1?q?Alexander=20Fisher?= Subject: large allocation groups fix 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: 2188 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexjfisher@yahoo.co.uk Precedence: bulk X-list: linux-xfs Hi. I'm running a vendor modified kernel 2.4.20-pre2 into which I have patched the 1.3.1 xfs 2.4.21 patches. Doing this wasn't too tricky although I needed to integrate a few bitkeeper changesets to get this to work. I'm using xfs on large filesystems 1TB+ and have quickly noticed the problem with the large allocation group size that the latest version of mkfs.xfs will create by default. I would like to 'fix' my kernel so that allocation group sizes above 4GB don't result in lockups. Is there a patch I can use against the 1.3.1 xfs release? I've looked at the fix included in kernel changeset 1.1276.1.2 http://linux.bkbits.net:8080/linux-2.4/cset@1.1276.1.2?nav=index.html|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_iomap.h but it doesn't apply to the official xfs release. On a related point, are there any plans to announce any more official xfs releases or is it just assumed that people will use upto date linux kernels? Thanks, Alex ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From owner-linux-xfs@oss.sgi.com Mon Feb 23 03:14:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 03:14:15 -0800 (PST) Received: from odin.sv.fintec.co.cr ([168.243.202.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NBE0KO028783 for ; Mon, 23 Feb 2004 03:14:01 -0800 Received: from interfilme.com ([192.168.201.229]) by odin.sv.fintec.co.cr (8.12.10/8.12.10) with ESMTP id i1NBDwp6010363 for ; Mon, 23 Feb 2004 05:13:59 -0600 Message-ID: <4039E05C.6050602@interfilme.com> Date: Mon, 23 Feb 2004 05:13:32 -0600 From: Ivan Kocher User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problem between XFS and JFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2189 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikocher@interfilme.com Precedence: bulk X-list: linux-xfs Hi, Yesterday I was hit by a nasty bug ... I tried to change the filesystem of a couple machines from XFS to JFS, so compiled kernel 2.4.23 with XFS (patch) and JFS. Once the jfs root partition was up, it booted, and xfs "tried" to repair the partition. I booted using my default setup and later after remaking all again using init=/bin/bash rw, and even later init=/bin/bash ro In the first two cases cases, xfs tried its "repair", teling that it recovered the journal... :( trashing the fs. When I booted in the third case, (ro) no problem... I wonder ... does xfs has some check for some magic in there? I tried in all machines, and in all it damaged the mounted / jfs fs ... Any ideas? Also, will there ever be a xfs patch for 2.4.24?? I know 2.4.25 has it... but for some reason I am having problems with a qlogic 2312 board with 2.4.25 ... :( so I was thinking on testing 2.4.24 ... ??? Thanks, Ivan PS: i'm still wondering why I did what i did... still don't see the real need ... From owner-linux-xfs@oss.sgi.com Mon Feb 23 03:53:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 03:53:28 -0800 (PST) Received: from hermod.acsalaska.net (hermod.acsalaska.net [209.112.155.45]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NBrCKO003597 for ; Mon, 23 Feb 2004 03:53:12 -0800 Received: from erbenson.alaska.net (104-pm6.nwc.acsalaska.net [209.112.139.104]) by hermod.acsalaska.net (8.12.10/8.12.10) with ESMTP id i1NBrAlG040128 for ; Mon, 23 Feb 2004 02:53:10 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id C6E2439E5 for ; Mon, 23 Feb 2004 02:53:08 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id D10B040FF35; Mon, 23 Feb 2004 02:53:08 -0900 (AKST) Date: Mon, 23 Feb 2004 02:53:08 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Problem between XFS and JFS Message-ID: <20040223115308.GC1003@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <4039E05C.6050602@interfilme.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CblX+4bnyfN0pR09" Content-Disposition: inline In-Reply-To: <4039E05C.6050602@interfilme.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-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.38; SA 2.61; spamdefang 1.93 X-archive-position: 2190 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --CblX+4bnyfN0pR09 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 23, 2004 at 05:13:32AM -0600, Ivan Kocher wrote: > Hi, >=20 > Yesterday I was hit by a nasty bug ... >=20 > I tried to change the filesystem of a couple machines from XFS to JFS,=20 > so compiled kernel 2.4.23 with XFS (patch) and JFS. Once the jfs root=20 > partition was up, it booted, and xfs "tried" to repair the partition. I= =20 > booted using my default setup and later after remaking all again using= =20 > init=3D/bin/bash rw, and even later init=3D/bin/bash ro >=20 > In the first two cases cases, xfs tried its "repair", teling that it=20 > recovered the journal... :( trashing the fs. >=20 > When I booted in the third case, (ro) no problem... >=20 > I wonder ... does xfs has some check for some magic in there? I tried=20 > in all machines, and in all it damaged the mounted / jfs fs ... sounds like mkfs.jfs is not zeroing enough of the device prior to writing its fs. particularly block zero where the XFS superblock lives. (some mkfs avoid zeroing this due to quirky partitioning setups on some architectures, notably Suns). >=20 > Any ideas? dd if=3D/dev/zero of=3D/dev/dev_being_mkfsed bs=3D512 count=3D100=20 prior to running mkfs. that should zero out enough to prevent any previous fs from being detected. >=20 > Also, will there ever be a xfs patch for 2.4.24?? I know 2.4.25 has=20 use the 2.4.23 patches, nothing changed in 2.4.24 that would affect xfs. > it... but for some reason I am having problems with a qlogic 2312 board= =20 > with 2.4.25 ... :( so I was thinking on testing 2.4.24 ... ??? apply the 2.4.23 split patches, all work and apply fine (except -misc, which you don't generally need anyway). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --CblX+4bnyfN0pR09 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEUEARECAAYFAkA56aQACgkQJKx7GixEevy8uwCfaJz3Lgai6X+OY+3rsfzASPKV k68AmP6CfczqYAIJ6eIMC2EDjm8u2MQ= =ysgk -----END PGP SIGNATURE----- --CblX+4bnyfN0pR09-- From owner-linux-xfs@oss.sgi.com Mon Feb 23 04:20:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 04:20:11 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NCK1KO007610 for ; Mon, 23 Feb 2004 04:20:04 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AvF43-0002Bu-Ud; Mon, 23 Feb 2004 12:19:59 +0000 Date: Mon, 23 Feb 2004 12:19:59 +0000 From: Christoph Hellwig To: Mikael Wahlberg Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) Message-ID: <20040223121959.A8354@infradead.org> Mail-Followup-To: Christoph Hellwig , Mikael Wahlberg , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20040222164941.D6046@foo.ardendo.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040222164941.D6046@foo.ardendo.se>; from Mikael.Wahlberg@ardendo.se on Sun, Feb 22, 2004 at 04:49:41PM +0100 X-archive-position: 2191 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Sun, Feb 22, 2004 at 04:49:41PM +0100, Mikael Wahlberg wrote: > Description: > > On heavy FTP Load (About 1Gbit/s) running both reads and writes on two ServeRAID6m Raid5 controllers merged together to one filesystem with Raidtools we see the error below. The filesystem gets totally hanged up. Currently with XFS, but JFS gets the same problem (Actually even more often). What does the JFS oops look like? > Feb 22 15:00:53 mserv1 kernel: [] __wake_up_common+0x3a/0x60 > Feb 22 15:00:53 mserv1 kernel: [] __wake_up+0x3f/0x70 This doesn't make a lot of sense, there's only two mrlocks in XFS, and they're in the inodes that have well-defined and understood lifetime rules. OTOH the previos oops might have messed quite a bit up in your system. did you run memtest86 on the box? do you some strange patches applied or external modules loaded? What's your .config? > Feb 22 15:00:54 mserv1 kernel: [] do_page_fault+0x0/0x523 > Feb 22 15:00:54 mserv1 kernel: [] error_code+0x2d/0x38 > Feb 22 15:00:54 mserv1 kernel: [] __wake_up+0x45/0x70 > Feb 22 15:00:54 mserv1 kernel: [] __wake_up_common+0x3a/0x60 > Feb 22 15:00:55 mserv1 kernel: [] __wake_up+0x3f/0x70 > Feb 22 15:00:55 mserv1 kernel: [] mrunlock+0x82/0xb0 > Feb 22 15:00:55 mserv1 kernel: [] mraccessf+0xc0/0xe0 > Feb 22 15:00:55 mserv1 kernel: [] xfs_iunlock+0x3e/0x80 > Feb 22 15:00:55 mserv1 kernel: [] xfs_iomap+0x3bb/0x540 > Feb 22 15:00:55 mserv1 kernel: [] bio_alloc+0xd7/0x1c0 > Feb 22 15:00:55 mserv1 kernel: [] map_blocks+0x7a/0x170 > Feb 22 15:00:55 mserv1 kernel: [] page_state_convert+0x52b/0x6d0 > Feb 22 15:00:55 mserv1 kernel: [] xfs_imap_to_bmap+0x39/0x240 > Feb 22 15:00:55 mserv1 kernel: [] linvfs_release_page+0xa8/0xb0 > Feb 22 15:00:55 mserv1 kernel: [] linvfs_writepage+0x60/0x120 > Feb 22 15:00:55 mserv1 kernel: [] shrink_list+0x41c/0x710 > Feb 22 15:00:55 mserv1 kernel: [] shrink_cache+0x1f8/0x3d0 > Feb 22 15:00:55 mserv1 kernel: [] journal_stop+0x220/0x330 > Feb 22 15:00:55 mserv1 kernel: [] shrink_zone+0xbc/0xc0 > Feb 22 15:00:55 mserv1 kernel: [] shrink_caches+0xc5/0xe0 > Feb 22 15:00:55 mserv1 kernel: [] try_to_free_pages+0xbc/0x190 > Feb 22 15:00:55 mserv1 kernel: [] __alloc_pages+0x203/0x370 > Feb 22 15:00:55 mserv1 kernel: [] __get_free_pages+0x25/0x40 Hmm, from the trace it looks like ->release_page was called from a context where we can't sleep. XFS defintily doesn't handle that, so the question is whether the kernel should do it. From owner-linux-xfs@oss.sgi.com Mon Feb 23 04:27:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 04:27:52 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NCRXKO008450 for ; Mon, 23 Feb 2004 04:27:33 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1NCRRF6015960 for ; Mon, 23 Feb 2004 04:27:27 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1NCRQbK34051125; Mon, 23 Feb 2004 06:27:26 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AvFBE-00010Z-00; Mon, 23 Feb 2004 06:27:24 -0600 Subject: PARTIAL TAKE 905452 - Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Mon, 23 Feb 2004 06:27:24 -0600 X-archive-position: 2192 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Mon Feb 23 04:25:57 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:167296a include/linux/rwsem.h - 1.3 - implement downgrade_write only if the architecture-specific bits are around From owner-linux-xfs@oss.sgi.com Mon Feb 23 04:28:27 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 04:28:30 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NCSQKO008642 for ; Mon, 23 Feb 2004 04:28:26 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AvFCD-0002DS-JA for linux-xfs@oss.sgi.com; Mon, 23 Feb 2004 12:28:25 +0000 Date: Mon, 23 Feb 2004 12:28:25 +0000 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: Re: Problem between XFS and JFS Message-ID: <20040223122825.A8509@infradead.org> References: <4039E05C.6050602@interfilme.com> <20040223115308.GC1003@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20040223115308.GC1003@plato.local.lan>; from erbenson@alaska.net on Mon, Feb 23, 2004 at 02:53:08AM -0900 X-archive-position: 2193 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Mon, Feb 23, 2004 at 02:53:08AM -0900, Ethan Benson wrote: > sounds like mkfs.jfs is not zeroing enough of the device prior to > writing its fs. particularly block zero where the XFS superblock > lives. (some mkfs avoid zeroing this due to quirky partitioning setups > on some architectures, notably Suns). or x86 where people like to put their bootloader in there :) From owner-linux-xfs@oss.sgi.com Mon Feb 23 05:08:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 05:08:42 -0800 (PST) Received: from foo.ardendo.se (foo.ardendo.se [212.32.189.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1ND8KKO009860 for ; Mon, 23 Feb 2004 05:08:21 -0800 Received: from localhost (localhost [127.0.0.1]) by foo.ardendo.se (Postfix) with ESMTP id 7E44F239BB; Mon, 23 Feb 2004 14:08:13 +0100 (CET) Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) From: Mikael Wahlberg To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Per Lejontand , Jonas =?ISO-8859-1?Q?Engstr=F6m?= In-Reply-To: <20040223121959.A8354@infradead.org> References: <20040222164941.D6046@foo.ardendo.se> <20040223121959.A8354@infradead.org> Content-Type: multipart/mixed; boundary="=-OfIQHYqc5FdqwGvGl0bd" Organization: Ardendo Message-Id: <1077541689.1247.12.camel@harrier> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 23 Feb 2004 14:08:09 +0100 X-archive-position: 2194 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikael.wahlberg@ardendo.se Precedence: bulk X-list: linux-xfs --=-OfIQHYqc5FdqwGvGl0bd Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2004-02-23 at 13:19, Christoph Hellwig wrote: > On Sun, Feb 22, 2004 at 04:49:41PM +0100, Mikael Wahlberg wrote: > > Description: > > > > On heavy FTP Load (About 1Gbit/s) running both reads and writes on two ServeRAID6m Raid5 controllers merged together to one filesystem with Raidtools we see the error below. The filesystem gets totally hanged up. Currently with XFS, but JFS gets the same problem (Actually even more often). > > What does the JFS oops look like? Unfortunately I cannot find the JFS oops right now. We can try to reproduce it on one of the machines (We have 4 identical setups). It seems like the JFS oops never was written in the messages-file.. We are running the system on 2 CPUs (No HyperThreading) right now, and it has not crashed for about 18 hours.. so it is a bit more stable with less CPU:s it seems. We will try JFS without HT today. > > Feb 22 15:00:53 mserv1 kernel: [] __wake_up_common+0x3a/0x60 > > Feb 22 15:00:53 mserv1 kernel: [] __wake_up+0x3f/0x70 > > This doesn't make a lot of sense, there's only two mrlocks in XFS, and > they're in the inodes that have well-defined and understood lifetime rules. > > OTOH the previos oops might have messed quite a bit up in your system. Ok.. > did you run memtest86 on the box? do you some strange patches applied or > external modules loaded? What's your .config? No strange patches. Pure 2.6.3 dist kernel. We haven't run memtest86, but as I mentioned above, we have 4 equal machines with error correcting memory, so I find it unlikely to be a memory problem. The .config is attached. > > Feb 22 15:00:54 mserv1 kernel: [] do_page_fault+0x0/0x523 > > Feb 22 15:00:54 mserv1 kernel: [] error_code+0x2d/0x38 > > Feb 22 15:00:54 mserv1 kernel: [] __wake_up+0x45/0x70 > > Feb 22 15:00:54 mserv1 kernel: [] __wake_up_common+0x3a/0x60 > > Feb 22 15:00:55 mserv1 kernel: [] __wake_up+0x3f/0x70 > > Feb 22 15:00:55 mserv1 kernel: [] mrunlock+0x82/0xb0 > > Feb 22 15:00:55 mserv1 kernel: [] mraccessf+0xc0/0xe0 > > Feb 22 15:00:55 mserv1 kernel: [] xfs_iunlock+0x3e/0x80 > > Feb 22 15:00:55 mserv1 kernel: [] xfs_iomap+0x3bb/0x540 > > Feb 22 15:00:55 mserv1 kernel: [] bio_alloc+0xd7/0x1c0 > > Feb 22 15:00:55 mserv1 kernel: [] map_blocks+0x7a/0x170 > > Feb 22 15:00:55 mserv1 kernel: [] page_state_convert+0x52b/0x6d0 > > Feb 22 15:00:55 mserv1 kernel: [] xfs_imap_to_bmap+0x39/0x240 > > Feb 22 15:00:55 mserv1 kernel: [] linvfs_release_page+0xa8/0xb0 > > Feb 22 15:00:55 mserv1 kernel: [] linvfs_writepage+0x60/0x120 > > Feb 22 15:00:55 mserv1 kernel: [] shrink_list+0x41c/0x710 > > Feb 22 15:00:55 mserv1 kernel: [] shrink_cache+0x1f8/0x3d0 > > Feb 22 15:00:55 mserv1 kernel: [] journal_stop+0x220/0x330 > > Feb 22 15:00:55 mserv1 kernel: [] shrink_zone+0xbc/0xc0 > > Feb 22 15:00:55 mserv1 kernel: [] shrink_caches+0xc5/0xe0 > > Feb 22 15:00:55 mserv1 kernel: [] try_to_free_pages+0xbc/0x190 > > Feb 22 15:00:55 mserv1 kernel: [] __alloc_pages+0x203/0x370 > > Feb 22 15:00:55 mserv1 kernel: [] __get_free_pages+0x25/0x40 > > Hmm, from the trace it looks like ->release_page was called from a context > where we can't sleep. XFS defintily doesn't handle that, so the question > is whether the kernel should do it. Ok.. If you need any more information please tell us, it is quite urgent for us, since we really don't want to go back to 2.4, the performance increase with 2.6 is really impressive (Except when it crashes :) /Mikael -- ----------------------------------------------------------------------- Mikael Wahlberg, M.Sc. Ardendo Unit Manager Professional Services/ e-mail: mikael@ardendo.se Technical Project Manager GSM: +46 733 279 274 --=-OfIQHYqc5FdqwGvGl0bd Content-Disposition: attachment; filename=kernel-config-mserv2 Content-Type: text/plain; name=kernel-config-mserv2; charset=iso-8859-1 Content-Transfer-Encoding: 7bit # # Automatically generated make config: don't edit # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_STANDALONE=y # # General setup # CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_LOG_BUF_SHIFT=15 # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # 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=y # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 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_MVIAC3_2 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_HPET_TIMER is not set # CONFIG_HPET_EMULATE_RTC is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 CONFIG_PREEMPT=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set # CONFIG_X86_MCE_P4THERMAL is not set CONFIG_TOSHIBA=m CONFIG_I8K=m CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_HIGHMEM=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y CONFIG_HAVE_DEC_LOCK=y # # Power management options (ACPI, APM) # # CONFIG_PM is not set # # ACPI (Advanced Configuration and Power Interface) Support # # CONFIG_ACPI is not set CONFIG_ACPI_BOOT=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI, PCMCIA, EISA, MCA, ISA) # 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_USE_VECTOR is not set # CONFIG_PCI_LEGACY_PROC is not set CONFIG_PCI_NAMES=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_HOTPLUG is not set # # Executable file formats # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m # # Device Drivers # # # Generic Driver Options # # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=m CONFIG_PARPORT_PC=m # CONFIG_PARPORT_PC_FIFO is not set # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # # Block devices # CONFIG_BLK_DEV_FD=y CONFIG_PARIDE=m CONFIG_PARIDE_PARPORT=m # # Parallel IDE high-level drivers # CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m CONFIG_PARIDE_PT=m CONFIG_PARIDE_PG=m # # Parallel IDE protocol modules # CONFIG_PARIDE_ATEN=m CONFIG_PARIDE_BPCK=m CONFIG_PARIDE_BPCK6=m CONFIG_PARIDE_COMM=m CONFIG_PARIDE_DSTR=m CONFIG_PARIDE_FIT2=m CONFIG_PARIDE_FIT3=m CONFIG_PARIDE_EPAT=m CONFIG_PARIDE_EPATC8=y CONFIG_PARIDE_EPIA=m CONFIG_PARIDE_FRIQ=m CONFIG_PARIDE_FRPW=m CONFIG_PARIDE_KBIC=m CONFIG_PARIDE_KTTI=m CONFIG_PARIDE_ON20=m CONFIG_PARIDE_ON26=m CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y # CONFIG_LBD is not set # # ATA/ATAPI/MFM/RLL support # CONFIG_IDE=y 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_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y # CONFIG_IDEDISK_STROKE is not set CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDESCSI=m # CONFIG_IDE_TASK_IOCTL is not set # CONFIG_IDE_TASKFILE_IO is not set # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=y CONFIG_BLK_DEV_CMD640=y # CONFIG_BLK_DEV_CMD640_ENHANCED is not set CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_BLK_DEV_GENERIC=y # CONFIG_BLK_DEV_OPTI621 is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK 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_TRIFLEX is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5520 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_SC1200 is not set CONFIG_BLK_DEV_PIIX=y # CONFIG_BLK_DEV_NS87415 is not set CONFIG_BLK_DEV_PDC202XX_OLD=y # CONFIG_PDC202XX_BURST is not set CONFIG_BLK_DEV_PDC202XX_NEW=y CONFIG_PDC202XX_FORCE=y CONFIG_BLK_DEV_SVWKS=y # CONFIG_BLK_DEV_SIIMAGE 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_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_IVB is not set CONFIG_IDEDMA_AUTO=y # CONFIG_DMA_NONPCI is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # CONFIG_SCSI=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m CONFIG_BLK_DEV_SR_VENDOR=y CONFIG_CHR_DEV_SG=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set CONFIG_SCSI_REPORT_LUNS=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # # SCSI low-level drivers # # CONFIG_BLK_DEV_3W_XXXX_RAID is not set # CONFIG_SCSI_ACARD is not set # CONFIG_SCSI_AACRAID is not set # CONFIG_SCSI_AIC7XXX is not set # CONFIG_SCSI_AIC7XXX_OLD is not set # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_ADVANSYS is not set # CONFIG_SCSI_MEGARAID is not set # CONFIG_SCSI_SATA is not set # CONFIG_SCSI_BUSLOGIC is not set # CONFIG_SCSI_CPQFCTS is not set # CONFIG_SCSI_DMX3191D is not set # CONFIG_SCSI_EATA 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_IPS=y # CONFIG_SCSI_INIA100 is not set # CONFIG_SCSI_PPA is not set # CONFIG_SCSI_IMM is not set CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 # CONFIG_SCSI_SYM53C8XX_IOMAPPED 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_QLA2XXX=y # CONFIG_SCSI_QLA21XX is not set # CONFIG_SCSI_QLA22XX is not set # CONFIG_SCSI_QLA2300 is not set # CONFIG_SCSI_QLA2322 is not set # CONFIG_SCSI_QLA6312 is not set # CONFIG_SCSI_QLA6322 is not set # CONFIG_SCSI_DC395x is not set # CONFIG_SCSI_DC390T is not set # CONFIG_SCSI_NSP32 is not set # CONFIG_SCSI_DEBUG is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_LINEAR=y CONFIG_MD_RAID0=y CONFIG_MD_RAID1=y CONFIG_MD_RAID5=y # CONFIG_MD_RAID6 is not set CONFIG_MD_MULTIPATH=y CONFIG_BLK_DEV_DM=y CONFIG_DM_IOCTL_V4=y # # Fusion MPT device support # CONFIG_FUSION=y CONFIG_FUSION_BOOT=y CONFIG_FUSION_MAX_SGE=40 # 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 # # Macintosh device drivers # # # Networking support # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_NETLINK_DEV=y CONFIG_UNIX=y # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set # CONFIG_INET_ECN is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # # IP: Virtual Server Configuration # CONFIG_IP_VS=m # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=16 # # IPVS transport protocol load balancing support # # CONFIG_IP_VS_PROTO_TCP is not set # CONFIG_IP_VS_PROTO_UDP is not set # CONFIG_IP_VS_PROTO_ESP is not set # CONFIG_IP_VS_PROTO_AH is not set # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m # CONFIG_IP_VS_SED is not set # CONFIG_IP_VS_NQ is not set # # IPVS application helper # CONFIG_IPV6=m # CONFIG_IPV6_PRIVACY is not set # CONFIG_INET6_AH is not set # CONFIG_INET6_ESP is not set # CONFIG_INET6_IPCOMP is not set # CONFIG_IPV6_TUNNEL is not set CONFIG_DECNET=m CONFIG_DECNET_SIOCGIFCONF=y CONFIG_DECNET_ROUTER=y CONFIG_DECNET_ROUTE_FWMARK=y CONFIG_BRIDGE=m CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_BRIDGE_NETFILTER=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=m CONFIG_IP_NF_FTP=m CONFIG_IP_NF_IRC=m # CONFIG_IP_NF_TFTP is not set # CONFIG_IP_NF_AMANDA is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_LIMIT=m # CONFIG_IP_NF_MATCH_IPRANGE is not set CONFIG_IP_NF_MATCH_MAC=m CONFIG_IP_NF_MATCH_PKTTYPE=m CONFIG_IP_NF_MATCH_MARK=m CONFIG_IP_NF_MATCH_MULTIPORT=m CONFIG_IP_NF_MATCH_TOS=m # CONFIG_IP_NF_MATCH_RECENT is not set CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_DSCP=m CONFIG_IP_NF_MATCH_AH_ESP=m CONFIG_IP_NF_MATCH_LENGTH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_TCPMSS=m CONFIG_IP_NF_MATCH_HELPER=m CONFIG_IP_NF_MATCH_STATE=m CONFIG_IP_NF_MATCH_CONNTRACK=m CONFIG_IP_NF_MATCH_OWNER=m # CONFIG_IP_NF_MATCH_PHYSDEV is not set CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_NAT=m CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m # CONFIG_IP_NF_TARGET_NETMAP is not set # CONFIG_IP_NF_TARGET_SAME is not set # CONFIG_IP_NF_NAT_LOCAL is not set CONFIG_IP_NF_NAT_SNMP_BASIC=m CONFIG_IP_NF_NAT_IRC=m CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m # CONFIG_IP_NF_TARGET_CLASSIFY is not set CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m # CONFIG_IP_NF_ARP_MANGLE is not set CONFIG_IP_NF_COMPAT_IPCHAINS=m CONFIG_IP_NF_COMPAT_IPFWADM=m # # IPv6: Netfilter Configuration # # CONFIG_IP6_NF_QUEUE is not set CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_LIMIT=m CONFIG_IP6_NF_MATCH_MAC=m # CONFIG_IP6_NF_MATCH_RT is not set # CONFIG_IP6_NF_MATCH_OPTS is not set # CONFIG_IP6_NF_MATCH_FRAG is not set # CONFIG_IP6_NF_MATCH_HL is not set CONFIG_IP6_NF_MATCH_MULTIPORT=m CONFIG_IP6_NF_MATCH_OWNER=m CONFIG_IP6_NF_MATCH_MARK=m # CONFIG_IP6_NF_MATCH_IPV6HEADER is not set # CONFIG_IP6_NF_MATCH_AHESP is not set CONFIG_IP6_NF_MATCH_LENGTH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_MARK=m # # DECnet: Netfilter Configuration # # CONFIG_DECNET_NF_GRABULATOR is not set # # Bridge: Netfilter Configuration # # CONFIG_BRIDGE_NF_EBTABLES is not set CONFIG_XFRM=y # CONFIG_XFRM_USER is not set # # SCTP Configuration (EXPERIMENTAL) # CONFIG_IPV6_SCTP__=m # CONFIG_IP_SCTP is not set CONFIG_ATM=y CONFIG_ATM_CLIP=y # CONFIG_ATM_CLIP_NO_ICMP is not set CONFIG_ATM_LANE=m CONFIG_ATM_MPOA=m CONFIG_ATM_BR2684=m CONFIG_ATM_BR2684_IPFILTER=y CONFIG_VLAN_8021Q=m CONFIG_LLC=y # CONFIG_LLC2 is not set CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=y CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set # CONFIG_LAPB is not set CONFIG_NET_DIVERT=y # CONFIG_ECONET is not set CONFIG_WAN_ROUTER=m # CONFIG_NET_FASTROUTE is not set # CONFIG_NET_HW_FLOWCONTROL is not set # # QoS and/or fair queueing # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m # CONFIG_NET_SCH_HFSC is not set CONFIG_NET_SCH_CSZ=m # CONFIG_NET_SCH_ATM is not set CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # # Network testing # # CONFIG_NET_PKTGEN is not set CONFIG_NETDEVICES=y # # ARCnet devices # # CONFIG_ARCNET is not set CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_TUN=m CONFIG_ETHERTAP=m # # Ethernet (10 or 100Mbit) # CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_NET_VENDOR_3COM=y CONFIG_VORTEX=m # CONFIG_TYPHOON is not set # # Tulip family network device support # # CONFIG_NET_TULIP is not set CONFIG_HP100=m CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_ADAPTEC_STARFIRE=m # CONFIG_ADAPTEC_STARFIRE_NAPI is not set # CONFIG_B44 is not set # CONFIG_FORCEDETH is not set CONFIG_DGRS=m CONFIG_EEPRO100=m # CONFIG_EEPRO100_PIO is not set CONFIG_E100=m CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set CONFIG_8139_RXBUF_IDX=2 CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m CONFIG_SUNDANCE_MMIO=y CONFIG_TLAN=m CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set # # Ethernet (1000 Mbit) # CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=y # CONFIG_E1000_NAPI is not set CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m # CONFIG_SIS190 is not set CONFIG_SK98LIN=m CONFIG_TIGON3=m # # Ethernet (10000 Mbit) # # CONFIG_IXGB is not set # CONFIG_FDDI is not set # CONFIG_HIPPI is not set CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m # CONFIG_PPP_BSDCOMP is not set # CONFIG_PPPOE is not set CONFIG_PPPOATM=m CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y # # Wireless LAN (non-hamradio) # CONFIG_NET_RADIO=y # # Obsolete Wireless cards support (pre-802.11) # CONFIG_STRIP=m # # Wireless 802.11b ISA/PCI cards support # CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m # CONFIG_TMD_HERMES is not set CONFIG_PCI_HERMES=m # CONFIG_ATMEL is not set CONFIG_NET_WIRELESS=y # # Token Ring devices # CONFIG_TR=y CONFIG_IBMOL=m CONFIG_IBMLS=m CONFIG_3C359=m CONFIG_TMS380TR=m CONFIG_TMSPCI=m CONFIG_ABYSS=m CONFIG_NET_FC=y CONFIG_RCPCI=m CONFIG_SHAPER=m # # Wan interfaces # CONFIG_WAN=y # CONFIG_DSCC4 is not set # CONFIG_LANMEDIA is not set # CONFIG_SYNCLINK_SYNCPPP is not set # CONFIG_HDLC is not set CONFIG_DLCI=m CONFIG_DLCI_COUNT=24 CONFIG_DLCI_MAX=8 CONFIG_WAN_ROUTER_DRIVERS=y CONFIG_CYCLADES_SYNC=m CONFIG_CYCLOMX_X25=y CONFIG_SBNI=m CONFIG_SBNI_MULTILINE=y # # ATM drivers # CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m CONFIG_ATM_ZATM=m # CONFIG_ATM_ZATM_DEBUG is not set CONFIG_ATM_NICSTAR=m CONFIG_ATM_NICSTAR_USE_SUNI=y CONFIG_ATM_NICSTAR_USE_IDT77105=y CONFIG_ATM_IDT77252=m # CONFIG_ATM_IDT77252_DEBUG is not set # CONFIG_ATM_IDT77252_RCV_ALL is not set CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=m # CONFIG_ATM_AMBASSADOR_DEBUG is not set CONFIG_ATM_HORIZON=m # CONFIG_ATM_HORIZON_DEBUG is not set CONFIG_ATM_IA=m # CONFIG_ATM_IA_DEBUG is not set CONFIG_ATM_FORE200E_MAYBE=m CONFIG_ATM_FORE200E_PCA=y CONFIG_ATM_FORE200E_PCA_DEFAULT_FW=y CONFIG_ATM_FORE200E_TX_RETRY=16 CONFIG_ATM_FORE200E_DEBUG=0 CONFIG_ATM_FORE200E=m # CONFIG_ATM_HE is not set # # Amateur Radio support # # CONFIG_HAMRADIO is not set # # IrDA (infrared) support # # CONFIG_IRDA is not set # # Bluetooth support # # CONFIG_BT is not set # # ISDN subsystem # # CONFIG_ISDN_BOOL is not set # # Telephony Support # # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set CONFIG_INPUT_EVDEV=m # CONFIG_INPUT_EVBUG is not set # # Input I/O drivers # # CONFIG_GAMEPORT is not set CONFIG_SOUND_GAMEPORT=y CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PARKBD is not set CONFIG_SERIO_PCIPS2=y # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y # CONFIG_MOUSE_SERIAL is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TOUCHSCREEN is not set # CONFIG_INPUT_MISC is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_ROCKETPORT=m CONFIG_SYNCLINK=m # CONFIG_SYNCLINKMP is not set CONFIG_N_HDLC=m CONFIG_STALDRV=y # # Serial drivers # # CONFIG_SERIAL_8250 is not set # # Non-8250 serial port support # CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=2048 CONFIG_PRINTER=m CONFIG_LP_CONSOLE=y CONFIG_PPDEV=m CONFIG_TIPAR=m # # Mice # CONFIG_BUSMOUSE=m # CONFIG_QIC02_TAPE is not set # # IPMI # CONFIG_IPMI_HANDLER=m # CONFIG_IPMI_PANIC_EVENT is not set CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_KCS=m CONFIG_IPMI_WATCHDOG=m # # Watchdog Cards # CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m CONFIG_ACQUIRE_WDT=m CONFIG_ADVANTECH_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_AMD7XX_TCO=m CONFIG_SC520_WDT=m CONFIG_EUROTECH_WDT=m CONFIG_IB700_WDT=m CONFIG_WAFER_WDT=m # CONFIG_I8XX_TCO is not set CONFIG_SC1200_WDT=m # CONFIG_SCx200_WDT is not set # CONFIG_60XX_WDT is not set # CONFIG_CPU5_WDT is not set # CONFIG_W83627HF_WDT is not set CONFIG_W83877F_WDT=m CONFIG_MACHZ_WDT=m # # PCI-based Watchdog Cards # # CONFIG_PCIPCWATCHDOG is not set CONFIG_WDTPCI=m # CONFIG_WDT_501_PCI is not set # CONFIG_HW_RANDOM is not set CONFIG_NVRAM=m 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_AGP=m # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set CONFIG_AGP_SWORKS=m # CONFIG_AGP_VIA is not set # CONFIG_DRM is not set # CONFIG_MWAVE is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HANGCHECK_TIMER is not set # # I2C support # # CONFIG_I2C is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # # Digital Video Broadcasting Devices # # CONFIG_DVB is not set # # Graphics support # # CONFIG_FB is not set CONFIG_VIDEO_SELECT=y # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_MDA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set # # USB support # CONFIG_USB=m # CONFIG_USB_DEBUG is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_BANDWIDTH is not set # CONFIG_USB_DYNAMIC_MINORS is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=m # CONFIG_USB_OHCI_HCD is not set # CONFIG_USB_UHCI_HCD is not set # # USB Device Class drivers # # CONFIG_USB_BLUETOOTH_TTY is not set CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_HP8200e=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y # # USB Human Interface Devices (HID) # CONFIG_USB_HID=m CONFIG_USB_HIDINPUT=y # CONFIG_HID_FF is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set CONFIG_USB_AIPTEK=m CONFIG_USB_WACOM=m # CONFIG_USB_KBTAB is not set CONFIG_USB_POWERMATE=m # CONFIG_USB_XPAD is not set # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m CONFIG_USB_HPUSBSCSI=m # # USB Multimedia devices # CONFIG_USB_DABUSB=m # # Video4Linux support is needed for USB Multimedia device support # # # USB Network adaptors # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m # # USB Host-to-Host Cables # CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_GENESYS=y CONFIG_USB_NET1080=y CONFIG_USB_PL2301=y # # Intelligent USB Devices/Gadgets # CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_ZAURUS=y CONFIG_USB_CDCETHER=y # # USB Network Adapters # CONFIG_USB_AX8817X=y # # USB port drivers # CONFIG_USB_USS720=m # # USB Serial Converter support # CONFIG_USB_SERIAL=m CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m # CONFIG_USB_SERIAL_KEYSPAN_MPR is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28X is not set CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y # CONFIG_USB_SERIAL_KEYSPAN_USA19 is not set # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set # CONFIG_USB_SERIAL_KEYSPAN_USA19W is not set CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y # CONFIG_USB_SERIAL_KEYSPAN_USA49W is not set # CONFIG_USB_SERIAL_KEYSPAN_USA49WLC is not set CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_PL2303=m # CONFIG_USB_SERIAL_SAFE is not set CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set CONFIG_USB_TIGL=m CONFIG_USB_AUERSWALD=m CONFIG_USB_RIO500=m # CONFIG_USB_LEGOTOWER is not set CONFIG_USB_BRLVGER=m CONFIG_USB_LCD=m # CONFIG_USB_LED is not set # CONFIG_USB_SPEEDTOUCH is not set # CONFIG_USB_TEST is not set # # USB Gadget Support # # CONFIG_USB_GADGET is not set # # File systems # CONFIG_EXT2_FS=y # CONFIG_EXT2_FS_XATTR is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y # CONFIG_EXT3_FS_SECURITY is not set CONFIG_JBD=y # CONFIG_JBD_DEBUG is not set CONFIG_FS_MBCACHE=y CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set CONFIG_REISERFS_PROC_INFO=y CONFIG_JFS_FS=y # CONFIG_JFS_POSIX_ACL is not set CONFIG_JFS_DEBUG=y CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_RT is not set # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set CONFIG_MINIX_FS=m CONFIG_ROMFS_FS=m CONFIG_QUOTA=y # CONFIG_QFMT_V1 is not set CONFIG_QFMT_V2=y CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_ZISOFS_FS=y CONFIG_UDF_FS=m # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y # CONFIG_DEVFS_FS is not set CONFIG_DEVPTS_FS=y # CONFIG_DEVPTS_FS_XATTR is not set CONFIG_TMPFS=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_RAMFS=y # # Miscellaneous filesystems # # CONFIG_ADFS_FS is not set # CONFIG_AFFS_FS is not set CONFIG_HFS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m # CONFIG_EFS_FS is not set CONFIG_CRAMFS=m CONFIG_VXFS_FS=m # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set CONFIG_SYSV_FS=m CONFIG_UFS_FS=m # CONFIG_UFS_FS_WRITE is not set # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V3=y # CONFIG_NFSD_V4 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_SUNRPC=m # CONFIG_SUNRPC_GSS is not set CONFIG_SMB_FS=m # CONFIG_SMB_NLS_DEFAULT is not set # CONFIG_CIFS is not set CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m # CONFIG_CODA_FS_OLD_API is not set CONFIG_INTERMEZZO_FS=m CONFIG_AFS_FS=m CONFIG_RXRPC=m # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y # CONFIG_AMIGA_PARTITION is not set # CONFIG_ATARI_PARTITION is not set CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set # CONFIG_NEC98_PARTITION is not set CONFIG_SGI_PARTITION=y # CONFIG_ULTRIX_PARTITION is not set CONFIG_SUN_PARTITION=y # CONFIG_EFI_PARTITION is not set # # Native Language Support # CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m # # Kernel hacking # CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_SLAB is not set # CONFIG_DEBUG_IOVIRT is not set CONFIG_MAGIC_SYSRQ=y # CONFIG_DEBUG_SPINLOCK is not set # CONFIG_DEBUG_PAGEALLOC is not set # CONFIG_DEBUG_HIGHMEM is not set # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set # CONFIG_FRAME_POINTER is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y # # Security options # # CONFIG_SECURITY is not set # # Cryptographic options # # CONFIG_CRYPTO is not set # # Library routines # CONFIG_CRC32=m CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_X86_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_PC=y --=-OfIQHYqc5FdqwGvGl0bd-- From owner-linux-xfs@oss.sgi.com Mon Feb 23 05:13:34 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 05:13:49 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NDDXKO010559 for ; Mon, 23 Feb 2004 05:13:33 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AvFtr-0002IF-Vz; Mon, 23 Feb 2004 13:13:31 +0000 Date: Mon, 23 Feb 2004 13:13:31 +0000 From: Christoph Hellwig To: Mikael Wahlberg Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Per Lejontand , =?iso-8859-1?Q?Jonas_Engstr=F6m?= Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) Message-ID: <20040223131331.A8778@infradead.org> Mail-Followup-To: Christoph Hellwig , Mikael Wahlberg , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Per Lejontand , =?iso-8859-1?Q?Jonas_Engstr=F6m?= References: <20040222164941.D6046@foo.ardendo.se> <20040223121959.A8354@infradead.org> <1077541689.1247.12.camel@harrier> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1077541689.1247.12.camel@harrier>; from mikael.wahlberg@ardendo.se on Mon, Feb 23, 2004 at 02:08:09PM +0100 X-archive-position: 2195 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Mon, Feb 23, 2004 at 02:08:09PM +0100, Mikael Wahlberg wrote: > If you need any more information please tell us, it is quite urgent for > us, since we really don't want to go back to 2.4, the performance > increase with 2.6 is really impressive (Except when it crashes :) Can you check whether the small patch below gets rid of you problems? It still wouldn't explain the JFS problems, though. --- 1.59/fs/xfs/linux/xfs_aops.c Mon Feb 9 05:39:27 2004 +++ edited/fs/xfs/linux/xfs_aops.c Mon Feb 23 15:11:33 2004 @@ -1170,7 +1170,7 @@ if (!delalloc && !unwritten) goto free_buffers; - if (!(gfp_mask & __GFP_FS)) + if ((gfp_mask & (__GFP_FS|__GFP_WAIT)) != (__GFP_FS|__GFP_WAIT)) return 0; /* If we are already inside a transaction or the thread cannot From owner-linux-xfs@oss.sgi.com Mon Feb 23 05:46:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 05:46:44 -0800 (PST) Received: from smtp-out5.xs4all.nl (smtp-out5.xs4all.nl [194.109.24.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NDkgKO012174 for ; Mon, 23 Feb 2004 05:46:42 -0800 Received: from auto-nb1.xs4all.nl (host-2.coltex.demon.nl [212.238.252.66]) (authenticated bits=0) by smtp-out5.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1NDkan2082881; Mon, 23 Feb 2004 14:46:36 +0100 (CET) Message-Id: <4.3.2.7.2.20040223144245.01c2e688@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 23 Feb 2004 14:46:34 +0100 To: Mikael Wahlberg , Christoph Hellwig From: Seth Mos Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Per Lejontand , Jonas =?iso-8859-1?Q?Engstr=F6m?= In-Reply-To: <1077541689.1247.12.camel@harrier> References: <20040223121959.A8354@infradead.org> <20040222164941.D6046@foo.ardendo.se> <20040223121959.A8354@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-archive-position: 2197 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: knuffie@xs4all.nl Precedence: bulk X-list: linux-xfs At 14:08 23-2-2004 +0100, Mikael Wahlberg wrote: >On Mon, 2004-02-23 at 13:19, Christoph Hellwig wrote: > > On Sun, Feb 22, 2004 at 04:49:41PM +0100, Mikael Wahlberg wrote: > > did you run memtest86 on the box? do you some strange patches applied or > > external modules loaded? What's your .config? > >No strange patches. Pure 2.6.3 dist kernel. We haven't run memtest86, >but as I mentioned above, we have 4 equal machines with error correcting >memory, so I find it unlikely to be a memory problem. The memory might be fine, but the mainboard might still be borked. I have seen this once with Dell kit. Asuming can be dangerous. If you can spare the down time it is always a good idea to make sure. In my experience XFS shows faulty memory quite fast. That's from personal experience. Cheers -- Seth I don't make sense, I don't pretend to either. Questions? From owner-linux-xfs@oss.sgi.com Mon Feb 23 05:46:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 05:46:31 -0800 (PST) Received: from foo.ardendo.se (foo.ardendo.se [212.32.189.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NDkDKO012090 for ; Mon, 23 Feb 2004 05:46:14 -0800 Received: from localhost (localhost [127.0.0.1]) by foo.ardendo.se (Postfix) with ESMTP id 02D0A239BC; Mon, 23 Feb 2004 14:46:06 +0100 (CET) Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) From: Mikael Wahlberg To: Christoph Hellwig Cc: linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Jonas =?ISO-8859-1?Q?Engstr=F6m?= , Per Lejontand In-Reply-To: <20040223121959.A8354@infradead.org> References: <20040222164941.D6046@foo.ardendo.se> <20040223121959.A8354@infradead.org> Content-Type: text/plain Organization: Ardendo Message-Id: <1077543963.1246.20.camel@harrier> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 23 Feb 2004 14:46:03 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2196 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikael.wahlberg@ardendo.se Precedence: bulk X-list: linux-xfs On Mon, 2004-02-23 at 13:19, Christoph Hellwig wrote: > On Sun, Feb 22, 2004 at 04:49:41PM +0100, Mikael Wahlberg wrote: > > Description: > > > > On heavy FTP Load (About 1Gbit/s) running both reads and writes on two ServeRAID6m Raid5 controllers merged together to one filesystem with Raidtools we see the error below. The filesystem gets totally hanged up. Currently with XFS, but JFS gets the same problem (Actually even more often). > > What does the JFS oops look like? Just tried it without HyperThreading, with JFS, the filesystem hanged without any kernel oops after about 10 minutes of 1Gbit/s FTP input. What I got was: Feb 23 14:19:15 mserv4 kernel: Feb 23 14:19:15 mserv4 kernel: swapper: page allocation failure. order:0, mode:0x20 Feb 23 14:19:15 mserv4 kernel: Call Trace: Feb 23 14:19:15 mserv4 kernel: [] __alloc_pages+0x320/0x370 Feb 23 14:19:15 mserv4 kernel: [] __get_free_pages+0x25/0x40 Feb 23 14:19:15 mserv4 kernel: [] cache_grow+0xcc/0x330 Feb 23 14:19:15 mserv4 kernel: [] cache_alloc_refill+0xfe/0x2a0 Feb 23 14:19:15 mserv4 kernel: [] __kmalloc+0x7e/0x90 Feb 23 14:19:15 mserv4 kernel: [] alloc_skb+0x47/0xf0 Feb 23 14:19:15 mserv4 kernel: [] e1000_alloc_rx_buffers+0x59/0x100 Feb 23 14:19:15 mserv4 kernel: [] e1000_clean_rx_irq+0xfe/0x4b0 Feb 23 14:19:15 mserv4 kernel: [] e1000_clean_tx_irq+0x1d6/0x280 Feb 23 14:19:15 mserv4 kernel: [] e1000_intr+0x4a/0xc0 Feb 23 14:19:16 mserv4 kernel: [] handle_IRQ_event+0x49/0x80 Feb 23 14:19:16 mserv4 kernel: [] do_IRQ+0xd2/0x1d0 Feb 23 14:19:16 mserv4 kernel: [] common_interrupt+0x18/0x20 Feb 23 14:19:16 mserv4 kernel: [] kmem_cache_alloc+0x31/0x50 Feb 23 14:19:16 mserv4 kernel: [] alloc_skb+0x25/0xf0 Feb 23 14:19:16 mserv4 kernel: [] tcp_send_ack+0x31/0xd0 Feb 23 14:19:16 mserv4 kernel: [] netif_receive_skb+0x1cd/0x250 Feb 23 14:19:16 mserv4 kernel: [] tcp_delack_timer+0x10f/0x220 Feb 23 14:19:16 mserv4 kernel: [] e1000_clean_tx_irq+0x1d6/0x280 Feb 23 14:19:16 mserv4 kernel: [] tcp_delack_timer+0x0/0x220 Feb 23 14:19:16 mserv4 kernel: [] run_timer_softirq+0xf8/0x1e0 Feb 23 14:19:16 mserv4 kernel: [] add_interrupt_randomness+0x31/0x40 Feb 23 14:19:16 mserv4 kernel: [] do_softirq+0xca/0xd0 Feb 23 14:19:16 mserv4 kernel: [] do_IRQ+0x15d/0x1d0 Feb 23 14:19:16 mserv4 kernel: [] default_idle+0x0/0x40 Feb 23 14:19:16 mserv4 kernel: [] common_interrupt+0x18/0x20 Feb 23 14:19:16 mserv4 kernel: [] default_idle+0x0/0x40 Feb 23 14:19:17 mserv4 kernel: [] default_idle+0x2d/0x40 Feb 23 14:19:18 mserv4 kernel: [] cpu_idle+0x46/0x50 Feb 23 14:19:18 mserv4 kernel: [] rest_init+0x0/0x70 Feb 23 14:19:18 mserv4 kernel: [] start_kernel+0x1a0/0x1e0 Feb 23 14:19:18 mserv4 kernel: [] unknown_bootoption+0x0/0x120 Feb 23 14:19:18 mserv4 kernel: Feb 23 14:19:18 mserv4 kernel: swapper: page allocation failure. order:0, mode:0x20 Feb 23 14:19:18 mserv4 kernel: Call Trace: Feb 23 14:19:18 mserv4 kernel: [] __alloc_pages+0x320/0x370 Feb 23 14:19:18 mserv4 kernel: [] ip_local_deliver_finish+0x0/0x220 Feb 23 14:19:18 mserv4 kernel: [] __get_free_pages+0x25/0x40 Feb 23 14:19:18 mserv4 kernel: [] cache_grow+0xcc/0x330 Feb 23 14:19:18 mserv4 kernel: [] cache_alloc_refill+0xfe/0x2a0 Feb 23 14:19:18 mserv4 kernel: [] __kmalloc+0x7e/0x90 Feb 23 14:19:19 mserv4 kernel: [] alloc_skb+0x47/0xf0 Feb 23 14:19:19 mserv4 kernel: [] e1000_alloc_rx_buffers+0x59/0x100 Feb 23 14:19:19 mserv4 kernel: [] e1000_clean_rx_irq+0xfe/0x4b0 Feb 23 14:19:19 mserv4 kernel: [] netif_receive_skb+0x1cd/0x250 Feb 23 14:19:19 mserv4 kernel: [] e1000_intr+0x4a/0xc0 Feb 23 14:19:19 mserv4 kernel: [] handle_IRQ_event+0x49/0x80 Feb 23 14:19:19 mserv4 kernel: [] do_IRQ+0xd2/0x1d0 Feb 23 14:19:19 mserv4 kernel: [] default_idle+0x0/0x40 Feb 23 14:19:19 mserv4 kernel: [] common_interrupt+0x18/0x20 Feb 23 14:19:19 mserv4 kernel: [] default_idle+0x0/0x40 Feb 23 14:19:19 mserv4 kernel: [] default_idle+0x2d/0x40 Feb 23 14:19:19 mserv4 kernel: [] cpu_idle+0x46/0x50 Feb 23 14:19:19 mserv4 kernel: [] rest_init+0x0/0x70 Feb 23 14:19:19 mserv4 kernel: [] start_kernel+0x1a0/0x1e0 Feb 23 14:19:20 mserv4 kernel: [] unknown_bootoption+0x0/0x120 Feb 23 14:19:20 mserv4 kernel: ^[ Feb 23 14:31:57 mserv4 proftpd[22053]: mserv4 - ProFTPD killed (signal 15) (I restardet proftpd when nothing happened) Then if I try to read a file on the filesystem: (Strace of less) [root@mserv4 clips]# strace less f5.in.09 execve("/usr/bin/less", ["less", "f5.in.09"], [/* 26 vars */]) = 0 uname({sys="Linux", node="mserv4", ...}) = 0 brk(0) = 0x806b000 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40013000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=62008, ...}) = 0 old_mmap(NULL, 62008, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 close(3) = 0 open("/usr/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\341"..., 512) = 512fstat64(3, {st_mode=S_IFREG|0755, st_size=255300, ...}) = 0 old_mmap(NULL, 256076, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40024000 old_mmap(0x4005a000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x36000) = 0x4005a000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\310V\1"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1476244, ...}) = 0 old_mmap(NULL, 1207972, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40063000 old_mmap(0x40184000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x120000) = 0x40184000 old_mmap(0x40188000, 7844, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40188000 close(3) = 0 munmap(0x40014000, 62008) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 brk(0) = 0x806b000 brk(0x806c000) = 0x806c000 brk(0) = 0x806c000 access("/root/.terminfo/x/xterm", R_OK) = -1 ENOENT (No such file or directory) access("/usr/share/terminfo/x/xterm", R_OK) = 0 open("/usr/share/terminfo/x/xterm", O_RDONLY) = 3 read(3, "\32\1\34\0\35\0\17\0i\1\273\3", 12) = 12 read(3, "xterm|X11 terminal emulator\0", 28) = 28 read(3, "\0\1\0\0\1\0\0\0\1\0\0\0\0\1\1\0\0\0\0\0\0\0\1\0\0\0\0"..., 29) = 29 read(3, "\0", 1) = 1 read(3, "P\0\10\0\30\0\377\377\377\377\377\377\377\377\377\377\377"..., 30) = 30read(3, "\0\0\4\0\6\0\10\0\31\0\36\0&\0*\0.\0\377\3779\0J\0L\0P"..., 722) = 722 read(3, "\33[Z\0\7\0\r\0\33[%i%p1%d;%p2%dr\0\33[3g\0\33["..., 955) = 955 read(3, "", 1) = 0 read(3, "", 10) = 0 close(3) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=61, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0 ioctl(2, TIOCGWINSZ, {ws_row=61, ws_col=80, ws_xpixel=0, ws_ypixel=0}) = 0 open("/usr/bin/.sysless", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/etc/sysless", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) open("/root/.less", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) brk(0) = 0x806c000 brk(0x806d000) = 0x806d000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=31202800, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4018a000 close(3) = 0 brk(0) = 0x806d000 brk(0x806e000) = 0x806e000 open("/dev/tty", O_RDONLY|O_LARGEFILE) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE, {B38400 opost isig icanon echo ...}) = 0 fsync(3) = -1 EINVAL (Invalid argument) ioctl(3, SNDCTL_TMR_STOP, {B38400 opost isig -icanon -echo ...}) = 0 rt_sigaction(SIGINT, {0x8059e90, [INT], SA_RESTORER|SA_RESTART, 0x40089cf8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTSTP, {0x8059ed0, [TSTP], SA_RESTORER|SA_RESTART, 0x40089cf8}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGWINCH, {0x8059f10, [WINCH], SA_RESTORER|SA_RESTART, 0x40089cf8}, {SIG_DFL}, 8) = 0 pipe([4, 5]) = 0 vfork() = 22348 close(5) = 0 read(4, "", 1) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- close(4) = 0 wait4(22348, [WIFEXITED(s) && WEXITSTATUS(s) == 127], 0, NULL) = 22348 stat64("f5.in.09", {st_mode=S_IFREG|0644, st_size=67719168, ...}) = 0 stat64("f5.in.09", {st_mode=S_IFREG|0644, st_size=67719168, ...}) = 0 open("f5.in.09", O_RDONLY|O_LARGEFILE) = 4 _llseek(4, 1, then hang.. Anybody got an idea? /Mikael -- ----------------------------------------------------------------------- Mikael Wahlberg, M.Sc. Ardendo Unit Manager Professional Services/ e-mail: mikael@ardendo.se Technical Project Manager GSM: +46 733 279 274 From owner-linux-xfs@oss.sgi.com Mon Feb 23 05:49:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 05:49:17 -0800 (PST) Received: from web25205.mail.ukl.yahoo.com (web25205.mail.ukl.yahoo.com [217.12.10.65]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NDnFKO012856 for ; Mon, 23 Feb 2004 05:49:15 -0800 Message-ID: <20040223134909.83414.qmail@web25205.mail.ukl.yahoo.com> Received: from [195.173.4.13] by web25205.mail.ukl.yahoo.com via HTTP; Mon, 23 Feb 2004 13:49:09 GMT Date: Mon, 23 Feb 2004 13:49:09 +0000 (GMT) From: =?iso-8859-1?q?Alexander=20Fisher?= Subject: large allocation groups fix 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: 2198 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexjfisher@yahoo.co.uk Precedence: bulk X-list: linux-xfs Hi. I'm running a vendor modified kernel 2.4.20-pre2 into which I have patched the 1.3.1 xfs 2.4.21 patches. Doing this wasn't too tricky although I needed to integrate a few bitkeeper changesets to get this to work. I'm using xfs on large filesystems 1TB+ and have quickly noticed the problem with the large allocation group size that the latest version of mkfs.xfs will create by default. I would like to 'fix' my kernel so that allocation group sizes above 4GB don't result in lockups. Is there a patch I can use against the 1.3.1 xfs release? I've looked at the fix included in kernel changeset 1.1276.1.2 http://linux.bkbits.net:8080/linux-2.4/cset@1.1276.1.2?nav=index.html|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_iomap.h but it doesn't apply to the official xfs release. On a related point, are there any plans to announce any more official xfs releases or is it just assumed that people will use upto date linux kernels? Thanks, Alex P.S. Sincere apologies if this email arrives at the list twice. ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From owner-linux-xfs@oss.sgi.com Mon Feb 23 07:29:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 07:29:40 -0800 (PST) Received: from foo.ardendo.se (foo.ardendo.se [212.32.189.9]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NFTFKO015529 for ; Mon, 23 Feb 2004 07:29:16 -0800 Received: from localhost (localhost [127.0.0.1]) by foo.ardendo.se (Postfix) with ESMTP id EF8E2239BC; Mon, 23 Feb 2004 14:50:26 +0100 (CET) Subject: Re: Filesystem kernel hangup, 2.6.3 (bad: scheduling while atomic!) From: Mikael Wahlberg To: Seth Mos Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com, Per Lejontand , Jonas =?ISO-8859-1?Q?Engstr=F6m?= In-Reply-To: <4.3.2.7.2.20040223144245.01c2e688@pop.xs4all.nl> References: <20040223121959.A8354@infradead.org> <20040222164941.D6046@foo.ardendo.se> <20040223121959.A8354@infradead.org> <4.3.2.7.2.20040223144245.01c2e688@pop.xs4all.nl> Content-Type: text/plain Organization: Ardendo Message-Id: <1077544223.1247.23.camel@harrier> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 23 Feb 2004 14:50:23 +0100 Content-Transfer-Encoding: 7bit X-archive-position: 2199 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mikael.wahlberg@ardendo.se Precedence: bulk X-list: linux-xfs On Mon, 2004-02-23 at 14:46, Seth Mos wrote: > At 14:08 23-2-2004 +0100, Mikael Wahlberg wrote: > >On Mon, 2004-02-23 at 13:19, Christoph Hellwig wrote: > > > On Sun, Feb 22, 2004 at 04:49:41PM +0100, Mikael Wahlberg wrote: > > > did you run memtest86 on the box? do you some strange patches applied or > > > external modules loaded? What's your .config? > > > >No strange patches. Pure 2.6.3 dist kernel. We haven't run memtest86, > >but as I mentioned above, we have 4 equal machines with error correcting > >memory, so I find it unlikely to be a memory problem. > > The memory might be fine, but the mainboard might still be borked. I have > seen this once with Dell kit. Asuming can be dangerous. If you can spare > the down time it is always a good idea to make sure. Yes, but four new identical boxes... seems very unlikely. But sure, we can try it when I get to the computer room (It is not at our site, but at a customers) /Mikael -- ----------------------------------------------------------------------- Mikael Wahlberg, M.Sc. Ardendo Unit Manager Professional Services/ e-mail: mikael@ardendo.se Technical Project Manager GSM: +46 733 279 274 From owner-linux-xfs@oss.sgi.com Mon Feb 23 08:07:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 08:07:30 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NG7EKO016676 for ; Mon, 23 Feb 2004 08:07:15 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1NG79Nl008633 for ; Mon, 23 Feb 2004 10:07:09 -0600 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1NG79AY34550965 for ; Mon, 23 Feb 2004 10:07:09 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1NG79kP2219457 for ; Mon, 23 Feb 2004 10:07:09 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i1NG789i14093412 for ; Mon, 23 Feb 2004 10:07:08 -0600 (CST) Message-Id: <200402231607.i1NG789i14093412@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: Re: DMAPI test suite. Date: Mon, 23 Feb 2004 10:07:08 -0600 From: Dean Roehrich X-archive-position: 2200 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs >From: Ram Pai >Looking through the xfs dmapi code, 2 questions pop up: >1. How can the pre_unmount event, when generated through the put_super() >code provide the DM_UNMOUNT_FORCE information. There is now way for the >put_super() code to know if the unmount is a forceful one or not. Our implementation does not use this UNMOUNT_FORCE feature, even on Irix, so I can't fall back to an example. I don't see the Linux MNT_FORCE option going all that far down the stack. The operation s_op->umount_begin looks like a valid place to insert the PREUNMOUNT event, with UNMOUNT_FORCE implied. The comment in do_umount makes it sound like it's almost tailored to DMAPI's needs. Unfortunately, s_op->umount_begin is not general-purpose--it works only for MNT_FORCE and it uses lock_kernel(). >2. And finally I find that all the DMAPI event generators are stubbed >to fs_nosys or fs_noerr or fs_noval . So does XFS ever generate DM >events ? You'll need the XFS code from oss.sgi.com. >> Al Viro is distinctly anti dmapi, so chances are slim to none I would >> say. > >hmm...that makes it difficult. Is he against Dmapi implemented in VFS or >against the overall idea of supporting DMAPI anywhere in linux? I hope >he is just against DMAPI implemented at the VFS level and is ok with >supporting filesystems to implement it. The implementation is just an easy target. The spec is the root of the objections. This preunmount discussion highlights some of it. Which HSM are you working with now? Is this HPSS, or something else? Are you attempting to make DMAPI work with other filesystems? Dean From owner-linux-xfs@oss.sgi.com Mon Feb 23 08:17:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 08:17:28 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NGH7KO017226 for ; Mon, 23 Feb 2004 08:17:07 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1NFIo62024357 for ; Mon, 23 Feb 2004 07:18:50 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1NGH2AY34524861; Mon, 23 Feb 2004 10:17:02 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1NGH1Er134912; Mon, 23 Feb 2004 10:17:01 -0600 (CST) Date: Mon, 23 Feb 2004 10:17:01 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?iso-8859-1?q?Alexander=20Fisher?= cc: linux-xfs@oss.sgi.com Subject: Re: large allocation groups fix In-Reply-To: <20040223134909.83414.qmail@web25205.mail.ukl.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2201 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Mon, 23 Feb 2004, Alexander Fisher wrote: > create by default. I would like to 'fix' my kernel so > that allocation group sizes above 4GB don't result in > lockups. > > Is there a patch I can use against the 1.3.1 xfs > release? I've looked at the fix included in kernel > changeset 1.1276.1.2 > http://linux.bkbits.net:8080/linux-2.4/cset@1.1276.1.2?nav=index.html|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_iomap.h > but it doesn't apply to the official xfs release. That looks like the right patchset, I would not expect that it is -too- difficult to backport to 1.3.1, although I have not looked... Your other workaround is to use an older mkfs that does not make AGs > 4G (or explicitly specify 4G AGs with your mkfs). > On a related point, are there any plans to announce > any more official xfs releases or is it just assumed > that people will use upto date linux kernels? Probably the latter, although I'm not quite certain yet. -Eric From owner-linux-xfs@oss.sgi.com Mon Feb 23 09:07:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 09:08:07 -0800 (PST) Received: from odin.sv.fintec.co.cr ([168.243.202.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NH7pKO029485 for ; Mon, 23 Feb 2004 09:07:54 -0800 Received: from odin.fintec.co.cr ([192.168.201.229]) by odin.sv.fintec.co.cr (8.12.10/8.12.10) with ESMTP id i1NH7pp6010659 for ; Mon, 23 Feb 2004 11:07:51 -0600 Message-ID: <403A3366.3070809@odin.fintec.co.cr> Date: Mon, 23 Feb 2004 11:07:50 -0600 From: Ivan Kocher Organization: Fintec SA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Problem with XFS and JFS Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2202 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikocher@odin.fintec.co.cr Precedence: bulk X-list: linux-xfs Sorry, I did said, but I used dd to zero part of the device: dev is /dev/sda1 (20GB) # dd if=/dev/zero bs=1M count=1k > /dev/sda1 # echo y | mkfs.jfs /dev/sda1 I though that the first 1GB would be enogh... but no ... :( Tried first with 100M, then 1GB, and then 10GB, on the same device ... same luck ... The device is a 'partition' on a SAN array from compaq/hp. It is not used for booting. I am using kernel 2.4.23, slackware 9.1, dual P4, 4GB RAM Ivan -------- On Mon, Feb 23, 2004 at 05:13:32AM -0600, Ivan Kocher wrote: > Hi, > > Yesterday I was hit by a nasty bug ... > > I tried to change the filesystem of a couple machines from XFS to JFS, > so compiled kernel 2.4.23 with XFS (patch) and JFS. Once the jfs root > partition was up, it booted, and xfs "tried" to repair the partition. I > booted using my default setup and later after remaking all again using > init=/bin/bash rw, and even later init=/bin/bash ro > > In the first two cases cases, xfs tried its "repair", teling that it > recovered the journal... :( trashing the fs. > > When I booted in the third case, (ro) no problem... > > I wonder ... does xfs has some check for some magic in there? I tried > in all machines, and in all it damaged the mounted / jfs fs ... sounds like mkfs.jfs is not zeroing enough of the device prior to writing its fs. particularly block zero where the XFS superblock lives. (some mkfs avoid zeroing this due to quirky partitioning setups on some architectures, notably Suns). > > Any ideas? dd if=/dev/zero of=/dev/dev_being_mkfsed bs=512 count=100 prior to running mkfs. that should zero out enough to prevent any previous fs from being detected. > > Also, will there ever be a xfs patch for 2.4.24?? I know 2.4.25 has use the 2.4.23 patches, nothing changed in 2.4.24 that would affect xfs. > it... but for some reason I am having problems with a qlogic 2312 board > with 2.4.25 ... :( so I was thinking on testing 2.4.24 ... ??? apply the 2.4.23 split patches, all work and apply fine (except -misc, which you don't generally need anyway). -- Ethan Benson http://www.alaska.net/~erbenson/ From owner-linux-xfs@oss.sgi.com Mon Feb 23 09:40:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 09:40:27 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NHeMKO030315 for ; Mon, 23 Feb 2004 09:40:24 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1NHPnF6011241 for ; Mon, 23 Feb 2004 09:25:49 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1NHPmXB34531849; Mon, 23 Feb 2004 11:25:48 -0600 (CST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1NHPmfl3426487; Mon, 23 Feb 2004 11:25:48 -0600 (CST) Subject: Re: Problem with XFS and JFS From: Russell Cattelan To: Ivan Kocher Cc: linux-xfs@oss.sgi.com In-Reply-To: <403A3366.3070809@odin.fintec.co.cr> References: <403A3366.3070809@odin.fintec.co.cr> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-AddVhan7kivMlBrWlxY+" Message-Id: <1077557148.4497.1.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-3mdk Date: Mon, 23 Feb 2004 11:25:48 -0600 X-archive-position: 2203 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: cattelan@xfs.org Precedence: bulk X-list: linux-xfs --=-AddVhan7kivMlBrWlxY+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable > > Hi, > >=20 > > Yesterday I was hit by a nasty bug ... > >=20 > > I tried to change the filesystem of a couple machines from XFS to JFS,= =20 > > so compiled kernel 2.4.23 with XFS (patch) and JFS. Once the jfs root= =20 > > partition was up, it booted, and xfs "tried" to repair the partition. = I=20 > > booted using my default setup and later after remaking all again using= =20 > > init=3D/bin/bash rw, and even later init=3D/bin/bash ro > >=20 > > In the first two cases cases, xfs tried its "repair", teling that it=20 > > recovered the journal... :( trashing the fs. > >=20 > > When I booted in the third case, (ro) no problem... > >=20 > > I wonder ... does xfs has some check for some magic in there? I tried= =20 > > in all machines, and in all it damaged the mounted / jfs fs ... >=20 > sounds like mkfs.jfs is not zeroing enough of the device prior to > writing its fs. particularly block zero where the XFS superblock > lives. (some mkfs avoid zeroing this due to quirky partitioning setups > on some architectures, notably Suns). Or make sure to change the fstab so that the system does not try to mount a jfs partition as xfs. --=-AddVhan7kivMlBrWlxY+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBAOjecNRmM+OaGhBgRAsVhAJ9KrMl7fzejQkbXL7Z5wqmKR2b/cACcCNki 9jMjqPZNhP1VjJxHKNMmnJQ= =Y+5V -----END PGP SIGNATURE----- --=-AddVhan7kivMlBrWlxY+-- From owner-linux-xfs@oss.sgi.com Mon Feb 23 14:05:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 14:05:30 -0800 (PST) Received: from odin.sv.fintec.co.cr ([168.243.202.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NM55KO011222 for ; Mon, 23 Feb 2004 14:05:05 -0800 Received: from odin.fintec.co.cr ([192.168.201.229]) by odin.sv.fintec.co.cr (8.12.10/8.12.10) with ESMTP id i1NM55p6010797 for ; Mon, 23 Feb 2004 16:05:05 -0600 Message-ID: <403A790F.7060100@odin.fintec.co.cr> Date: Mon, 23 Feb 2004 16:05:03 -0600 From: Ivan Kocher Organization: Fintec SA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Problem with XFS and JFS References: <403A3366.3070809@odin.fintec.co.cr> <1077557148.4497.1.camel@naboo.americas.sgi.com> In-Reply-To: <1077557148.4497.1.camel@naboo.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2204 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikocher@odin.fintec.co.cr Precedence: bulk X-list: linux-xfs Yes, I take care of /etc/fstab also. Note that I started the machine with init=/bin/bash rw, so there is no /etc/fstab processing. But anyway, /etc/fstab was ok, with / declared as type jfs. Ivan -------- Russell Cattelan wrote: >>>Hi, >>> >>>Yesterday I was hit by a nasty bug ... >>> >>>I tried to change the filesystem of a couple machines from XFS to JFS, >>>so compiled kernel 2.4.23 with XFS (patch) and JFS. Once the jfs root >>>partition was up, it booted, and xfs "tried" to repair the partition. I >>> booted using my default setup and later after remaking all again using >>>init=/bin/bash rw, and even later init=/bin/bash ro >>> >>>In the first two cases cases, xfs tried its "repair", teling that it >>>recovered the journal... :( trashing the fs. >>> >>>When I booted in the third case, (ro) no problem... >>> >>>I wonder ... does xfs has some check for some magic in there? I tried >>>in all machines, and in all it damaged the mounted / jfs fs ... >>> >>> >>sounds like mkfs.jfs is not zeroing enough of the device prior to >>writing its fs. particularly block zero where the XFS superblock >>lives. (some mkfs avoid zeroing this due to quirky partitioning setups >>on some architectures, notably Suns). >> >> > >Or make sure to change the fstab so that the system does not try to >mount a jfs partition as xfs. > > > > From owner-linux-xfs@oss.sgi.com Mon Feb 23 14:39:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 14:39:24 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1NMdEKO012956 for ; Mon, 23 Feb 2004 14:39:14 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1NMd90P023011 for ; Mon, 23 Feb 2004 16:39:09 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1NMd8mN34542845; Mon, 23 Feb 2004 16:39:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1NMd8Eq173474; Mon, 23 Feb 2004 16:39:08 -0600 (CST) Subject: Re: Problem with XFS and JFS From: Eric Sandeen To: Ivan Kocher Cc: linux-xfs@oss.sgi.com In-Reply-To: <403A790F.7060100@odin.fintec.co.cr> References: <403A3366.3070809@odin.fintec.co.cr> <1077557148.4497.1.camel@naboo.americas.sgi.com> <403A790F.7060100@odin.fintec.co.cr> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1077575947.7791.88.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 23 Feb 2004 16:39:08 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2205 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs It does not make sense that xfs would be trying to replay a log from a partition which has been zeroed, then mkfs.jfs'd - there should be no xfs superblock magic left, and xfs should not try to do anything. What do you get from: dd if=/dev/your/device bs=1 count=4 | strings if you see "XFSB" in the output, then you still have an xfs superblock. -Eric p.s. actually you have stumbled upon our plan for global domination, once you have formatted with mkfs.xfs your drive is xfs forever. ;-) -- Eric Sandeen [C]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 Feb 23 19:11:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 19:11:05 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1O3B3KO030006 for ; Mon, 23 Feb 2004 19:11:03 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1O2xWF6026307 for ; Mon, 23 Feb 2004 18:59:33 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA14097 for ; Tue, 24 Feb 2004 13:59:31 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1O2xU7a000720 for ; Tue, 24 Feb 2004 13:59:31 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1O2xUYG000718 for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 13:59:30 +1100 Date: Tue, 24 Feb 2004 13:59:30 +1100 From: Tim Shimmin Message-Id: <200402240259.i1O2xUYG000718@sherman.melbourne.sgi.com> Subject: TAKE 907752 - xfstests v2 log recovery Apparently-To: X-archive-position: 2206 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Add test 087 which uses fsstress to create meta ops and src/godown to create a dirty log for recovery. It checks that FS looks reasonable after recovery and is a consistent state. There are more v2 log variants yet to try. Date: Mon Feb 23 18:58:40 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/xfs-cmds Inspected by: tes@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167354a xfstests/087 - 1.1 - Uses fsstress to create meta ops and src/godown to create a dirty log for recovery. It checks that FS looks reasonable after recovery and is a consistent state. There are more v2 log variants yet to try. xfstests/087.out - 1.1 - out file for 087 xfstests/group - 1.53 - Add new test 087. From owner-linux-xfs@oss.sgi.com Mon Feb 23 21:29:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 21:29:37 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1O5TLKO002897 for ; Mon, 23 Feb 2004 21:29:23 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1O5TD0P010218 for ; Mon, 23 Feb 2004 23:29:15 -0600 Received: from boing.melbourne.sgi.com (localhost [127.0.0.1]) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1O5TA3H1487037; Tue, 24 Feb 2004 16:29:10 +1100 (AEDT) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1O5T8JA1355940; Tue, 24 Feb 2004 16:29:08 +1100 (AEDT) Date: Tue, 24 Feb 2004 16:29:08 +1100 From: Tim Shimmin To: Chris Wedgwood Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 909639 - XFS log recovery for v2 >32K (64K) LRs on log wrap trips assert Message-ID: <20040224162908.S208237@boing.melbourne.sgi.com> References: <200402200708.i1K78NSd019670@sherman.melbourne.sgi.com> <20040220121650.GA27998@dingdong.cryptoapps.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: <20040220121650.GA27998@dingdong.cryptoapps.com>; from cw@f00f.org on Fri, Feb 20, 2004 at 04:16:50AM -0800 X-archive-position: 2207 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: linux-xfs Hi Chris, On Fri, Feb 20, 2004 at 04:16:50AM -0800, Chris Wedgwood wrote: > On Fri, Feb 20, 2004 at 06:08:23PM +1100, Tim Shimmin wrote: > > > Fix log recovery case when have v2 log with size >32K and we have a > > Log Record wrapping around the physical log end. Need to reset the > > pb size back to what we were using and NOT just 32K. > > Does this mean v2 logs are 'mostly' safe right now? > > > --cw > :) The status... I have one pending fix to checkin for the v2 log code. Need to clean up my debugging code in the change and get it reviewed. (It should fix the handling of reservations with v2 log striping and the padding that can occur with it. The bug was triggering an assert that checked that the reservation ptr wasn't falling behind the tail of the log.) I have written some qa tests to check that the contents of the log is basically the same irrespective of the iclog buffer size and irrespective of the use of log striping. And then there are tests to check that on recovery we are doing a reasonable thing for v2 logs. I just ran all the tests twice with my kernel and they passed. I have tickled some shutdown and unmount bugs in the past with these tests but they do not seem to be v2 log related :) --Tim From owner-linux-xfs@oss.sgi.com Mon Feb 23 21:47:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Feb 2004 21:47:52 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1O5loKO004191 for ; Mon, 23 Feb 2004 21:47:50 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1O5lh0P016210 for ; Mon, 23 Feb 2004 23:47:44 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1O5lfhI14955362 for ; Tue, 24 Feb 2004 16:47:42 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1O5leOB14939279 for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 16:47:40 +1100 (EST) Date: Tue, 24 Feb 2004 16:47:40 +1100 (EST) From: Nathan Scott Message-Id: <200402240547.i1O5leOB14939279@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - kdb update X-archive-position: 2208 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Merge in latest KDB changes from Keith. Date: Mon Feb 23 21:47:18 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/2.6.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: 2.6.x-xfs:linux:167359a kdb/Makefile - 1.6 kdb/ChangeLog - 1.7 From owner-linux-xfs@oss.sgi.com Tue Feb 24 03:00:18 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 03:00:20 -0800 (PST) Received: from web25203.mail.ukl.yahoo.com (web25203.mail.ukl.yahoo.com [217.12.10.63]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OB0HKO015608 for ; Tue, 24 Feb 2004 03:00:18 -0800 Message-ID: <20040224110011.35273.qmail@web25203.mail.ukl.yahoo.com> Received: from [195.173.4.13] by web25203.mail.ukl.yahoo.com via HTTP; Tue, 24 Feb 2004 11:00:11 GMT Date: Tue, 24 Feb 2004 11:00:11 +0000 (GMT) From: =?iso-8859-1?q?Alexander=20Fisher?= Subject: Re: large allocation groups fix To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-archive-position: 2209 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexjfisher@yahoo.co.uk Precedence: bulk X-list: linux-xfs --- Eric Sandeen wrote: > On Mon, 23 Feb 2004, Alexander Fisher wrote: > > > create by default. I would like to 'fix' my > kernel so > > that allocation group sizes above 4GB don't result > in > > lockups. > > > > Is there a patch I can use against the 1.3.1 xfs > > release? I've looked at the fix included in > kernel > > changeset 1.1276.1.2 > > > http://linux.bkbits.net:8080/linux-2.4/cset@1.1276.1.2?nav=index.html|src/|src/fs|src/fs/xfs|related/fs/xfs/xfs_iomap.h > > but it doesn't apply to the official xfs release. > > That looks like the right patchset, I would not > expect > that it is -too- difficult to backport to 1.3.1, > although > I have not looked... Your other workaround is to > use > an older mkfs that does not make AGs > 4G (or > explicitly > specify 4G AGs with your mkfs). > > > On a related point, are there any plans to > announce > > any more official xfs releases or is it just > assumed > > that people will use upto date linux kernels? > > Probably the latter, although I'm not quite certain > yet. > > -Eric > Unfortunately backporting the fix in any sensible time period is beyond me. At least one of the files being patched doesn't even exist in the 1.3.1 release. If I try to remedy this by applying other updates to the xfs code first I'm going to get into the situation where other core kernel updates are also required. These will too have their dependencies. I think it really needs somebody who knows the xfs code and understands the problem to produce a 1.3.1 fix. You said that one of my workarounds would be to downgrade xfstools (or at least mkfs.xfs). Wouldn't it be better if the latest released version of xfstools worked correctly with the latest released version of xfs? Perhaps its possible for mkfs.xfs to detect the use of xfs1.3.1 (and earlier?) and not create large allocation groups under those conditions. Kind Regards, Alex ___________________________________________________________ Yahoo! Messenger - Communicate instantly..."Ping" your friends today! Download Messenger Now http://uk.messenger.yahoo.com/download/index.html From owner-linux-xfs@oss.sgi.com Tue Feb 24 03:08:03 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 03:08:05 -0800 (PST) Received: from hermes.acsalaska.net (hermes.acsalaska.net [209.112.155.38]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OB82KO016033 for ; Tue, 24 Feb 2004 03:08:02 -0800 Received: from erbenson.alaska.net (121-pm30.nwc.acsalaska.net [209.112.158.121]) by hermes.acsalaska.net (8.12.10/8.12.10) with ESMTP id i1OB81Pw037044 for ; Tue, 24 Feb 2004 02:08:01 -0900 (AKST) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 4D8B839E9 for ; Tue, 24 Feb 2004 02:08:00 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 7CF8640FF35; Tue, 24 Feb 2004 02:07:59 -0900 (AKST) Date: Tue, 24 Feb 2004 02:07:59 -0900 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: large allocation groups fix Message-ID: <20040224110759.GE1003@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20040224110011.35273.qmail@web25203.mail.ukl.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RpqchZ26BWispMcB" Content-Disposition: inline In-Reply-To: <20040224110011.35273.qmail@web25203.mail.ukl.yahoo.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-ACS-Spam-Status: no X-ACS-Scanned-By: MD 2.39; SA 2.63; spamdefang 1.93 X-archive-position: 2210 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: erbenson@alaska.net Precedence: bulk X-list: linux-xfs --RpqchZ26BWispMcB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2004 at 11:00:11AM +0000, Alexander Fisher wrote: > You said that one of my workarounds would be to > downgrade xfstools (or at least mkfs.xfs). Wouldn't > it be better if the latest released version of > xfstools worked correctly with the latest released > version of xfs? Perhaps its possible for mkfs.xfs to the latest version of XFS is in Linux 2.4.25 > detect the use of xfs1.3.1 (and earlier?) and not > create large allocation groups under those conditions. such runtime checks are really not appropriate for a mkfs IMO.=20=20 you can force current mkfs to not create large AGs. read the man page. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --RpqchZ26BWispMcB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iEYEARECAAYFAkA7MI8ACgkQJKx7GixEevw7tgCfYDk8BzdGxNDrN8Ga7oJcc84x MnEAn24ZD/Nc9ckEI3xqodmeCkmoc9K5 =exUz -----END PGP SIGNATURE----- --RpqchZ26BWispMcB-- From owner-linux-xfs@oss.sgi.com Tue Feb 24 06:15:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 06:15:39 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OEFLKO022584 for ; Tue, 24 Feb 2004 06:15:21 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HTL00B01E2K5I@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 08:15:19 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HTL00266E9IYC@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 08:15:18 -0600 (CST) Date: Tue, 24 Feb 2004 08:15:18 -0600 From: Dan Yocum Subject: FS, CPU or memory problem? To: xfs-list Message-id: <403B5C76.5060200@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_kjqKKLyggv5+X85uugXiWw)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-archive-position: 2211 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --Boundary_(ID_kjqKKLyggv5+X85uugXiWw) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I'm pretty sure the attached error is due to a hardware problem (shush mkp), but I'd like to other opinions. Thanks, Dan -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. --Boundary_(ID_kjqKKLyggv5+X85uugXiWw) Content-type: text/plain; name=dp0-kernel-crash.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=dp0-kernel-crash.txt [root@sdssdp0 /root]# mount /dev/md3 /export/data/dp0.a/ XFS mounting filesystem md(9,3) Starting XFS recovery on filesystem: md(9,3) (dev: 9/3) Unable to handle kernel NULL pointer dereference at virtual address 00000030 printing eip: c01cc4de *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010206 EIP is at (2.4.18-26xfs12tw031rh73x) eax: 00000000 ebx: 00000000 ecx: f6c13800 edx: 14190030 esi: f6c13800 edi: 00000000 ebp: f61d9a5c esp: f61d9a54 ds: 0018 es: 0018 ss: 0018 Process mount (pid: 2526, stackpage=f61d9000) Stack: 00000000 0000000c f61d9ac4 c01babef c02a1bee f6c13800 00000000 14190030 00000000 00000000 14190030 00000000 00000000 f61d8000 00000246 00000018 f61d9aac c01ba482 f61b0fa4 f618e1c0 f618ea40 f61b0f80 f61d9ac8 c01ba4da Call Trace: [] (0xf61d9a60)) [] (0xf61d9a98)) [] (0xf61d9ab0)) [] (0xf61d9ac8)) [] (0xf61d9aec)) [] (0xf61d9b04)) [] (0xf61d9b3c)) [] (0xf61d9b64)) [] (0xf61d9bf0)) [] (0xf61d9c28)) [] (0xf61d9c60)) [] (0xf61d9cac)) [] (0xf61d9cd0)) [] (0xf61d9d68)) [] (0xf61d9d84)) [] (0xf61d9dc8)) [] (0xf61d9df8)) [] (0xf61d9e7c)) [] (0xf61d9eb4)) [] (0xf61d9ec0)) [] (0xf61d9ed4)) [] (0xf61d9f08)) [] (0xf61d9f3c)) [] (0xf61d9f78)) [] (0xf61d9f8c)) [] (0xf61d9fc0)) Code: 8b 58 30 85 c0 8b 4d 18 53 bb 0c 00 00 00 74 04 0f b7 58 78 Segmentation fault --Boundary_(ID_kjqKKLyggv5+X85uugXiWw)-- From owner-linux-xfs@oss.sgi.com Tue Feb 24 06:45:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 06:45:56 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OEjeKO023259 for ; Tue, 24 Feb 2004 06:45:40 -0800 Received: (qmail 9977 invoked by alias); 24 Feb 2004 14:45:39 -0000 Received: from unknown (HELO colorfront.com) (195.228.226.66) by 0 with SMTP; 24 Feb 2004 14:45:39 -0000 Message-ID: <403BE0E5.5060309@colorfront.com> Date: Tue, 24 Feb 2004 15:40:21 -0800 From: Bela Babik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: XFS patched RHELv3 kernels now available - please test Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2212 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bela@colorfront.com Precedence: bulk X-list: linux-xfs Hello! My NVidia X server is hangup on startup when i use this kernel. Machine: Ibm Z Pro 6221, NVidia FX3000G Driver: i have tried multiple drivers (5336, 5328,4496,4363) What can be the problem ? Bela From owner-linux-xfs@oss.sgi.com Tue Feb 24 06:52:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 06:53:00 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OEqvKO023718 for ; Tue, 24 Feb 2004 06:52:58 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HTL00A01FZ9RT@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 08:52:57 -0600 (CST) Received: from maxwell.fnal.gov (maxwell.fnal.gov [131.225.54.225]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPS id <0HTL0039GG0904@woozle.fnal.gov>; Tue, 24 Feb 2004 08:52:57 -0600 (CST) Date: Tue, 24 Feb 2004 08:52:57 -0600 (CST) From: Chris Green Subject: Re: XFS patched RHELv3 kernels now available - please test In-reply-to: <403BE0E5.5060309@colorfront.com> To: Bela Babik Cc: linux-xfs@oss.sgi.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-archive-position: 2213 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: greenc@fnal.gov Precedence: bulk X-list: linux-xfs On Tue, 24 Feb 2004, Bela Babik wrote: > Hello! > > My NVidia X server is hangup on startup when i use this > kernel. > Machine: Ibm Z Pro 6221, NVidia FX3000G > Driver: i have tried multiple drivers (5336, 5328,4496,4363) > > What can be the problem ? The module needs to be recompiled on your machine with the kernel source being properly configured (make dep after initializing the config). It's possible that when you re-installed the NVidia module, the NVidia package found a close-match (but incorrect) binary on its FTP site and that's why you're hanging. You need to give the -n (I think) switch to the .run script to prevent it downloading a binary module and force it to compile its own. You may need to play with the options but you'll get there eventually. I hope this helps, Chris. > > Bela > > > -- Chris Green, MiniBooNE / LANL. Email greenc@fnal.gov Tel: (630) 840-2167. Fax: (630) 840-3867 From owner-linux-xfs@oss.sgi.com Tue Feb 24 07:13:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 07:13:45 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OFDTKO024321 for ; Tue, 24 Feb 2004 07:13:30 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HTL00L01GWQY1@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 09:13:29 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HTL002EWGYGVP@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 09:13:29 -0600 (CST) Date: Tue, 24 Feb 2004 09:13:28 -0600 From: Dan Yocum Subject: Re: FS, CPU or memory problem? In-reply-to: <403B5C76.5060200@fnal.gov> To: Dan Yocum Cc: xfs-list Message-id: <403B6A18.5080409@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <403B5C76.5060200@fnal.gov> X-archive-position: 2214 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Oop. I should clarify: by "hardware" I mean disk and/or 3ware controller card problem. Thanks, Dan Dan Yocum wrote: > I'm pretty sure the attached error is due to a hardware problem (shush > mkp), but I'd like to other opinions. > > Thanks, > Dan > > > ------------------------------------------------------------------------ > > [root@sdssdp0 /root]# mount /dev/md3 /export/data/dp0.a/ > XFS mounting filesystem md(9,3) > Starting XFS recovery on filesystem: md(9,3) (dev: 9/3) > Unable to handle kernel NULL pointer dereference at virtual address 00000030 > printing eip: > c01cc4de > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010206 > > EIP is at (2.4.18-26xfs12tw031rh73x) > eax: 00000000 ebx: 00000000 ecx: f6c13800 edx: 14190030 > esi: f6c13800 edi: 00000000 ebp: f61d9a5c esp: f61d9a54 > ds: 0018 es: 0018 ss: 0018 > Process mount (pid: 2526, stackpage=f61d9000) > Stack: 00000000 0000000c f61d9ac4 c01babef c02a1bee f6c13800 00000000 14190030 > 00000000 00000000 14190030 00000000 00000000 f61d8000 00000246 00000018 > f61d9aac c01ba482 f61b0fa4 f618e1c0 f618ea40 f61b0f80 f61d9ac8 c01ba4da > Call Trace: [] (0xf61d9a60)) > [] (0xf61d9a98)) > [] (0xf61d9ab0)) > [] (0xf61d9ac8)) > [] (0xf61d9aec)) > [] (0xf61d9b04)) > [] (0xf61d9b3c)) > [] (0xf61d9b64)) > [] (0xf61d9bf0)) > [] (0xf61d9c28)) > [] (0xf61d9c60)) > [] (0xf61d9cac)) > [] (0xf61d9cd0)) > [] (0xf61d9d68)) > [] (0xf61d9d84)) > [] (0xf61d9dc8)) > [] (0xf61d9df8)) > [] (0xf61d9e7c)) > [] (0xf61d9eb4)) > [] (0xf61d9ec0)) > [] (0xf61d9ed4)) > [] (0xf61d9f08)) > [] (0xf61d9f3c)) > [] (0xf61d9f78)) > [] (0xf61d9f8c)) > [] (0xf61d9fc0)) > > > Code: 8b 58 30 85 c0 8b 4d 18 53 bb 0c 00 00 00 74 04 0f b7 58 78 > Segmentation fault > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. From owner-linux-xfs@oss.sgi.com Tue Feb 24 07:24:09 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 07:24:12 -0800 (PST) Received: from mta3.navair.navy.mil (mta3.navair.navy.mil [192.58.199.165]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OFO8KO025189 for ; Tue, 24 Feb 2004 07:24:09 -0800 Received: by mta3.navair.navy.mil (Postfix, from userid 0) id 5398716C114; Tue, 24 Feb 2004 10:24:02 -0500 (EST) Received: from neim04.nawcad.navy.mil (neim04.nawcad.navy.mil [140.229.37.1]) by mta3.navair.navy.mil (Postfix) with ESMTP id B16EA16C269 for ; Tue, 24 Feb 2004 10:24:01 -0500 (EST) Received: by neim04.nawcad.navy.mil with Internet Mail Service (5.5.2657.72) id ; Tue, 24 Feb 2004 10:24:13 -0500 Message-ID: From: "Kirkpatrick, Drew (Red-Inc)" To: "'linux-xfs@oss.sgi.com'" Subject: remote xfsdump problems.... Date: Tue, 24 Feb 2004 10:28:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-archive-position: 2215 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: KirkpatricDA@navair.navy.mil Precedence: bulk X-list: linux-xfs I'm having significant difficulties using xfsdump on my linux box. xfsdump goes out to lunch, and never comes back. I can't kill the process either, ps aux shows it in an eternal 'D' state, and I have to reboot it to kill it. From ps aux: root 6238 0.0 0.0 2004 932 pts/3 S 10:05 0:00 /bin/bash ./backupRaid root 6247 0.5 0.0 5096 2148 pts/3 D 10:05 0:05 xfsdump -f gaby:/dev/nst0 -l 0 -E -p 30 -M 2004-02-24 -L 2004-02-24 -c /root/backups/dumps/changeTape /raid root 6251 0.0 0.0 0 0 pts/3 Z 10:05 0:00 [rsh ] Here's the info on my xfs filesystem: (from mount) /dev/md0 on /raid type xfs (rw) (from df -lh) /dev/md0 2.6T 1.6T 1.1T 58% /raid Both computers are linux boxes, one (xena) with a 2.6 TB xfs filesystem. The other computer (gabby) doesn't have a xfs filesystem, but does have the tape library. Both rsh and ssh work without passwords. Here's what I'm running on xena: xfsdump -f gaby:/dev/nst0 -l 0 -E -p 30 -M `date -I` -L `date -I` -c /root/backups/dumps/changeTape /raid not that it ever get's here, but this is the contents of the changeTape command (which does work): rsh -l root gaby '/usr/local/sbin/mtx -f /dev/sg3 next 0' I've preloaded a tape myself into the drive 0, since I'm only testing so far. Here's the output I get from xfsdump: [root@xena dumps]# xfsdump -f gaby:/dev/nst0 -l 0 -E -p 30 -M `date -I` -L `date -I` -c /root/backups/dumps/changeTape /raid xfsdump: using scsi tape (drive_scsitape) strategy xfsdump: version 2.2.13 (dump format 3.0) - Running single-threaded xfsdump: level 0 dump of xena.someplace.com:/raid xfsdump: dump date: Tue Feb 24 10:05:47 2004 xfsdump: session id: 9e4cc962-351a-4197-afc5-cae209980173 xfsdump: session label: "2004-02-24" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: status at 10:05:57: inomap phase 2 970753/15358367 inos scanned, 10 seconds elapsed And here's where it sits forever. I'm desperate here folks! HELP!!! lol Much thanks in advance... -Drew drew.kirkpatrick@red-inc.us From owner-linux-xfs@oss.sgi.com Tue Feb 24 07:26:43 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 07:26:44 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OFQgKO025610 for ; Tue, 24 Feb 2004 07:26:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1OFMNF6019624 for ; Tue, 24 Feb 2004 07:22:23 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1OFMM2734601619; Tue, 24 Feb 2004 09:22:23 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1OFMMEr243494; Tue, 24 Feb 2004 09:22:22 -0600 (CST) Date: Tue, 24 Feb 2004 09:22:22 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: =?iso-8859-1?q?Alexander=20Fisher?= cc: linux-xfs@oss.sgi.com Subject: Re: large allocation groups fix In-Reply-To: <20040224110011.35273.qmail@web25203.mail.ukl.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2216 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Tue, 24 Feb 2004, Alexander Fisher wrote: > Unfortunately backporting the fix in any sensible time > period is beyond me. At least one of the files being > patched doesn't even exist in the 1.3.1 release. page_buf.[ch] turned into xfs_buf.[ch], and moved from fs/xfs/pagebuf to fs/xfs/linux-2.[46]/ With that, it will be much closer to applying. > If I > try to remedy this by applying other updates to the > xfs code first I'm going to get into the situation > where other core kernel updates are also required. > These will too have their dependencies. I think it > really needs somebody who knows the xfs code and > understands the problem to produce a 1.3.1 fix. We can't be in the business of applying all new bugfixes to all past releases, we'd soon run out of time to do real work, I'm afraid. > You said that one of my workarounds would be to > downgrade xfstools (or at least mkfs.xfs). Wouldn't > it be better if the latest released version of > xfstools worked correctly with the latest released > version of xfs? It does; XFS in 2.4.25 + xfsprogs 2.6.3 does not exhibit this problem. > Perhaps its possible for mkfs.xfs to > detect the use of xfs1.3.1 (and earlier?) and not > create large allocation groups under those conditions. mkfs is a purely userspace app, it has no knowledge of (and no need for) any kernelspace code, so that's not a workable solution. I'd suggest that you use 2.4.25, downgrade xfsprogs, specify 4g AG size with later xfsprogs, or work just a bit more with the patch to get it to apply to 1.3.1 - at least you have a few options. :) Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Feb 24 07:32:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 07:32:13 -0800 (PST) Received: from hotmail.com (law9-f95.law9.hotmail.com [64.4.9.95]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OFWBKO026089 for ; Tue, 24 Feb 2004 07:32:11 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 24 Feb 2004 07:32:06 -0800 Received: from 68.84.13.81 by lw9fd.law9.hotmail.msn.com with HTTP; Tue, 24 Feb 2004 15:32:06 GMT X-Originating-IP: [68.84.13.81] X-Originating-Email: [drew_kirkpatrick@hotmail.com] X-Sender: drew_kirkpatrick@hotmail.com From: "Drew Kirkpatrick" To: linux-xfs@oss.sgi.com Subject: remote xfsdump problems.... Date: Tue, 24 Feb 2004 10:32:06 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Feb 2004 15:32:06.0656 (UTC) FILETIME=[5C22F800:01C3FAEB] X-archive-position: 2217 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: drew_kirkpatrick@hotmail.com Precedence: bulk X-list: linux-xfs I'm having significant difficulties using xfsdump on my linux box. xfsdump goes out to lunch, and never comes back. I can't kill the process either, ps aux shows it in an eternal 'D' state, and I have to reboot it to kill it. From ps aux: root 6238 0.0 0.0 2004 932 pts/3 S 10:05 0:00 /bin/bash ./backupRaid root 6247 0.5 0.0 5096 2148 pts/3 D 10:05 0:05 xfsdump -f gaby:/dev/nst0 -l 0 -E -p 30 -M 2004-02-24 -L 2004-02-24 -c /root/backups/dumps/changeTape /raid root 6251 0.0 0.0 0 0 pts/3 Z 10:05 0:00 [rsh ] Here's the info on my xfs filesystem: (from mount) /dev/md0 on /raid type xfs (rw) (from df -lh) /dev/md0 2.6T 1.6T 1.1T 58% /raid Both computers are linux boxes, one (xena) with a 2.6 TB xfs filesystem. The other computer (gabby) doesn't have a xfs filesystem, but does have the tape library. Both rsh and ssh work without passwords. Here's what I'm running on xena: xfsdump -f gaby:/dev/nst0 -l 0 -E -p 30 -M `date -I` -L `date -I` -c /root/backups/dumps/changeTape /raid not that it ever get's here, but this is the contents of the changeTape command (which does work): rsh -l root gaby '/usr/local/sbin/mtx -f /dev/sg3 next 0' I've preloaded a tape myself into the drive 0, since I'm only testing so far. Here's the output I get from xfsdump: [root@xena dumps]# xfsdump -f gaby:/dev/nst0 -l 0 -E -p 30 -M `date -I` -L `date -I` -c /root/backups/dumps/changeTape /raid xfsdump: using scsi tape (drive_scsitape) strategy xfsdump: version 2.2.13 (dump format 3.0) - Running single-threaded xfsdump: level 0 dump of xena.someplace.com:/raid xfsdump: dump date: Tue Feb 24 10:05:47 2004 xfsdump: session id: 9e4cc962-351a-4197-afc5-cae209980173 xfsdump: session label: "2004-02-24" xfsdump: ino map phase 1: skipping (no subtrees specified) xfsdump: ino map phase 2: constructing initial dump list xfsdump: status at 10:05:57: inomap phase 2 970753/15358367 inos scanned, 10 seconds elapsed And here's where it sits forever. I'm desperate here folks! HELP!!! lol Much thanks in advance... -Drew _________________________________________________________________ Get a FREE online computer virus scan from McAfee when you click here. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-linux-xfs@oss.sgi.com Tue Feb 24 08:50:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 08:50:41 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OGoGKO030648 for ; Tue, 24 Feb 2004 08:50:16 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HTL00L01LEKB9@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 10:50:16 -0600 (CST) Received: from fnal.gov (sdsslnx13.fnal.gov [131.225.7.152]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTPSA id <0HTL002WNLFRN9@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 10:50:15 -0600 (CST) Date: Tue, 24 Feb 2004 10:50:15 -0600 From: Dan Yocum Subject: Re: FS, CPU or memory problem? In-reply-to: <403B6A18.5080409@fnal.gov> To: xfs-list Message-id: <403B80C7.7080602@fnal.gov> Organization: Fermilab MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 References: <403B5C76.5060200@fnal.gov> <403B6A18.5080409@fnal.gov> X-archive-position: 2218 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: yocum@fnal.gov Precedence: bulk X-list: linux-xfs Ignore me for the time being - I'm getting a clue. When I've got part of one, I'll come back. back in my box, back in my box.... Dan Yocum wrote: > Oop. I should clarify: by "hardware" I mean disk and/or 3ware > controller card problem. > > Thanks, > Dan > > > Dan Yocum wrote: > >> I'm pretty sure the attached error is due to a hardware problem (shush >> mkp), but I'd like to other opinions. >> >> Thanks, >> Dan >> >> >> ------------------------------------------------------------------------ >> >> [root@sdssdp0 /root]# mount /dev/md3 /export/data/dp0.a/ >> XFS mounting filesystem md(9,3) >> Starting XFS recovery on filesystem: md(9,3) (dev: 9/3) >> Unable to handle kernel NULL pointer dereference at virtual address >> 00000030 >> printing eip: >> c01cc4de >> *pde = 00000000 >> Oops: 0000 >> CPU: 0 >> EIP: 0010:[] Not tainted >> EFLAGS: 00010206 >> >> EIP is at (2.4.18-26xfs12tw031rh73x) >> eax: 00000000 ebx: 00000000 ecx: f6c13800 edx: 14190030 >> esi: f6c13800 edi: 00000000 ebp: f61d9a5c esp: f61d9a54 >> ds: 0018 es: 0018 ss: 0018 >> Process mount (pid: 2526, stackpage=f61d9000) >> Stack: 00000000 0000000c f61d9ac4 c01babef c02a1bee f6c13800 00000000 >> 14190030 00000000 00000000 14190030 00000000 00000000 f61d8000 >> 00000246 00000018 f61d9aac c01ba482 f61b0fa4 f618e1c0 f618ea40 >> f61b0f80 f61d9ac8 c01ba4da Call Trace: [] (0xf61d9a60)) >> [] (0xf61d9a98)) >> [] (0xf61d9ab0)) >> [] (0xf61d9ac8)) >> [] (0xf61d9aec)) >> [] (0xf61d9b04)) >> [] (0xf61d9b3c)) >> [] (0xf61d9b64)) >> [] (0xf61d9bf0)) >> [] (0xf61d9c28)) >> [] (0xf61d9c60)) >> [] (0xf61d9cac)) >> [] (0xf61d9cd0)) >> [] (0xf61d9d68)) >> [] (0xf61d9d84)) >> [] (0xf61d9dc8)) >> [] (0xf61d9df8)) >> [] (0xf61d9e7c)) >> [] (0xf61d9eb4)) >> [] (0xf61d9ec0)) >> [] (0xf61d9ed4)) >> [] (0xf61d9f08)) >> [] (0xf61d9f3c)) >> [] (0xf61d9f78)) >> [] (0xf61d9f8c)) >> [] (0xf61d9fc0)) >> >> >> Code: 8b 58 30 85 c0 8b 4d 18 53 bb 0c 00 00 00 74 04 0f b7 58 78 >> Segmentation fault >> > -- Dan Yocum Sloan Digital Sky Survey, Fermilab 630.840.6509 yocum@fnal.gov, http://www.sdss.org SDSS. Mapping the Universe. There is no spoon. From owner-linux-xfs@oss.sgi.com Tue Feb 24 09:20:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 09:20:27 -0800 (PST) Received: from c.pexit.com ([216.187.68.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1OHKOKO002588 for ; Tue, 24 Feb 2004 09:20:25 -0800 Received: from consensyxdlcmm (CPE0002b38c45e3-CM000a73663c88.cpe.net.cable.rogers.com [63.139.198.156]) by c.pexit.com (8.11.6/8.11.6) with SMTP id i1OHK3s29812; Tue, 24 Feb 2004 12:20:03 -0500 Message-ID: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> From: "Alex Wun" To: Cc: "Eric Sandeen" References: Subject: XFS Writes: IOLOCK_EXCL Date: Tue, 24 Feb 2004 12:20:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 2219 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexwun@consensys.com Precedence: bulk X-list: linux-xfs Hi. What I've been trying to do is squeeze some more write performance out of my system. (Dual Pentium Xeon processors, 1GB ram, software RAID, 2.4.20 kernel patched with XFS 1.3.1) I've ended up fiddling with some XFS code and have found that write performance can improve significantly in certain applications (i.e. exporting the filesystem over a network). I've left the system running (and writing) over the weekend and it seems to be stable. Although things look good for now, I'd like to be certain that I haven't broken anything. Essentially, this is what I've done: In the function xfs_fsync(): Instead of: VOP_FLUSH_PAGES(...); I essentially have: VOP_COMMIT_PAGES(...); xfs_iunlock(ip, XFS_IOLOCK_EXCL); VOP_CLEANUP_PAGES(...); xfs_ilock(ip, XFS_IOLOCK_EXCL); Where VOP_COMMIT_PAGES() + VOP_CLEANUP_PAGES() does the same thing as VOP_FLUSH_PAGES() but in two parts, first the writing of the pages then the cleanup. So I've basically released the XFS_IOLOCK_EXCL during page cleanup. This may not work for everyone but it seems to give me better writing (maybe strict operating conditions will apply?). But I'd just like to ask, from a conceptual stand-point, whether this is a legitimate thing to do. Thanks for your time, Alex Wun -- Sorry if this gets posted twice :( From owner-linux-xfs@oss.sgi.com Tue Feb 24 10:31:05 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 10:31:20 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1OIV5KO011356 for ; Tue, 24 Feb 2004 10:31:05 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1OIV5GC011355 for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 10:31:05 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1OIV2KS011330 for ; Tue, 24 Feb 2004 10:31:03 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1OINNIF006575; Tue, 24 Feb 2004 10:23:23 -0800 Date: Tue, 24 Feb 2004 10:23:23 -0800 Message-Id: <200402241823.i1OINNIF006575@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2220 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From driver@jpl.nasa.gov 2004-24-02 10:23 PDT ------- Has anyone found a resolution to this? Even if it is only running a "better" version of xfsrepair on my corrupt filesystem? Is there any more data I can send to help out? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 24 11:31:04 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 11:31:17 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1OJV4KO017131 for ; Tue, 24 Feb 2004 11:31:04 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1OJV4R3017130 for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 11:31:04 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1OJV2KS017114 for ; Tue, 24 Feb 2004 11:31:02 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1OIjehj016183; Tue, 24 Feb 2004 10:45:40 -0800 Date: Tue, 24 Feb 2004 10:45:40 -0800 Message-Id: <200402241845.i1OIjehj016183@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 274] xfs_iunlink_remove: xfs_inotobp() returned error 22 X-Bugzilla-Reason: AssignedTo X-archive-position: 2221 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=274 ------- Additional Comments From sandeen@sgi.com 2004-24-02 10:45 PDT ------- Bryan, can you post the xfs diff between 2.4.19-36mdkenterprise and 2.4.19-37mdkenterprise somewhere? If you really saw it appear only after that upgrade, that'd be helpful. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Tue Feb 24 15:15:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 15:16:02 -0800 (PST) Received: from heretic.physik.fu-berlin.de (root@heretic.physik.fu-berlin.de [160.45.32.227]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1ONFnKO029752 for ; Tue, 24 Feb 2004 15:15:49 -0800 Received: by heretic.physik.fu-berlin.de (8.12.10/8.12.10) with ESMTP id i1ONFbWN020466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Feb 2004 00:15:42 +0100 Received: (from thimm@localhost) by neu.nirvana (8.12.10/8.12.10/Submit) id i1ONFLia021217; Wed, 25 Feb 2004 00:15:21 +0100 Date: Wed, 25 Feb 2004 00:15:21 +0100 From: Axel Thimm To: Dan Yocum Cc: linux-xfs@oss.sgi.com, ATrpms user list Subject: Re: difference between 'at' and non-'at' kernel rpms Message-ID: <20040224231521.GI16826@neu.nirvana> References: <403B7E43.7020200@fnal.gov> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WHz+neNWvhIGAO8A" Content-Disposition: inline In-Reply-To: <403B7E43.7020200@fnal.gov> User-Agent: Mutt/1.4.2i X-archive-position: 2222 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Axel.Thimm@physik.fu-berlin.de Precedence: bulk X-list: linux-xfs --WHz+neNWvhIGAO8A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 24, 2004 at 10:39:31AM -0600, Dan Yocum wrote: > Axel, >=20 > First off, thanks a ton for keeping the RH+SGI kernels up-to-date. I=20 > really appreciate it. >=20 > What's the difference between the 'at' tagged kernels and the non-'at'=20 > ones. For instance: >=20 > kernel-source-2.4.20-30_37.rh7.3.at.i386.rpm > vs. > kernel-source-2.4.20-30.7.i386.rpm Red Hat stopped offering updates for RH 7.3 and 8.0 since the end of the year. The kernels for RH9/8.0/7.3 were kept in sync for some time, so it is easy to build the kernels for 8.0 and 7.3 out of RH9' sources. So 2.4.20-30.7 is the kernel Red Hat would have published, if RH7.3 would not have been past EOL. As such it does not contain any XFS, lm_sensors etc. patches as the 'at' series does. For XFS on Red Hat 7.3 you want 2.4.20-30_37.rh7.3.at. > Thanks, > Dan >=20 --=20 Axel.Thimm@physik.fu-berlin.de --WHz+neNWvhIGAO8A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAO9sJQBVS1GOamfERAlzUAJ4i11PonS+A6PzyNEfUNcEfYc+bsgCglbAE HJ+DFeYqJBW/BXfFB/yla+k= =BbK3 -----END PGP SIGNATURE----- --WHz+neNWvhIGAO8A-- From owner-linux-xfs@oss.sgi.com Tue Feb 24 15:27:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 15:27:53 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1ONRpKO030376 for ; Tue, 24 Feb 2004 15:27:51 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HTM009013T4Y7@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 17:27:50 -0600 (CST) Received: from nietzsche.fnal.gov (nietzsche.fnal.gov [131.225.80.76]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HTM006A23UEMR@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Tue, 24 Feb 2004 17:27:50 -0600 (CST) Date: Tue, 24 Feb 2004 17:27:51 -0600 From: Joe Kaiser Subject: kernel debugger and Infortrend and bad blocks To: linux-xfs@oss.sgi.com Message-id: <1077665271.1051.21.camel@nietzsche.fnal.gov> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-type: text/plain Content-transfer-encoding: 7BIT X-archive-position: 2223 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlkaiser@fnal.gov Precedence: bulk X-list: linux-xfs Hi, I have a number of Infortrends that cause XFS to go into the kernel debugger and unmount the XFS filesystem whenever a bad block is found on the disk. A remount and then a dismount and an xfs_repair is then required to fix the problem. Is there anyway to avoid this? Why is XFS even getting bad block information from the disk? I am using XFS1.3.1 on 2.4.20-20.9..... Thanks, Joe -- =================================================================== Joe Kaiser - Systems Administrator Fermi Lab CD/OSS-SCS Never laugh at live dragons. 630-840-6444 jlkaiser@fnal.gov =================================================================== From owner-linux-xfs@oss.sgi.com Tue Feb 24 15:57:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 15:57:51 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1ONvRKO031657 for ; Tue, 24 Feb 2004 15:57:29 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1ONvFF6001838 for ; Tue, 24 Feb 2004 15:57:16 -0800 Received: from thistle-e236.americas.sgi.com (thistle-e236.americas.sgi.com [128.162.236.204]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1ONvFEk34606509; Tue, 24 Feb 2004 17:57:15 -0600 (CST) Received: from clink.americas.sgi.com (clink.americas.sgi.com [128.162.236.153]) by thistle-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1ONvFkP2355569; Tue, 24 Feb 2004 17:57:15 -0600 (CST) Received: from clink (localhost [127.0.0.1]) by clink.americas.sgi.com (SGI-8.12.5/8.12.5/erikj-IRIX6519-news) with ESMTP id i1ONur9i13910926; Tue, 24 Feb 2004 17:57:04 -0600 (CST) Message-Id: <200402242357.i1ONur9i13910926@clink.americas.sgi.com> To: Mike Montour cc: linux-xfs@oss.sgi.com Subject: Re: dm_write_invis() blocking problem Date: Tue, 24 Feb 2004 17:56:53 -0600 From: Dean Roehrich X-archive-position: 2224 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: roehrich@clink.americas.sgi.com Precedence: bulk X-list: linux-xfs Mike, Can you try this new version of the patch for fixing the invis I/O blocking? This goes on top of the last patch--or, on top of the code on oss.sgi.com. thanks Dean ---------- =========================================================================== fs/xfs/dmapi/dmapi_xfs.c =========================================================================== *** /usr/tmp/TmpDir.14847134-0/fs/xfs/dmapi/dmapi_xfs.c_1.31 Tue Feb 24 14:37:17 2004 --- fs/xfs/dmapi/dmapi_xfs.c Tue Feb 24 14:34:03 2004 *************** *** 181,188 **** if (flags & DM_FLAGS_ISEM) up(&inode->i_sem); ! #ifdef DM_FLAGS_IALLOCSEM ! else if (flags & DM_FLAGS_IALLOCSEM) up_read(&inode->i_alloc_sem); #endif --- 181,192 ---- if (flags & DM_FLAGS_ISEM) up(&inode->i_sem); ! #ifdef DM_FLAGS_IALLOCSEM_WR ! if (flags & DM_FLAGS_IALLOCSEM_WR) ! up_write(&inode->i_alloc_sem); ! #endif ! #ifdef DM_FLAGS_IALLOCSEM_RD ! if (flags & DM_FLAGS_IALLOCSEM_RD) up_read(&inode->i_alloc_sem); #endif *************** *** 191,198 **** if (flags & DM_FLAGS_ISEM) down(&inode->i_sem); ! #ifdef DM_FLAGS_IALLOCSEM ! else if (flags & DM_FLAGS_IALLOCSEM) down_read(&inode->i_alloc_sem); #endif --- 195,206 ---- if (flags & DM_FLAGS_ISEM) down(&inode->i_sem); ! #ifdef DM_FLAGS_IALLOCSEM_WR ! if (flags & DM_FLAGS_IALLOCSEM_WR) ! down_write(&inode->i_alloc_sem); ! #endif ! #ifdef DM_FLAGS_IALLOCSEM_RD ! if (flags & DM_FLAGS_IALLOCSEM_RD) down_read(&inode->i_alloc_sem); #endif =========================================================================== fs/xfs/linux-2.4/xfs_lrw.c =========================================================================== *** /usr/tmp/TmpDir.14847134-0/fs/xfs/linux-2.4/xfs_lrw.c_1.213 Tue Feb 24 14:37:17 2004 --- fs/xfs/linux-2.4/xfs_lrw.c Tue Feb 24 14:33:00 2004 *************** *** 311,317 **** !(ioflags & IO_INVIS)) { int error; vrwlock_t locktype = VRWLOCK_READ; ! int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG(ioflags); error = XFS_SEND_DATA(mp, DM_EVENT_READ, BHV_TO_VNODE(bdp), *offset, size, dmflags, &locktype); --- 311,317 ---- !(ioflags & IO_INVIS)) { int error; vrwlock_t locktype = VRWLOCK_READ; ! int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG_RD(ioflags); error = XFS_SEND_DATA(mp, DM_EVENT_READ, BHV_TO_VNODE(bdp), *offset, size, dmflags, &locktype); *************** *** 654,660 **** if ((DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS) && !eventsent)) { loff_t savedsize = *offset; ! int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG(ioflags); xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, --- 654,660 ---- if ((DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS) && !eventsent)) { loff_t savedsize = *offset; ! int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG_RD(ioflags); xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, =========================================================================== fs/xfs/linux-2.6/xfs_lrw.c =========================================================================== *** /usr/tmp/TmpDir.14847134-0/fs/xfs/linux-2.6/xfs_lrw.c_1.205 Tue Feb 24 14:37:17 2004 --- fs/xfs/linux-2.6/xfs_lrw.c Tue Feb 24 14:35:51 2004 *************** *** 739,745 **** if ((DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS) && !eventsent)) { loff_t savedsize = *offset; ! int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG(ioflags); xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, --- 739,745 ---- if ((DM_EVENT_ENABLED(vp->v_vfsp, xip, DM_EVENT_WRITE) && !(ioflags & IO_INVIS) && !eventsent)) { loff_t savedsize = *offset; ! int dmflags = FILP_DELAY_FLAG(file) | DM_SEM_FLAG_RD(ioflags); xfs_iunlock(xip, XFS_ILOCK_EXCL); error = XFS_SEND_DATA(xip->i_mount, DM_EVENT_WRITE, vp, =========================================================================== fs/xfs/xfs_dmapi.h =========================================================================== *** /usr/tmp/TmpDir.14847134-0/fs/xfs/xfs_dmapi.h_1.44 Tue Feb 24 14:37:17 2004 --- fs/xfs/xfs_dmapi.h Tue Feb 24 14:33:00 2004 *************** *** 169,175 **** #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) #if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,21) /* i_alloc_sem was added in 2.4.22-pre1 */ ! #define DM_FLAGS_IALLOCSEM 0x010 /* thread holds i_alloc_sem */ #endif #endif --- 169,176 ---- #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0) #if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,21) /* i_alloc_sem was added in 2.4.22-pre1 */ ! #define DM_FLAGS_IALLOCSEM_RD 0x010 /* thread holds i_alloc_sem rd */ ! #define DM_FLAGS_IALLOCSEM_WR 0x020 /* thread holds i_alloc_sem wr */ #endif #endif *************** *** 176,187 **** /* * Based on IO_ISDIRECT, decide which i_ flag is set. */ ! #ifdef DM_FLAGS_IALLOCSEM ! #define DM_SEM_FLAG(ioflags) (((ioflags) & IO_ISDIRECT) ? \ ! DM_FLAGS_IALLOCSEM : DM_FLAGS_ISEM) #else ! #define DM_SEM_FLAG(ioflags) (((ioflags) & IO_ISDIRECT) ? \ 0 : DM_FLAGS_ISEM) #endif /* --- 177,190 ---- /* * Based on IO_ISDIRECT, decide which i_ flag is set. */ ! #ifdef DM_FLAGS_IALLOCSEM_RD ! #define DM_SEM_FLAG_RD(ioflags) (((ioflags) & IO_ISDIRECT) ? \ ! DM_FLAGS_IALLOCSEM_RD : DM_FLAGS_ISEM) ! #define DM_SEM_FLAG_WR (DM_FLAGS_IALLOCSEM_WR | DM_FLAGS_ISEM) #else ! #define DM_SEM_FLAG_RD(ioflags) (((ioflags) & IO_ISDIRECT) ? \ 0 : DM_FLAGS_ISEM) + #define DM_SEM_FLAG_WR (DM_FLAGS_ISEM) #endif /* =========================================================================== fs/xfs/xfs_vnodeops.c =========================================================================== *** /usr/tmp/TmpDir.14847134-0/fs/xfs/xfs_vnodeops.c_1.619 Tue Feb 24 14:37:17 2004 --- fs/xfs/xfs_vnodeops.c Tue Feb 24 14:33:00 2004 *************** *** 413,420 **** } else { if (DM_EVENT_ENABLED (vp->v_vfsp, ip, DM_EVENT_TRUNCATE) && !(flags & ATTR_DMI)) { code = XFS_SEND_DATA(mp, DM_EVENT_TRUNCATE, vp, ! vap->va_size, 0, AT_DELAY_FLAG(flags), NULL); if (code) { lock_flags = 0; goto error_return; --- 413,421 ---- } else { if (DM_EVENT_ENABLED (vp->v_vfsp, ip, DM_EVENT_TRUNCATE) && !(flags & ATTR_DMI)) { + int dmflags = AT_DELAY_FLAG(flags) | DM_SEM_FLAG_WR; code = XFS_SEND_DATA(mp, DM_EVENT_TRUNCATE, vp, ! vap->va_size, 0, dmflags, NULL); if (code) { lock_flags = 0; goto error_return; From owner-linux-xfs@oss.sgi.com Tue Feb 24 16:08:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 16:08:44 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1P08eKO032188 for ; Tue, 24 Feb 2004 16:08:41 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1ONAS62013923 for ; Tue, 24 Feb 2004 15:10:28 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1P08YEk34594085; Tue, 24 Feb 2004 18:08:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1P088Eq289194; Tue, 24 Feb 2004 18:08:29 -0600 (CST) Subject: Re: kernel debugger and Infortrend and bad blocks From: Eric Sandeen To: Joe Kaiser Cc: linux-xfs@oss.sgi.com In-Reply-To: <1077665271.1051.21.camel@nietzsche.fnal.gov> References: <1077665271.1051.21.camel@nietzsche.fnal.gov> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1077667688.14465.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 24 Feb 2004 18:08:08 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2225 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Details please, what did the kernel say... xfs knows nothing about bad blocks on the disk, but it does know about I/O errors. -Eric On Tue, 2004-02-24 at 17:27, Joe Kaiser wrote: > Hi, > > I have a number of Infortrends that cause XFS to go into the kernel > debugger and unmount the XFS filesystem whenever a bad block is found on > the disk. A remount and then a dismount and an xfs_repair is then > required to fix the problem. Is there anyway to avoid this? Why is XFS > even getting bad block information from the disk? > > I am using XFS1.3.1 on 2.4.20-20.9..... > > Thanks, > > Joe -- Eric Sandeen [C]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 Feb 24 18:09:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 18:09:51 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1P29jKO007548 for ; Tue, 24 Feb 2004 18:09:45 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1P29c36013005 for ; Tue, 24 Feb 2004 20:09:39 -0600 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA03962 for ; Wed, 25 Feb 2004 13:09:36 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1P29a7a028278 for ; Wed, 25 Feb 2004 13:09:36 +1100 Received: (from nathans@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1P29Zix028276 for linux-xfs@oss.sgi.com; Wed, 25 Feb 2004 13:09:35 +1100 Date: Wed, 25 Feb 2004 13:09:35 +1100 From: Nathan Scott Message-Id: <200402250209.i1P29Zix028276@sherman.melbourne.sgi.com> Subject: TAKE 904196 - add missing 2.4 bits Apparently-To: X-archive-position: 2226 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Merge some lost 2.4 differences... not sure what happened to these. Date: Tue Feb 24 18:07:34 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: 2.4.x-xfs:linux:167434a arch/ppc/platforms/sandpoint_serial.h - 1.1 drivers/net/wan/pci200syn.c - 1.1 Documentation/i2c/i2c-velleman - 1.1 drivers/char/mpc8xx_wdt.c - 1.1 arch/ppc/platforms/sandpoint.c - 1.1 arch/ppc/platforms/prpmc750_serial.h - 1.1 arch/ppc/platforms/prpmc750.h - 1.1 arch/ppc/platforms/prpmc750.c - 1.1 arch/ppc/kernel/m8xx_wdt.c - 1.1 arch/ppc/boot/simple/clear.S - 1.1 Documentation/Configure.help - 1.10 Documentation/SubmittingDrivers - 1.3 Documentation/i2c/summary - 1.3 MAINTAINERS - 1.6 arch/ppc/boot/Makefile - 1.3 arch/ppc/boot/chrp/Makefile - 1.3 arch/ppc/boot/common/misc-simple.c - 1.3 arch/ppc/boot/pmac/Makefile - 1.3 arch/ppc/boot/simple/Makefile - 1.3 arch/ppc/boot/utils/mkprep.c - 1.3 arch/ppc/config.in - 1.5 arch/ppc/configs/IVMS8_defconfig - 1.5 arch/ppc/configs/SM850_defconfig - 1.5 arch/ppc/configs/SPD823TS_defconfig - 1.5 arch/ppc/configs/TQM823L_defconfig - 1.5 arch/ppc/configs/TQM850L_defconfig - 1.5 arch/ppc/configs/TQM860L_defconfig - 1.5 arch/ppc/configs/apus_defconfig - 1.4 arch/ppc/configs/briq_defconfig - 1.4 arch/ppc/configs/bseip_defconfig - 1.5 arch/ppc/configs/common_defconfig - 1.4 arch/ppc/configs/ebony_defconfig - 1.4 arch/ppc/configs/est8260_defconfig - 1.4 arch/ppc/configs/gemini_defconfig - 1.4 arch/ppc/configs/ibmchrp_defconfig - 1.4 arch/ppc/configs/mbx_defconfig - 1.5 arch/ppc/configs/oak_defconfig - 1.4 arch/ppc/configs/ocotea_defconfig - 1.4 arch/ppc/configs/pal4_defconfig - 1.4 arch/ppc/configs/pmac_defconfig - 1.4 arch/ppc/configs/power3_defconfig - 1.4 arch/ppc/configs/pplus_defconfig - 1.4 arch/ppc/configs/rpxcllf_defconfig - 1.5 arch/ppc/configs/rpxlite_defconfig - 1.5 arch/ppc/configs/spruce_defconfig - 1.4 arch/ppc/configs/walnut_defconfig - 1.4 arch/ppc/defconfig - 1.4 arch/ppc/kernel/Makefile - 1.3 arch/ppc/kernel/m8xx_setup.c - 1.3 arch/ppc/kernel/open_pic.c - 1.4 arch/ppc/kernel/ppc_ksyms.c - 1.3 arch/ppc/kernel/setup.c - 1.3 arch/ppc/platforms/Makefile - 1.4 arch/ppc/platforms/ebony.c - 1.3 arch/ppc/platforms/ebony.h - 1.3 arch/ppc/platforms/gemini_serial.h - 1.3 arch/ppc/platforms/ibm405gp.h - 1.3 arch/ppc/platforms/lopec_serial.h - 1.3 arch/ppc/platforms/lopec_setup.c - 1.3 arch/ppc/platforms/ocotea.c - 1.3 arch/ppc/platforms/ocotea.h - 1.3 arch/ppc/platforms/pal4_serial.h - 1.3 arch/ppc/platforms/spruce.h - 1.3 arch/ppc/platforms/spruce_setup.c - 1.3 arch/sparc64/defconfig - 1.4 arch/sparc64/kernel/pci_sabre.c - 1.3 drivers/block/cciss.c - 1.3 drivers/block/genhd.c - 1.3 drivers/char/Config.in - 1.4 drivers/char/Makefile - 1.4 drivers/i2c/Config.in - 1.4 drivers/i2c/i2c-adap-ite.c - 1.3 drivers/i2c/i2c-algo-bit.c - 1.3 drivers/i2c/i2c-algo-ite.c - 1.3 drivers/i2c/i2c-algo-pcf.c - 1.3 drivers/i2c/i2c-core.c - 1.4 drivers/i2c/i2c-dev.c - 1.3 drivers/i2c/i2c-elektor.c - 1.3 drivers/i2c/i2c-elv.c - 1.3 drivers/i2c/i2c-keywest.c - 1.3 drivers/i2c/i2c-philips-par.c - 1.4 drivers/i2c/i2c-proc.c - 1.3 drivers/i2c/i2c-velleman.c - 1.3 drivers/ide/raid/pdcraid.c - 1.3 drivers/md/lvm-snap.c - 1.3 drivers/md/lvm.c - 1.3 drivers/md/raid5.c - 1.3 drivers/media/video/Makefile - 1.4 drivers/net/tokenring/Config.in - 1.3 drivers/net/wan/Config.in - 1.4 drivers/net/wan/Makefile - 1.3 drivers/net/wan/c101.c - 1.3 drivers/net/wan/hd64572.h - 1.3 drivers/net/wan/hd6457x.c - 1.3 drivers/net/wan/hdlc_cisco.c - 1.3 drivers/net/wan/hdlc_fr.c - 1.3 drivers/net/wan/hdlc_generic.c - 1.3 drivers/net/wan/hdlc_ppp.c - 1.3 drivers/net/wan/hdlc_raw.c - 1.3 drivers/net/wan/hdlc_raw_eth.c - 1.3 drivers/net/wan/hdlc_x25.c - 1.3 drivers/net/wan/n2.c - 1.3 drivers/video/clgenfb.c - 1.3 drivers/video/hgafb.c - 1.3 fs/readdir.c - 1.4 include/net/pkt_cls.h - 1.3 mm/mmap.c - 1.3 net/core/dev.c - 1.3 net/core/neighbour.c - 1.3 net/sched/cls_api.c - 1.3 net/sched/sch_atm.c - 1.3 net/sched/sch_cbq.c - 1.3 net/sched/sch_csz.c - 1.3 net/sched/sch_dsmark.c - 1.3 net/sched/sch_htb.c - 1.3 net/sched/sch_ingress.c - 1.3 net/sched/sch_prio.c - 1.3 net/sched/sch_tbf.c - 1.3 From owner-linux-xfs@oss.sgi.com Tue Feb 24 22:30:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 22:30:22 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1P6UJKO015885 for ; Tue, 24 Feb 2004 22:30:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1P6UC36003447 for ; Wed, 25 Feb 2004 00:30:13 -0600 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 RAA07124; Wed, 25 Feb 2004 17:30:09 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1P6U78n448860; Wed, 25 Feb 2004 17:30:08 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1P6T9aY002292; Wed, 25 Feb 2004 17:29:10 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1P6T72I002290; Wed, 25 Feb 2004 17:29:07 +1100 Date: Wed, 25 Feb 2004 17:29:07 +1100 From: Nathan Scott To: Alex Wun , lord@xfs.org Cc: linux-xfs@oss.sgi.com Subject: Re: XFS Writes: IOLOCK_EXCL Message-ID: <20040225062907.GB1832@frodo> References: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> User-Agent: Mutt/1.5.3i X-archive-position: 2227 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Tue, Feb 24, 2004 at 12:20:22PM -0500, Alex Wun wrote: > Hi. hi there. > What I've been trying to do is squeeze some more write performance out of my > system. Good stuff. > I've ended up fiddling with some XFS code and have found that write > performance can improve significantly in certain applications (i.e. > exporting the filesystem over a network). I've left the system running (and Can you describe your workload there a bit more? Do you have multiple writers to the same file (from different NFS clients?)? Readers too? thanks. > writing) over the weekend and it seems to be stable. Although things look > good for now, I'd like to be certain that I haven't broken anything. > > Essentially, this is what I've done: > > In the function xfs_fsync(): > > Instead of: > > VOP_FLUSH_PAGES(...); > > I essentially have: > VOP_COMMIT_PAGES(...); > xfs_iunlock(ip, XFS_IOLOCK_EXCL); > VOP_CLEANUP_PAGES(...); > xfs_ilock(ip, XFS_IOLOCK_EXCL); > > Where VOP_COMMIT_PAGES() + VOP_CLEANUP_PAGES() does the same thing as > VOP_FLUSH_PAGES() but in two parts, first the writing of the pages then the > cleanup. So I've basically released the XFS_IOLOCK_EXCL during page > cleanup. By "cleanup" I guess you mean the filemap_fdatawait() call in fs_flush_pages? So, you're releasing the IOLOCK inbetween the initiation of IO, and the wait-for-completion of that IO. Hmm, I'll need to think about that - Steve, anything immediately obvious to you as to whether thats going to go bad? filemap_fdatawait is only processing already-locked pages, so other writers would be synchronised by the page lock. However another writer can sneak into the window created there, and do nasty things like updating the inode size or do direct IO when you weren't looking, etc. I think, not convinced yet though. What pointed out this spot in the code as a problem initially? Is this the call down from NFS where it wants to write a range within a file, but since theres no such interface it has to sync all the dirty data? Someone else was asking me if that could be improved a little while ago, but there are no VFS interfaces to provide that functionality (yet?) - XFS would be able to use that if it existed. > This may not work for everyone but it seems to give me better writing (maybe > strict operating conditions will apply?). But I'd just like to ask, from a > conceptual stand-point, whether this is a legitimate thing to do. I'm a little concerned that this may be opening a window for data corruption, but I need to think about it a whole lot. > Thanks for your time, Thanks for looking into this. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Feb 24 22:31:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Feb 2004 22:32:00 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1P6VwKO016107 for ; Tue, 24 Feb 2004 22:31:58 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1P6Vp36003729 for ; Wed, 25 Feb 2004 00:31:52 -0600 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1P6VlhI14814243; Wed, 25 Feb 2004 17:31:47 +1100 (EST) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id i1P6Vk0K15422670; Wed, 25 Feb 2004 17:31:46 +1100 (EST) Date: Wed, 25 Feb 2004 17:31:46 +1100 (EST) From: Nathan Scott Message-Id: <200402250631.i1P6Vk0K15422670@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 910030 - pagebuf X-archive-position: 2228 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@snort.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Remove PBF_SYNC buffer flag, unused for some time now. Date: Tue Feb 24 21:53:35 PST 2004 Workarea: snort.melbourne.sgi.com:/home/nathans/clean-xfs-linux The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:167442a xfsidbg.c - 1.255 linux-2.6/xfs_buf.h - 1.88 linux-2.6/xfs_buf.c - 1.152 linux-2.4/xfs_buf.h - 1.94 linux-2.4/xfs_buf.c - 1.173 From owner-linux-xfs@oss.sgi.com Wed Feb 25 02:09:19 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 02:09:39 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PA9HKO030853 for ; Wed, 25 Feb 2004 02:09:18 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i1PA9AXv001505 for ; Wed, 25 Feb 2004 21:09:10 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i1PA9A4x001499; Wed, 25 Feb 2004 21:09:10 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16444.29766.345969.596829@jdc.local> Date: Wed, 25 Feb 2004 21:09:10 +1100 To: linux-xfs Subject: XFS problem: system hang during shutdown; corruption reported by xfs_check X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2229 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Kernel: Linux jdc 2.4.24-pre1-xfs #2 Wed Dec 31 14:05:41 EST 2003 i686 (yes I know I should have upgraded. I've deleted the 2.4 tree and downloaded 2.6 but haven't tried it yet; nor have I upgraded to 2.4.25 as I was plannig to try 2.6). Symtpoms: the system hung during shutdown ("unmounting local filesystems"); there were no errors on screen or in the logs. After reboot: Feb 25 20:28:24 jdc kernel: Linux version 2.4.24-pre1-xfs (jason@jdc) (gcc version 3.3.3 20031206 (prerelease) (Debian)) #2 Wed Dec 31 14:05:41 EST 2003 Feb 25 20:28:24 jdc kernel: SGI-XFS CVS-2003-12-30_06:00_UTC with ACLs, realtime, no debug enabled Feb 25 20:28:24 jdc kernel: XFS mounting filesystem ide0(3,5) Feb 25 20:28:24 jdc kernel: Starting XFS recovery on filesystem: ide0(3,5) (dev: ide0(3,5)) Feb 25 20:28:24 jdc kernel: Ending XFS recovery on filesystem: ide0(3,5) (dev: ide0(3,5)) Feb 25 20:28:24 jdc kernel: VFS: Mounted root (xfs filesystem) readonly. I then started the machine from another partition that has a very old Linux installation on it (an ancient XFS kernel), copied over the xfs_check program from the main filesystem, unmounted it and ran xfs_check, with the following output: xfs_check /dev/hda5 agi unlinked bucket 42 is 60330 in ag 18 (inode=75557802) allocated inode 75557802 has 0 link count I was able to boot the system normally, but obviously I am worried about these events and want to take all prudent steps to preserve the data on the filesystem and correct whatever the problem is. The only other bootable medium I have is the partition with an extremely old kernel on it, from which I can run xfs utilities (copied across if necessary). This filesystem has been running well since the end of 2001. Please let me know if there are any further tests you would like completed, or additional information that would help identify the cause. Hardware details (for reference, from lspci): 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:05.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 00:0d.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 0c) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. USB (rev 1b) 00:11.3 USB Controller: VIA Technologies, Inc. USB (rev 1b) 00:11.4 USB Controller: VIA Technologies, Inc. USB (rev 1b) 01:00.0 VGA compatible controller: nVidia Corporation NV11DDR [GeForce2 MX 100 DDR/200 DDR] (rev b2) With thanks and regards, Jason. From owner-linux-xfs@oss.sgi.com Wed Feb 25 02:51:16 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 02:51:18 -0800 (PST) Received: from w1301.hostcentric.net (w1301.hostcentric.net [209.25.197.254]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PApFKO001470 for ; Wed, 25 Feb 2004 02:51:16 -0800 Received: (qmail 12100 invoked by alias); 25 Feb 2004 10:51:13 -0000 Received: from unknown (HELO colorfront.com) (195.228.226.66) by 0 with SMTP; 25 Feb 2004 10:51:13 -0000 Message-ID: <403CFB75.8050501@colorfront.com> Date: Wed, 25 Feb 2004 11:45:57 -0800 From: Bela Babik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Green CC: linux-xfs@oss.sgi.com Subject: Re: XFS patched RHELv3 kernels now available - please test References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2230 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bela@colorfront.com Precedence: bulk X-list: linux-xfs Hi, thanks for the answer. > The module needs to be recompiled on your machine with the kernel source > being properly configured (make dep after initializing the config). It's > possible that when you re-installed the NVidia module, the NVidia package > found a close-match (but incorrect) binary on its FTP site and that's why > you're hanging. You need to give the -n (I think) switch to the .run > script to prevent it downloading a binary module and force it to compile > its own. You may need to play with the options but you'll get there > eventually. I have a configured kernel and i have skipped the precompiled serch step in the installation. The server starts, and the NVidia logo appears and then hangup. The newer drivers are a bit better, because it begin to load the desktop and hangup befire it can finish. Bela From owner-linux-xfs@oss.sgi.com Wed Feb 25 03:25:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 03:25:32 -0800 (PST) Received: from odin.sv.fintec.co.cr ([168.243.202.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PBPGKO004495 for ; Wed, 25 Feb 2004 03:25:17 -0800 Received: from odin.fintec.co.cr ([192.168.201.229]) by odin.sv.fintec.co.cr (8.12.10/8.12.10) with ESMTP id i1PBPFp6013359 for ; Wed, 25 Feb 2004 05:25:16 -0600 Message-ID: <403C8619.2040906@odin.fintec.co.cr> Date: Wed, 25 Feb 2004 05:25:13 -0600 From: Ivan Kocher Organization: Fintec SA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Problem with XFS and JFS References: <403A3366.3070809@odin.fintec.co.cr> <1077557148.4497.1.camel@naboo.americas.sgi.com> <403A790F.7060100@odin.fintec.co.cr> <1077575947.7791.88.camel@stout.americas.sgi.com> In-Reply-To: <1077575947.7791.88.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2231 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ikocher@odin.fintec.co.cr Precedence: bulk X-list: linux-xfs By now I can't do that ... I run jfs_fsck on the partition, and that removed the problem... I hope it doesn't bite me again. I will try to reproduce the bug next week, by now I must set this units in production, and can make more test on this matter. I am still wondering what went wrong. I _like_ xfs, is has proven to me that it really delivers, but well under certain conditions I went for jfs ... :( Ivan -------- Eric Sandeen wrote: >It does not make sense that xfs would be trying to replay a log from a >partition which has been zeroed, then mkfs.jfs'd - there should be no >xfs superblock magic left, and xfs should not try to do anything. > >What do you get from: > >dd if=/dev/your/device bs=1 count=4 | strings > >if you see "XFSB" in the output, then you still have an xfs superblock. > >-Eric > >p.s. actually you have stumbled upon our plan for global domination, >once you have formatted with mkfs.xfs your drive is xfs forever. ;-) > > > From owner-linux-xfs@oss.sgi.com Wed Feb 25 06:51:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 06:52:04 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PEpbKO022681 for ; Wed, 25 Feb 2004 06:51:38 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.24) id 1Aw0Nm-0006XY-OP; Wed, 25 Feb 2004 14:51:30 +0000 Message-ID: <403CB672.88ABDDF8@moving-picture.com> Date: Wed, 25 Feb 2004 14:51:30 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: Joe Kaiser CC: linux-xfs@oss.sgi.com Subject: Re: kernel debugger and Infortrend and bad blocks References: <1077665271.1051.21.camel@nietzsche.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 2232 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs We had a look an Infortrend array (SATA internally, SCSI externally) and had a lot of problems - it looked like problems in the array 'leaked' through to the host - e.g. a failed disk caused the external SCSI bus to reset etc. Internal problems like this with the raid disks should be handled by the raid controller - the host should be unaware of these problems. Because of these problems, we rejected the Infortrend ... James Pearson Joe Kaiser wrote: > > Hi, > > I have a number of Infortrends that cause XFS to go into the kernel > debugger and unmount the XFS filesystem whenever a bad block is found on > the disk. A remount and then a dismount and an xfs_repair is then > required to fix the problem. Is there anyway to avoid this? Why is XFS > even getting bad block information from the disk? > > I am using XFS1.3.1 on 2.4.20-20.9..... > > Thanks, > > Joe > > -- > =================================================================== > Joe Kaiser - Systems Administrator > > Fermi Lab > CD/OSS-SCS Never laugh at live dragons. > 630-840-6444 > jlkaiser@fnal.gov > =================================================================== From owner-linux-xfs@oss.sgi.com Wed Feb 25 07:29:39 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 07:29:43 -0800 (PST) Received: from c.pexit.com ([216.187.68.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PFTcKO025012 for ; Wed, 25 Feb 2004 07:29:39 -0800 Received: from consensyxdlcmm (CPE0002b38c3dc3-CM000a73663c85.cpe.net.cable.rogers.com [63.139.199.14]) by c.pexit.com (8.11.6/8.11.6) with SMTP id i1NFTas06356 for ; Mon, 23 Feb 2004 10:29:36 -0500 Message-ID: <018a01c3fa21$dae5bda0$9002a8c0@consensys.com> From: "Alex Wun" To: References: Subject: XFS Writes: IOLOCK_EXCL Date: Mon, 23 Feb 2004 10:29:40 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1377 X-archive-position: 2233 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexwun@consensys.com Precedence: bulk X-list: linux-xfs Hi. What I've been trying to do is squeeze some more write performance out of my system. (Dual Pentium Xeon processors, 1GB ram, software RAID, 2.4.20 kernel patched with XFS 1.3.1) I've ended up fiddling with some XFS code and have found that write performance can improve significantly in certain applications (i.e. exporting the filesystem over a network). I've left the system running (and writing) over the weekend and it seems to be stable. Although things look good for now, I'd like to be certain that I haven't broken anything. Essentially, this is what I've done: In the function xfs_fsync(): Instead of: VOP_FLUSH_PAGES(...); I essentially have: VOP_COMMIT_PAGES(...); xfs_iunlock(ip, XFS_IOLOCK_EXCL); VOP_CLEANUP_PAGES(...); xfs_ilock(ip, XFS_IOLOCK_EXCL); Where VOP_COMMIT_PAGES() + VOP_CLEANUP_PAGES() does the same thing as VOP_FLUSH_PAGES() but in two parts, first the writing of the pages then the cleanup. So I've basically released the XFS_IOLOCK_EXCL during page cleanup. This may not work for everyone but it seems to give me better writing (maybe strict operating conditions will apply?). But I'd just like to ask, from a conceptual stand-point, whether this is a legitimate thing to do. Thanks for your time, Alex Wun [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Feb 25 07:58:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 07:59:02 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PFwqKO025893 for ; Wed, 25 Feb 2004 07:58:53 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1PEtU62016587 for ; Wed, 25 Feb 2004 06:55:30 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1PFrWnO34605310; Wed, 25 Feb 2004 09:53:32 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1PFrHEr356394; Wed, 25 Feb 2004 09:53:27 -0600 (CST) Date: Wed, 25 Feb 2004 09:53:17 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jason White cc: linux-xfs Subject: Re: XFS problem: system hang during shutdown; corruption reported by xfs_check In-Reply-To: <16444.29766.345969.596829@jdc.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs It looks like the filesystem is not in bad shape; ideally make sure it's been cleanly unmounted, then point a recent xfs_repair at it. Running that under an old kernel should not be a problem. It's not clear why the umount hung, but there's probably no way to debug that problem right now. -Eric On Wed, 25 Feb 2004, Jason White wrote: > Kernel: > Linux jdc 2.4.24-pre1-xfs #2 Wed Dec 31 14:05:41 EST 2003 i686 > (yes I know I should have upgraded. I've deleted the 2.4 tree and > downloaded 2.6 but haven't tried it yet; nor have I upgraded to > 2.4.25 as I was plannig to try 2.6). > > Symtpoms: the system hung during shutdown ("unmounting local > filesystems"); there were no errors on screen or in the logs. > After reboot: > From owner-linux-xfs@oss.sgi.com Wed Feb 25 07:58:46 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 07:59:02 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PFwkKO025888 for ; Wed, 25 Feb 2004 07:58:46 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1PEx362017276 for ; Wed, 25 Feb 2004 06:59:03 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1PFv7nO34542450; Wed, 25 Feb 2004 09:57:07 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1PFugEr358570; Wed, 25 Feb 2004 09:56:52 -0600 (CST) Date: Wed, 25 Feb 2004 09:56:42 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Bela Babik cc: Chris Green , Subject: Re: XFS patched RHELv3 kernels now available - please test In-Reply-To: <403CFB75.8050501@colorfront.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2234 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I would suggest submitting this to the bugs list at nvidia, along with pointers to where they can get the kernel & the source. For obvious reasons we cannot debug it. They may be interested in the datapoint, though - I've seen someone else with an RH9-based sgi-modified kernel where the nvidia module oopses the box consistently, although stock RH9 appears ok. *shrug* - we just added devfs, kdb, and VFS stuff for xfs.... -eric On Wed, 25 Feb 2004, Bela Babik wrote: > Hi, > > thanks for the answer. > > The module needs to be recompiled on your machine with the kernel source > > being properly configured (make dep after initializing the config). It's > > possible that when you re-installed the NVidia module, the NVidia package > > found a close-match (but incorrect) binary on its FTP site and that's why > > you're hanging. You need to give the -n (I think) switch to the .run > > script to prevent it downloading a binary module and force it to compile > > its own. You may need to play with the options but you'll get there > > eventually. > I have a configured kernel and i have skipped the precompiled serch step > in the installation. > > The server starts, and the NVidia logo appears and then hangup. > The newer drivers are a bit better, because it begin to load > the desktop and hangup befire it can finish. > > Bela > > From owner-linux-xfs@oss.sgi.com Wed Feb 25 08:17:32 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 08:17:37 -0800 (PST) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PGHVKO027107 for ; Wed, 25 Feb 2004 08:17:31 -0800 Received: from localhost (localhost [127.0.0.1]) by baikonur.stro.at (Postfix) with ESMTP id 732165C045 for ; Wed, 25 Feb 2004 17:17:28 +0100 (CET) Received: from baikonur.stro.at ([127.0.0.1]) by localhost (baikonur [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32067-08 for ; Wed, 25 Feb 2004 17:17:28 +0100 (CET) Received: from aibuk.worstofall.com (chello062178011226.4.11.wu-wien.teleweb.at [62.178.11.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aibuk.worstofall.com", Issuer "stro.at" (verified OK)) by baikonur.stro.at (Postfix) with ESMTP id C063A5C009 for ; Wed, 25 Feb 2004 17:17:27 +0100 (CET) Received: by aibuk.worstofall.com (Postfix, from userid 1000) id 6BF3557598; Wed, 25 Feb 2004 17:17:28 +0100 (CET) Date: Wed, 25 Feb 2004 17:17:28 +0100 From: Klaus Ita To: linux-xfs@oss.sgi.com Subject: oops today with 2.4.25 Message-ID: <20040225161728.GA816@aibuk.worstofall.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by amavadisd-new (ClamAV) at stro.at X-archive-position: 2235 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: avk@worstofall.com Precedence: bulk X-list: linux-xfs --hQiwHBbRI9kgIhsi Content-Type: multipart/mixed; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi all! had an oops today. somehow linked to the xfs/vfs. is this known, or am i alone with this problem? regs --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="result.oops" Content-Transfer-Encoding: quoted-printable ksymoops 2.4.5 on i686 2.4.25-20040218. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.25-20040218/ (default) -m /boot/System.map-2.4.25-20040218 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. No modules in ksyms, skipping objects Warning (read_lsmod): no symbols in lsmod, is /proc/modules a valid lsmod f= ile? Feb 25 10:11:10 target kernel: Unable to handle kernel NULL pointer derefer= ence at virtual address 00000000 Feb 25 10:11:10 target kernel: c011532b Feb 25 10:11:10 target kernel: *pde =3D 00000000 Feb 25 10:11:10 target kernel: Oops: 0000 Feb 25 10:11:10 target kernel: CPU: 0 Feb 25 10:11:10 target kernel: EIP: 0010:[__wake_up+27/112] Not taint= ed Feb 25 10:11:10 target kernel: EFLAGS: 00010082 Feb 25 10:11:10 target kernel: eax: efc0a1c8 ebx: 00000000 ecx: 0000000= 1 edx: 00000003 Feb 25 10:11:10 target kernel: esi: efc0a1c8 edi: 00000003 ebp: da62dc8= 0 esp: da62dc64 Feb 25 10:11:10 target kernel: ds: 0018 es: 0018 ss: 0018 Feb 25 10:11:10 target kernel: Process postmaster (pid: 7509, stackpage=3Dd= a62d000) Feb 25 10:11:10 target kernel: Stack: 00000000 000001a3 00000001 00000082 0= 0000296 ec36c750 00001da5 00002f37=20 Feb 25 10:11:10 target kernel: c0107ab7 efc0a100 c0107adb efc0a1c0 e= fc0a100 c01d095e c01d5e40 efc0a100=20 Feb 25 10:11:10 target kernel: 00000008 ec36c750 f7661000 c01e9afa e= c36c750 00002f37 00001da5 00002f37=20 Feb 25 10:11:10 target kernel: Call Trace: [__down_trylock+55/60] [__dow= n_failed_trylock+7/12] [.text.lock.xfs_iget+75/109] [xfs_inode_item_trylock= +80/176] [xfs_trans_push_ail+138/368] Feb 25 10:11:10 target kernel: Code: 8b 13 0f 0d 02 39 c3 74 16 8b 4b fc 8b= 01 85 c7 75 19 8b 02=20 Using defaults from ksymoops -t elf32-i386 -a i386 >>eax; efc0a1c8 >>esi; efc0a1c8 >>ebp; da62dc80 >>esp; da62dc64 Code; 00000000 Before first symbol 00000000 <_EIP>: Code; 00000000 Before first symbol 0: 8b 13 mov (%ebx),%edx Code; 00000002 Before first symbol 2: 0f 0d 02 prefetch (%edx) Code; 00000005 Before first symbol 5: 39 c3 cmp %eax,%ebx Code; 00000007 Before first symbol 7: 74 16 je 1f <_EIP+0x1f> 0000001f Before fir= st symbol Code; 00000009 Before first symbol 9: 8b 4b fc mov 0xfffffffc(%ebx),%ecx Code; 0000000c Before first symbol c: 8b 01 mov (%ecx),%eax Code; 0000000e Before first symbol e: 85 c7 test %eax,%edi Code; 00000010 Before first symbol 10: 75 19 jne 2b <_EIP+0x2b> 0000002b Before fir= st symbol Code; 00000012 Before first symbol 12: 8b 02 mov (%edx),%eax Feb 25 10:11:12 target kernel: <1>Unable to handle kernel NULL pointer der= eference at virtual address 00000000 Feb 25 10:11:12 target kernel: c011532b Feb 25 10:11:12 target kernel: *pde =3D 00000000 Feb 25 10:11:12 target kernel: Oops: 0000 Feb 25 10:11:12 target kernel: CPU: 0 Feb 25 10:11:12 target kernel: EIP: 0010:[__wake_up+27/112] Not taint= ed Feb 25 10:11:12 target kernel: EFLAGS: 00010082 Feb 25 10:11:12 target kernel: eax: efc0a1c8 ebx: 00000000 ecx: 0000000= 1 edx: 00000003 Feb 25 10:11:12 target kernel: esi: efc0a1c8 edi: 00000003 ebp: f0713bb= 4 esp: f0713b98 Warning (Oops_read): Code line not seen, dumping what data is available >>eax; efc0a1c8 >>esi; efc0a1c8 >>ebp; f0713bb4 >>esp; f0713b98 Feb 25 11:36:59 target kernel: SGI XFS with no debug enabled Feb 25 11:36:59 target kernel: 8139too Fast Ethernet driver 0.9.26 3 warnings issued. Results may not be reliable. --rwEMma7ioTxnRzrJ-- --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAPMqYzu1rXjOPidIRAstyAJ9qyxny7AWU+d7MFDkeuhArlRI2AQCfYV8o S7wn1me/FWEUum0zOxXZq/Q= =5s45 -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-linux-xfs@oss.sgi.com Wed Feb 25 08:40:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 08:40:29 -0800 (PST) Received: from woozle.fnal.gov (woozle.fnal.gov [131.225.9.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1PGeOKO030894 for ; Wed, 25 Feb 2004 08:40:25 -0800 Received: from conversion-daemon.woozle.fnal.gov by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) id <0HTN00E01FMMQK@woozle.fnal.gov> for linux-xfs@oss.sgi.com; Wed, 25 Feb 2004 10:40:24 -0600 (CST) Received: from nietzsche.fnal.gov (nietzsche.fnal.gov [131.225.80.76]) by woozle.fnal.gov (iPlanet Messaging Server 5.2 HotFix 1.10 (built Jan 23 2003)) with ESMTP id <0HTN006YMFNCV6@woozle.fnal.gov>; Wed, 25 Feb 2004 10:40:24 -0600 (CST) Date: Wed, 25 Feb 2004 10:40:25 -0600 From: Joe Kaiser Subject: Re: kernel debugger and Infortrend and bad blocks In-reply-to: <1077667688.14465.22.camel@stout.americas.sgi.com> To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Message-id: <1077727224.3041.12.camel@nietzsche.fnal.gov> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1077665271.1051.21.camel@nietzsche.fnal.gov> <1077667688.14465.22.camel@stout.americas.sgi.com> X-archive-position: 2236 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jlkaiser@fnal.gov Precedence: bulk X-list: linux-xfs This is what I got on boot up: Mounting local filesystems: Entering kdb (current=0xc03a6000, pid 0) on processor 0 due to NonMaskable Interrupt @ 0xc0107098 eax = 0x00000000 ebx = 0xc0107070 ecx = 0x00000000 edx = 0xc03a6000 esi = 0xc03a6000 edi = 0xc03a6000 esp = 0xc03a7fc0 eip = 0xc0107098 ebp = 0xc0107070 xss = 0xc0270068 xcs = 0x00000060 eflags = 0x00000246 xds = 0x00000068 xes = 0xf7fe0068 origeax = 0x00000000 ®s = 0xc03a7f8c [0]kdb> Catastrophic error detected kdb_continue_catastrophic=1, attempting to continue Thanks, Joe On Tue, 2004-02-24 at 18:08, Eric Sandeen wrote: > Details please, what did the kernel say... xfs knows nothing about bad > blocks on the disk, but it does know about I/O errors. > > -Eric > > On Tue, 2004-02-24 at 17:27, Joe Kaiser wrote: > > Hi, > > > > I have a number of Infortrends that cause XFS to go into the kernel > > debugger and unmount the XFS filesystem whenever a bad block is found on > > the disk. A remount and then a dismount and an xfs_repair is then > > required to fix the problem. Is there anyway to avoid this? Why is XFS > > even getting bad block information from the disk? > > > > I am using XFS1.3.1 on 2.4.20-20.9..... > > > > Thanks, > > > > Joe -- =================================================================== Joe Kaiser - Systems Administrator Fermi Lab CD/OSS-SCS Never laugh at live dragons. 630-840-6444 jlkaiser@fnal.gov =================================================================== From owner-linux-xfs@oss.sgi.com Wed Feb 25 16:05:41 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 16:06:04 -0800 (PST) Received: from jdc.local (dyn172.mel2.homedsl.pacific.net.au [203.100.245.172]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1Q05dKO016826 for ; Wed, 25 Feb 2004 16:05:40 -0800 Received: from jdc.local (localhost [127.0.0.1]) by jdc.local (8.12.11/8.12.11/Debian-1) with ESMTP id i1Q05WKA001502; Thu, 26 Feb 2004 11:05:32 +1100 Received: (from jason@localhost) by jdc.local (8.12.11/8.12.11/Debian-1) id i1Q05WAZ001495; Thu, 26 Feb 2004 11:05:32 +1100 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16445.14412.723115.815734@jdc.local> Date: Thu, 26 Feb 2004 11:05:32 +1100 To: Eric Sandeen Cc: linux-xfs Subject: Re: XFS problem: system hang during shutdown; corruption reported by xfs_check In-Reply-To: References: <16444.29766.345969.596829@jdc.local> X-Mailer: VM 7.18 under Emacs 21.3.1 Reply-To: jasonw@ariel.ucs.unimelb.edu.au X-archive-position: 2237 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jasonw@ariel.ucs.unimelb.edu.au Precedence: bulk X-list: linux-xfs Eric Sandeen writes: > It looks like the filesystem is not in bad shape; > ideally make sure it's been cleanly unmounted, then > point a recent xfs_repair at it. Running that > under an old kernel should not be a problem. Thanks. Repair fixed the disconnected inode, and that was it (the file in /lost+found turned out to be empty). Is there any test you would like to be run if the system hangs again durning unmount? I expect to upgrade tis kernel before too long. Thank you once again for the help. Jason. Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 75557802, moving to lost+found Phase 7 - verify and correct link counts... done From owner-linux-xfs@oss.sgi.com Wed Feb 25 16:33:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 16:33:30 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1Q0XHKO020632 for ; Wed, 25 Feb 2004 16:33:17 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1Q0XCF6021560 for ; Wed, 25 Feb 2004 16:33:12 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1Q0XBj334618593; Wed, 25 Feb 2004 18:33:11 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1Q0WtEr409212; Wed, 25 Feb 2004 18:33:05 -0600 (CST) Date: Wed, 25 Feb 2004 18:32:55 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jason White cc: linux-xfs Subject: Re: XFS problem: system hang during shutdown; corruption reported by xfs_check In-Reply-To: <16445.14412.723115.815734@jdc.local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2238 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs On Thu, 26 Feb 2004, Jason White wrote: > Eric Sandeen writes: > > It looks like the filesystem is not in bad shape; > > ideally make sure it's been cleanly unmounted, then > > point a recent xfs_repair at it. Running that > > under an old kernel should not be a problem. > > Thanks. > Repair fixed the disconnected inode, and that was it (the file in > /lost+found turned out to be empty). > > Is there any test you would like to be run if the system hangs again > durning unmount? I expect to upgrade tis kernel before too long. if you have kdb in place, enter kdb and backtrace the hung process, that would be a hint. kdb> ps kdb> btp If no kdb, sysrq-t should dump all task info as well. > Thank you once again for the help. > Jason. No problem! -eric From owner-linux-xfs@oss.sgi.com Wed Feb 25 20:07:30 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 20:07:44 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1Q47UKO024835 for ; Wed, 25 Feb 2004 20:07:30 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1Q39HO9014452 for ; Wed, 25 Feb 2004 19:09:21 -0800 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 PAA24426; Thu, 26 Feb 2004 15:07:19 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1Q47H8n475358; Thu, 26 Feb 2004 15:07:17 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1Q47EgO015717; Thu, 26 Feb 2004 15:07:14 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1Q46qNv015715; Thu, 26 Feb 2004 15:06:52 +1100 Date: Thu, 26 Feb 2004 15:06:52 +1100 From: Nathan Scott To: Steve Lord Cc: Alex Wun , linux-xfs@oss.sgi.com Subject: Re: XFS Writes: IOLOCK_EXCL Message-ID: <20040226040651.GC1177@frodo> References: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> <20040225062907.GB1832@frodo> <403CAA00.20502@xfs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403CAA00.20502@xfs.org> User-Agent: Mutt/1.5.3i X-archive-position: 2239 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Thanks Steve. On Wed, Feb 25, 2004 at 07:58:24AM -0600, Steve Lord wrote: > > Only speaking for 2.6 here, so take that under advisement. After an audit, this seems to be valid for both 2.4 and 2.6. > There are very few callers of fsync in the kernel, and they all do the > data flush and wait for data themselves, the filesystem fsync code is > not involved in the data flush at all for most filesystems, just the > metadata for the file. The callers hold the i_sem, but not the nfs > commit case. Mmmm? seems to me that i_sem is also held for nfs commit, both in 2.4 and 2.6 (nfsd_commit -> nfsd_sync -> down(i_sem) -> nfsd_dosync -> fop->fsync). > As for flushing data without the IO lock, I think this is OK in general, > if a new read comes along there is no problem, if a new write modifies > the page then it will get redirtied and flushed again later. If a > truncate removes the page then it will delete the page before after > it is flushed. The holding of the IO lock is partially a hold over > from Irix where it is required around the VOP_FLUSH..... calls. Yep, OK, thanks. > The tosspages and flushinval pages cases do need the lock though. > > This is untested, but should generally speed things up in 2.6. A very > quick scan of 2.4 seems to suggest a similar change will work there > too. I think its always valid to do this (after auditing the callers), but doesn't seem to do "general speedup" - the "usual suspects" benchmarks don't show any improvements anyway. Alex, what was your workload? (you didn't get back to me yet). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Feb 25 20:49:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 20:49:03 -0800 (PST) Received: from relay04.roc.ny.frontiernet.net (relay04.roc.ny.frontiernet.net [66.133.131.37]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1Q4mxKO028821 for ; Wed, 25 Feb 2004 20:48:59 -0800 Received: (qmail 7093 invoked from network); 25 Feb 2004 13:59:38 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay04.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 25 Feb 2004 13:59:38 -0000 Message-ID: <403CAA00.20502@xfs.org> Date: Wed, 25 Feb 2004 07:58:24 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Alex Wun , linux-xfs@oss.sgi.com Subject: Re: XFS Writes: IOLOCK_EXCL References: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> <20040225062907.GB1832@frodo> In-Reply-To: <20040225062907.GB1832@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2240 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > On Tue, Feb 24, 2004 at 12:20:22PM -0500, Alex Wun wrote: > >>Hi. > > > hi there. > > >>What I've been trying to do is squeeze some more write performance out of my >>system. > > > Good stuff. > > >>I've ended up fiddling with some XFS code and have found that write >>performance can improve significantly in certain applications (i.e. >>exporting the filesystem over a network). I've left the system running (and > > > Can you describe your workload there a bit more? Do you have > multiple writers to the same file (from different NFS clients?)? > Readers too? thanks. > > >>writing) over the weekend and it seems to be stable. Although things look >>good for now, I'd like to be certain that I haven't broken anything. >> >>Essentially, this is what I've done: >> >>In the function xfs_fsync(): >> >>Instead of: >> >> VOP_FLUSH_PAGES(...); >> >>I essentially have: >> VOP_COMMIT_PAGES(...); >> xfs_iunlock(ip, XFS_IOLOCK_EXCL); >> VOP_CLEANUP_PAGES(...); >> xfs_ilock(ip, XFS_IOLOCK_EXCL); >> >>Where VOP_COMMIT_PAGES() + VOP_CLEANUP_PAGES() does the same thing as >>VOP_FLUSH_PAGES() but in two parts, first the writing of the pages then the >>cleanup. So I've basically released the XFS_IOLOCK_EXCL during page >>cleanup. > > > By "cleanup" I guess you mean the filemap_fdatawait() call in > fs_flush_pages? So, you're releasing the IOLOCK inbetween the > initiation of IO, and the wait-for-completion of that IO. Hmm, > I'll need to think about that - Steve, anything immediately > obvious to you as to whether thats going to go bad? > > filemap_fdatawait is only processing already-locked pages, so > other writers would be synchronised by the page lock. However > another writer can sneak into the window created there, and do > nasty things like updating the inode size or do direct IO when > you weren't looking, etc. I think, not convinced yet though. > > What pointed out this spot in the code as a problem initially? > Is this the call down from NFS where it wants to write a range > within a file, but since theres no such interface it has to sync > all the dirty data? Someone else was asking me if that could > be improved a little while ago, but there are no VFS interfaces > to provide that functionality (yet?) - XFS would be able to use > that if it existed. > > >>This may not work for everyone but it seems to give me better writing (maybe >>strict operating conditions will apply?). But I'd just like to ask, from a >>conceptual stand-point, whether this is a legitimate thing to do. > > > I'm a little concerned that this may be opening a window for > data corruption, but I need to think about it a whole lot. > > >>Thanks for your time, > > > Thanks for looking into this. > > cheers. > Only speaking for 2.6 here, so take that under advisement. There are very few callers of fsync in the kernel, and they all do the data flush and wait for data themselves, the filesystem fsync code is not involved in the data flush at all for most filesystems, just the metadata for the file. The callers hold the i_sem, but not the nfs commit case. So, in 2.6, xfs_fsync needs gutting, the VOP_FLUSH_PAGES call can go completely. Since FSYNC_INVAL is not used (at least not in the kernel tree code, Nathan you know where to look), the VOP_FLUSHINVAL_PAGES could go to, and with it all the code associated with the iolock. As for flushing data without the IO lock, I think this is OK in general, if a new read comes along there is no problem, if a new write modifies the page then it will get redirtied and flushed again later. If a truncate removes the page then it will delete the page before after it is flushed. The holding of the IO lock is partially a hold over from Irix where it is required around the VOP_FLUSH..... calls. The tosspages and flushinval pages cases do need the lock though. This is untested, but should generally speed things up in 2.6. A very quick scan of 2.4 seems to suggest a similar change will work there too. Steve STATIC int xfs_fsync( bhv_desc_t *bdp, int flag, cred_t *credp, xfs_off_t start, xfs_off_t stop) { xfs_inode_t *ip; int error; xfs_trans_t *tp; vn_trace_entry(BHV_TO_VNODE(bdp), __FUNCTION__, (inst_t *) __return_address); ip = XFS_BHVTOI(bdp); ASSERT(start >= 0 && stop >= -1); if (XFS_FORCED_SHUTDOWN(ip->i_mount)) return XFS_ERROR(EIO); xfs_ilock(ip, XFS_IOLOCK_EXCL); /* * We always need to make sure that the required inode state * is safe on disk. The vnode might be clean but because * of committed transactions that haven't hit the disk yet. * Likewise, there could be unflushed non-transactional * changes to the inode core that have to go to disk. * * The following code depends on one assumption: that * any transaction that changes an inode logs the core * because it has to change some field in the inode core * (typically nextents or nblocks). That assumption * implies that any transactions against an inode will * catch any non-transactional updates. If inode-altering * transactions exist that violate this assumption, the * code breaks. Right now, it figures that if the involved * update_* field is clear and the inode is unpinned, the * inode is clean. Either it's been flushed or it's been * committed and the commit has hit the disk unpinning the inode. * (Note that xfs_inode_item_format() called at commit clears * the update_* fields.) */ xfs_ilock(ip, XFS_ILOCK_SHARED); /* If we are flushing data then we care about update_size * being set, otherwise we care about update_core */ if ((flag & FSYNC_DATA) ? (ip->i_update_size == 0) : (ip->i_update_core == 0)) { /* * Timestamps/size haven't changed since last inode * flush or inode transaction commit. That means * either nothing got written or a transaction * committed which caught the updates. If the * latter happened and the transaction hasn't * hit the disk yet, the inode will be still * be pinned. If it is, force the log. */ xfs_iunlock(ip, XFS_ILOCK_SHARED); if (xfs_ipincount(ip)) { xfs_log_force(ip->i_mount, (xfs_lsn_t)0, XFS_LOG_FORCE | ((flag & FSYNC_WAIT) ? XFS_LOG_SYNC : 0)); } error = 0; } else { /* * Kick off a transaction to log the inode * core to get the updates. Make it * sync if FSYNC_WAIT is passed in (which * is done by everybody but specfs). The * sync transaction will also force the log. */ xfs_iunlock(ip, XFS_ILOCK_SHARED); tp = xfs_trans_alloc(ip->i_mount, XFS_TRANS_FSYNC_TS); if ((error = xfs_trans_reserve(tp, 0, XFS_FSYNC_TS_LOG_RES(ip->i_mount), 0, 0, 0))) { xfs_trans_cancel(tp, 0); return error; } xfs_ilock(ip, XFS_ILOCK_EXCL); /* * Note - it's possible that we might have pushed * ourselves out of the way during trans_reserve * which would flush the inode. But there's no * guarantee that the inode buffer has actually * gone out yet (it's delwri). Plus the buffer * could be pinned anyway if it's part of an * inode in another recent transaction. So we * play it safe and fire off the transaction anyway. */ xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); xfs_trans_ihold(tp, ip); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); if (flag & FSYNC_WAIT) xfs_trans_set_sync(tp); error = xfs_trans_commit(tp, 0, NULL); xfs_iunlock(ip, XFS_ILOCK_EXCL); } return error; } From owner-linux-xfs@oss.sgi.com Wed Feb 25 21:54:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 25 Feb 2004 21:54:32 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1Q5sGKO031657 for ; Wed, 25 Feb 2004 21:54:17 -0800 Received: from bruce.melbourne.sgi.com (bruce.melbourne.sgi.com [134.14.54.176]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1Q4u7O9000365 for ; Wed, 25 Feb 2004 20:56:08 -0800 Received: from bruce.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by bruce.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1Q5s1sF010058; Thu, 26 Feb 2004 16:54:01 +1100 Received: (from fsgqa@localhost) by bruce.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1Q5s0tR010057; Thu, 26 Feb 2004 16:54:00 +1100 Date: Thu, 26 Feb 2004 16:54:00 +1100 From: FSG QA Message-Id: <200402260554.i1Q5s0tR010057@bruce.melbourne.sgi.com> Subject: TAKE 909327 - fix xfsdump build X-archive-position: 2241 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: fsgqa@bruce.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Whoops, missed a comment close delimiter in that last fix. - nathans Date: Wed Feb 25 21:50:21 PST 2004 Workarea: bruce.melbourne.sgi.com:/home/fsgqa/qa/xfs-cmds Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:167508a xfsdump/dump/content.c - 1.29 From owner-linux-xfs@oss.sgi.com Thu Feb 26 05:28:15 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 05:28:29 -0800 (PST) Received: from relay03.roc.ny.frontiernet.net (relay03.roc.ny.frontiernet.net [66.133.131.36]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QDSEKO025935 for ; Thu, 26 Feb 2004 05:28:15 -0800 Received: (qmail 26245 invoked from network); 26 Feb 2004 13:28:14 -0000 Received: from unknown (HELO xfs.org) ([208.186.10.249]) (envelope-sender ) by relay03.roc.ny.frontiernet.net (FrontierMTA 2.3.6) with SMTP for ; 26 Feb 2004 13:28:14 -0000 Message-ID: <403DF426.1040705@xfs.org> Date: Thu, 26 Feb 2004 07:27:02 -0600 From: Steve Lord User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Alex Wun , linux-xfs@oss.sgi.com Subject: Re: XFS Writes: IOLOCK_EXCL References: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> <20040225062907.GB1832@frodo> <403CAA00.20502@xfs.org> <20040226040651.GC1177@frodo> In-Reply-To: <20040226040651.GC1177@frodo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2242 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: lord@xfs.org Precedence: bulk X-list: linux-xfs Nathan Scott wrote: > > I think its always valid to do this (after auditing the callers), > but doesn't seem to do "general speedup" - the "usual suspects" > benchmarks don't show any improvements anyway. Alex, what was > your workload? (you didn't get back to me yet). > > cheers. > I missed the i_sem in nfs, did not look high enough up the stack. Possibly the double flush in there was catching some extra data, which considering we do this under the i_sem is somewhat unlikely. The change would however allow reads to proceed across flushes as the fsync_datawait which matters is now the one in the fsync caller which is not holding any lock a read cares about. Steve From owner-linux-xfs@oss.sgi.com Thu Feb 26 06:19:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 06:19:56 -0800 (PST) Received: from deneb.allinfo.com (24-148-31-190.c3-0.stk-ubr1.chi-stk.il.cable.rcn.com [24.148.31.190]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QEJrKO028100 for ; Thu, 26 Feb 2004 06:19:54 -0800 Received: (qmail 19538 invoked by uid 0); 26 Feb 2004 12:19:48 -0000 Received: from unknown (HELO atlas) (192.168.2.75) by deneb.local with SMTP; 26 Feb 2004 12:19:48 -0000 Message-ID: <997721204.1077797988937.JavaMail.jwu@atlas> Date: Thu, 26 Feb 2004 06:19:48 -0600 (CST) From: Ian Lenzen To: linux-xfs@oss.sgi.com Subject: Open Source category Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 2243 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ian@all.info Precedence: bulk X-list: linux-xfs Hello, We're creating a directory focused on web site credibility. We included: http://oss.sgi.com/ in the Open Source section of the All.info directory. Descriptive information provided by you and our editors helps our users choose sites. Our editors have already selected starter keyterms and a category for your web site. To review their work, add information and gain editorial control over your site's record in our system, please update your information here: http://all.info/s?a=l&z=1ve44wpct0ld64uut7a68c More information about All.info is available at: http://www.all.info Thanks in advance. Ian Lenzen Editor, All.info - the Directory of Topics Note: If you are NOT the proper site contact or you would like to provide a corrected site contact, please update it here: http://all.info/s?a=nl&z=1ve44wpct0ld64uut7a68c&x=linux-xfs%40oss.sgi.com If you have other questions, please email: priority@all.info From owner-linux-xfs@oss.sgi.com Thu Feb 26 07:02:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 07:02:42 -0800 (PST) Received: from relay.uni-heidelberg.de (relay.uni-heidelberg.de [129.206.100.212]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QF2LKO029274 for ; Thu, 26 Feb 2004 07:02:22 -0800 Received: from mail.iwr.uni-heidelberg.de (mail.iwr.uni-heidelberg.de [129.206.104.30]) by relay.uni-heidelberg.de (8.12.10/8.12.10) with ESMTP id i1QF2Kiv022327 for ; Thu, 26 Feb 2004 16:02:20 +0100 (MET) Received: from boskoop.iwr.uni-heidelberg.de (boskoop.iwr.uni-heidelberg.de [129.206.120.167]) by mail.iwr.uni-heidelberg.de (8.12.10/8.12.9) with ESMTP id i1QF2J2x014760 for ; Thu, 26 Feb 2004 16:02:19 +0100 (MET) Received: from iwr.uni-heidelberg.de (localhost [127.0.0.1]) by boskoop.iwr.uni-heidelberg.de (8.9.3p2/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA04370 for ; Thu, 26 Feb 2004 16:02:19 +0100 Message-ID: <403E0A7A.3040505@iwr.uni-heidelberg.de> Date: Thu, 26 Feb 2004 16:02:18 +0100 From: Michael Lampe Organization: IWR Uni Heidelberg User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040117 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.25 & xfs & ide write barriers Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2244 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: Michael.Lampe@iwr.uni-heidelberg.de Precedence: bulk X-list: linux-xfs fs/xfs/linux/xfs_buf.c already has #ifdef RQ_WRITE_ORDERED if (flush) set_bit(BH_Ordered_Flush, &bufferlist[cnt-1]->b_state); #endif in _pagebuf_page_io. Is this all I need (I already have applied the ide write barrier patch) to safely use disk write back caching? Thanks, Michael From owner-linux-xfs@oss.sgi.com Thu Feb 26 07:10:25 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 07:10:39 -0800 (PST) Received: from c.pexit.com ([216.187.68.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QFAMKO029878 for ; Thu, 26 Feb 2004 07:10:24 -0800 Received: from consensyxdlcmm (CPE0002b38c3dc3-CM000a73663c85.cpe.net.cable.rogers.com [63.139.199.14]) by c.pexit.com (8.11.6/8.11.6) with SMTP id i1QF9Zs14042; Thu, 26 Feb 2004 10:09:35 -0500 Message-ID: <028c01c3fc7a$9930aea0$9002a8c0@consensys.com> From: "Alex Wun" To: "Nathan Scott" , "Steve Lord" Cc: References: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> <20040225062907.GB1832@frodo> <403CAA00.20502@xfs.org> <20040226040651.GC1177@frodo> Subject: Re: XFS Writes: IOLOCK_EXCL Date: Thu, 26 Feb 2004 10:09:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 2245 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexwun@consensys.com Precedence: bulk X-list: linux-xfs I'm just forwarding everything to you. They're kind of on the wrong track right now. Again. Sorry for the mess I've created. Alex W. ----- Original Message ----- From: "Nathan Scott" To: "Steve Lord" Cc: "Alex Wun" ; Sent: Wednesday, February 25, 2004 11:06 PM Subject: Re: XFS Writes: IOLOCK_EXCL > Thanks Steve. > > On Wed, Feb 25, 2004 at 07:58:24AM -0600, Steve Lord wrote: > > > > Only speaking for 2.6 here, so take that under advisement. > > After an audit, this seems to be valid for both 2.4 and 2.6. > > > There are very few callers of fsync in the kernel, and they all do the > > data flush and wait for data themselves, the filesystem fsync code is > > not involved in the data flush at all for most filesystems, just the > > metadata for the file. The callers hold the i_sem, but not the nfs > > commit case. > > Mmmm? seems to me that i_sem is also held for nfs commit, both > in 2.4 and 2.6 (nfsd_commit -> nfsd_sync -> down(i_sem) -> > nfsd_dosync -> fop->fsync). > > > As for flushing data without the IO lock, I think this is OK in general, > > if a new read comes along there is no problem, if a new write modifies > > the page then it will get redirtied and flushed again later. If a > > truncate removes the page then it will delete the page before after > > it is flushed. The holding of the IO lock is partially a hold over > > from Irix where it is required around the VOP_FLUSH..... calls. > > Yep, OK, thanks. > > > The tosspages and flushinval pages cases do need the lock though. > > > > This is untested, but should generally speed things up in 2.6. A very > > quick scan of 2.4 seems to suggest a similar change will work there > > too. > > I think its always valid to do this (after auditing the callers), > but doesn't seem to do "general speedup" - the "usual suspects" > benchmarks don't show any improvements anyway. Alex, what was > your workload? (you didn't get back to me yet). > > cheers. > > -- > Nathan > From owner-linux-xfs@oss.sgi.com Thu Feb 26 07:31:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 07:31:14 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1QFVCKO030881 for ; Thu, 26 Feb 2004 07:31:12 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1QFVCZc030880 for linux-xfs@oss.sgi.com; Thu, 26 Feb 2004 07:31:12 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1QFVAKQ030866 for ; Thu, 26 Feb 2004 07:31:11 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1QFTNpn030843; Thu, 26 Feb 2004 07:29:23 -0800 Date: Thu, 26 Feb 2004 07:29:23 -0800 Message-Id: <200402261529.i1QFTNpn030843@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 296] Kernel 2.4.22 xfs_force_shutdown line 4049 of file xfs_bmap.c X-Bugzilla-Reason: AssignedTo X-archive-position: 2246 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=296 ------- Additional Comments From michele@pupazzo.org 2004-26-02 07:29 PDT ------- Just wanted to chime in since I think I hit this bug (I'd tend to assume it is related) as well. For me it happened with kernel 2.4.21 plus XFS. Machine is a Samba 3 and Dhcp server. The volume is mounted via LVM. XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1623 of file xfs_alloc.c. Caller 0xc018460b f5709d68 c01ada2c 00000000 0001efe5 f5709dc8 c0183963 c02ec81c 00000001 00000000 c02ec7f6 00000657 c018460b 00000000 0001efe5 c866ee60 d481df34 e02bf000 00000000 e5639eec 0001eff0 0000000e 00000001 0001efe3 00000002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] xfs_force_shutdown(lvm(58,0),0x8) called from line 4051 of file xfs_bmap.c. Return address = 0xc01dd9da Filesystem "lvm(58,0)": Corruption of in-memory data detected. Shutting down filesystem: lvm(58,0) Please umount the filesystem, and rectify the problem(s) XFS mounting filesystem lvm(58,0) Starting XFS recovery on filesystem: lvm(58,0) (dev: 58/0) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1623 of file xfs_alloc.c. Caller 0xc018460b dfcbdc14 c01ada2c 00000000 0001efe5 dfcbdc74 c0183963 c02ec81c 00000001 00000000 c02ec7f6 00000657 c018460b 00000000 0001efe5 c866ee60 cc944594 e02bf000 00000000 e7d7ff70 0001eff0 0000000e 00000001 0001efe3 00000002 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Ending XFS recovery on filesystem: lvm(58,0) (dev: 58/0) XFS mounting filesystem lvm(58,0) Ending clean XFS mount for filesystem: lvm(58,0) # xfs_info /opt/ meta-data=/opt isize=256 agcount=25, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=12800, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 # cat /proc/fs/xfs/stat extent_alloc 7921 2030841 8064 2019641 abt 40568 257225 16302 16054 blk_map 18578027 148817 13666 148817 13695 18740562 1515917 bmbt 579 4325 61 18 dir 472061 8847 8712 325211 trans 5509 106952 5617 ig 462957 101776 188 361181 0 333701 21376 log 12220 251090 19 18906 6153 push_ail 118099 0 0 0 0 0 0 0 0 0 xstrat 4130 0 rw 2262088 17225932 attr 30753 9816 2 0 icluster 66981 27024 82509 vnodes 27480 362408 0 67931 334928 334928 334928 0 Running the first OOPS through ksymoops: Trace; c01ada2c Trace; c0183963 Trace; c018460b Trace; c018460b Trace; c0193873 Trace; c01b5aca Trace; c01cdbad Trace; c01de059 Trace; c01dce84 Trace; c014fb51 Trace; c015046e Trace; c014da66 Trace; c0147b8d Trace; c01089d3 end here is the one during the repair: Trace; c01ada2c Trace; c0183963 Trace; c018460b Trace; c018460b Trace; c01c0a82 Trace; c01c0af6 Trace; c01c1e7c Trace; c01ba716 Trace; c01c3924 Trace; c01b8310 Trace; c01ca4d1 Trace; c01dd78f Trace; c01dd552 Trace; c013fbf2 Trace; c0151b06 Trace; c013fddd Trace; c0152be9 Trace; c0152ea2 Trace; c0152d0d Trace; c01532cf Trace; c01089d3 Hope this might give some more insight. let me know if I might provide further info ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Thu Feb 26 09:54:28 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 09:54:49 -0800 (PST) Received: from moving-picture.com (mpc-5.sohonet.co.uk [193.203.82.230]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QHruKO004361 for ; Thu, 26 Feb 2004 09:54:13 -0800 Date: Thu, 26 Feb 2004 09:53:56 -0800 From: james-p@moving-picture.com Message-Id: <200402261754.i1QHruKO004361@oss.sgi.com> X-archive-position: 2247 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: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs I have a problem with df reporting "Value too large for defined data type" for file systems on a particular server. The problem occurs when using an NFS client running on a 2.6.3 kernel that mounts XFS file systems over NFS from a server running a 2.4.21 kernel with XFS 1.3 When I run df on these file systems using the 2.6.3 client I get: df: `/mnt/tmp': Value too large for defined data type However, running df on any other client running 2.4.X, or on the server itself works OK. Also, running df on the 2.6.3 client to any other NFS exported file system works OK. I initially thought this was an NFS issue, but it appears to be a problem with the number of inodes reported from the underlying XFS file system. My original posts to the NFS list can be seen via: http://marc.theaimsgroup.com/?t=107762984200002&r=1&w=2 It appears the number of inodes that is being reported back to statfs() from this file system (from any client or on the server itself) is 2^64 - 1. On 2.4.X clients, the kernel routine just takes the lower 32 bits and doesn't complain. But on the 2.6.X client, it checks for the overflow and returns EOVERFLOW to statfs() - hence the error above. When I run 'df -i /disk2' on the 2.4.21 server, I get: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdc1 4294967295 3 4294967292 1% /disk2 df reports: Filesystem 1k-blocks Used Available Use% Mounted on /dev/sdc1 976428116 3744 976424372 1% /disk2 i.e. 2^32 - 1 inodes (which is in fact the lower 32 bits of 2^64 - 1) The server in question has an external 3.5TB RAID array, partitioned on the RAID into 4 separate volumes that are seen on the host server as separate LUNs. 3 of these devices are about 1TB, the forth is approx 500Gb. Each of 3 1TB devices have this problem, the 500Gb device reports sensible inode numbers (much less than 2^32) and hence df works OK when statfs'ing this file system from a 2.6.3 client. The question is why is this file system (and other similar file systems on the same file server) reporting so many available inodes? All the other XFS file systems on other servers of about 1TB (or more) report the number of inodes at much less than 2^32. The XFS file systems were initially made using a very old version of xfsprogs, but I've just remade one file system using v2.5.6-0 - and it still shows the same behaviour. xfs_info reports: meta-data=/disk2 isize=256 agcount=233, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=244139797, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Any idea as to what is going on? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Thu Feb 26 09:58:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 09:58:59 -0800 (PST) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QHwsKO004786 for ; Thu, 26 Feb 2004 09:58:55 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 3CC1116233F for ; Thu, 26 Feb 2004 18:58:53 +0100 (CET) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10966-02 for ; Thu, 26 Feb 2004 18:58:50 +0100 (CET) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 93402161EAF for ; Thu, 26 Feb 2004 18:58:50 +0100 (CET) Message-ID: <403E33DA.2070509@opticalart.de> Date: Thu, 26 Feb 2004 18:58:50 +0100 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: XFS List Subject: XFS on large block device problem Content-Type: multipart/mixed; boundary="------------010204080307010803060106" X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 2248 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------010204080307010803060106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi! I just upgraded one of our linux boxes (Redhat 9 + usual 2.6 and glibc patches) to kernel 2.6.3 and wanted to try out the large block device support. First attemp, beware... :-) I setup a md0 device consisting of four ~1.5TB large devices with mkraid /dev/md0 and a simple /etc/raidtab. I had some issues makeing the filesystem on /dev/md0. mkfs.xfs complained about a non-clean md0 device and would not let me do anything with it. Upgrading to xfs-progs 2.6.3 and mdadm 1.5 tools didn't change that. First doing an mkfs.ext3, mounting and unmounting the device seems to cure that. At least after that I could mkfs.xfs it. Unfortunatly restoring (tar not xfsrestore) some demo data back onto the drive I was getting a lot of xfs/kernel messages into the logfile. The tar process stopped with errors after about 200M of restore and the last files got corrupted. pdflush has high activity (~95%). xfs_repair reports beside a lot of other problems a couple of: primary/secondary superblock XX conflict - AG superblock geometry info conflicts with filesystem geometry which really makes me wonder, whats going on... See the attached files for further info. Unfortunatly I currently don't have any debugging tools on that machine... Everything is peachy (with LBD), if I stay below the usual 2TB limits with the 2.6.3 kernel. Am I missing anything for XFS LBD support? Any ideas? Cheers, Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 --------------010204080307010803060106 Content-Type: text/plain; name="messages.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="messages.txt" ... Feb 26 17:19:17 machine kernel: XFS mounting filesystem md0 Feb 26 17:19:17 machine kernel: XFS mounting filesystem md1 Feb 26 17:23:38 machine kernel: st0: Block limits 1 - 16777215 bytes. Feb 26 17:24:00 machine kernel: 0x0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Feb 26 17:24:00 machine kernel: Filesystem "md0": XFS internal error xfs_alloc_read_agf at line 2201 of file fs/xfs/xfs_alloc.c. Caller 0xc01dfcdd Feb 26 17:24:00 machine kernel: Call Trace: Feb 26 17:24:00 machine kernel: [] xfs_alloc_read_agf+0x1b9/0x22e Feb 26 17:24:00 machine kernel: [] xfs_alloc_fix_freelist+0x464/0x47a Feb 26 17:24:00 machine last message repeated 2 times Feb 26 17:24:00 machine kernel: [] xfs_trans_log_buf+0x6e/0xa7 Feb 26 17:24:00 machine kernel: [] xfs_alloc_log_agf+0x58/0x5c Feb 26 17:24:00 machine kernel: [] xfs_alloc_ag_vextent+0xaf/0x143 Feb 26 17:24:00 machine kernel: [] xfs_alloc_vextent+0x2cf/0x4fc Feb 26 17:24:00 machine kernel: [] xfs_bmap_alloc+0xc8b/0x1c05 Feb 26 17:24:00 machine kernel: [] xfs_bmap_add_extent_delay_real+0x114b/0x1692 Feb 26 17:24:00 machine kernel: [] xfs_bmbt_get_state+0x2f/0x3b Feb 26 17:24:00 machine kernel: [] xfs_bmapi+0xfd0/0x169c Feb 26 17:24:00 machine kernel: [] recalc_task_prio+0xb2/0x1ea Feb 26 17:24:00 machine kernel: [] try_to_wake_up+0x1f1/0x294 Feb 26 17:24:00 machine kernel: [] __wake_up_common+0x38/0x57 Feb 26 17:24:00 machine kernel: [] schedule+0x387/0x6c5 Feb 26 17:24:00 machine kernel: [] xfs_log_reserve+0xd7/0xdc Feb 26 17:24:00 machine kernel: [] xfs_iomap_write_allocate+0x2c1/0x504 Feb 26 17:24:00 machine kernel: [] bio_alloc+0xcb/0x19c Feb 26 17:24:00 machine kernel: [] submit_bh+0xa1/0x1e5 Feb 26 17:24:00 machine kernel: [] xfs_iunlock+0x3d/0x77 Feb 26 17:24:00 machine kernel: [] xfs_iomap+0x415/0x54a Feb 26 17:24:00 machine kernel: [] map_blocks+0x7a/0x15c Feb 26 17:24:00 machine kernel: [] page_state_convert+0x50c/0x6a0 Feb 26 17:24:00 machine kernel: [] pagebuf_iorequest+0xb6/0x14e Feb 26 17:24:00 machine kernel: [] xfs_bdstrat_cb+0x42/0x48 Feb 26 17:24:00 machine kernel: [] pagebuf_iostart+0x54/0xac Feb 26 17:24:00 machine kernel: [] xfs_iflush+0x272/0x535 Feb 26 17:24:01 machine kernel: [] linvfs_writepage+0x60/0x10c Feb 26 17:24:01 machine kernel: [] mpage_writepages+0x2ca/0x3b4 Feb 26 17:24:01 machine kernel: [] xfs_inode_flush+0x26b/0x2b6 Feb 26 17:24:01 machine kernel: [] linvfs_writepage+0x0/0x10c Feb 26 17:24:01 machine kernel: [] do_writepages+0x36/0x38 Feb 26 17:24:01 machine kernel: [] __sync_single_inode+0xf7/0x283 Feb 26 17:24:01 machine kernel: [] sync_sb_inodes+0x1b1/0x295 Feb 26 17:24:01 machine kernel: [] writeback_inodes+0x85/0x129 Feb 26 17:24:01 machine kernel: [] background_writeout+0xbc/0xfa Feb 26 17:24:01 machine kernel: [] __pdflush+0x106/0x22c Feb 26 17:24:01 machine kernel: [] pdflush+0x0/0x13 Feb 26 17:24:01 machine kernel: [] pdflush+0xf/0x13 Feb 26 17:24:01 machine kernel: [] background_writeout+0x0/0xfa Feb 26 17:24:01 machine kernel: [] kernel_thread_helper+0x0/0xb Feb 26 17:24:01 machine kernel: [] kernel_thread_helper+0x5/0xb ... --------------010204080307010803060106 Content-Type: text/plain; name="xfs_repair.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_repair.txt" Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... bad on-disk superblock 9 - bad magic number primary/secondary superblock 9 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 9 bad version # 0 for agf 9 bad sequence # 0 for agf 9 bad length 0 for agf 9, should be 45329664 bad magic # 0x0 for agi 9 bad version # 0 for agi 9 bad sequence # 0 for agi 9 bad length # 0 for agi 9, should be 45329664 reset bad sb for ag 9 reset bad agf for ag 9 reset bad agi for ag 9 bad agbno 0 for btbno root, agno 9 bad agbno 0 for btbcnt root, agno 9 bad agbno 0 for inobt root, agno 9 bad on-disk superblock 10 - bad magic number primary/secondary superblock 10 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 10 bad version # 0 for agf 10 bad sequence # 0 for agf 10 bad length 0 for agf 10, should be 45329664 bad magic # 0x0 for agi 10 bad version # 0 for agi 10 bad sequence # 0 for agi 10 bad length # 0 for agi 10, should be 45329664 reset bad sb for ag 10 reset bad agf for ag 10 reset bad agi for ag 10 bad agbno 0 for btbno root, agno 10 bad agbno 0 for btbcnt root, agno 10 bad agbno 0 for inobt root, agno 10 bad on-disk superblock 11 - bad magic number primary/secondary superblock 11 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 11 bad version # 0 for agf 11 bad sequence # 0 for agf 11 bad length 0 for agf 11, should be 45329664 bad magic # 0x0 for agi 11 bad version # 0 for agi 11 bad sequence # 0 for agi 11 bad length # 0 for agi 11, should be 45329664 reset bad sb for ag 11 reset bad agf for ag 11 reset bad agi for ag 11 bad agbno 0 for btbno root, agno 11 bad agbno 0 for btbcnt root, agno 11 bad agbno 0 for inobt root, agno 11 bad on-disk superblock 21 - bad magic number primary/secondary superblock 21 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 21 bad version # 0 for agf 21 bad sequence # 0 for agf 21 bad length 0 for agf 21, should be 45329664 bad magic # 0x0 for agi 21 bad version # 0 for agi 21 bad sequence # 0 for agi 21 bad length # 0 for agi 21, should be 45329664 reset bad sb for ag 21 reset bad agf for ag 21 reset bad agi for ag 21 bad agbno 0 for btbno root, agno 21 bad agbno 0 for btbcnt root, agno 21 bad agbno 0 for inobt root, agno 21 bad on-disk superblock 22 - bad magic number primary/secondary superblock 22 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 22 bad version # 0 for agf 22 bad sequence # 0 for agf 22 bad length 0 for agf 22, should be 45329664 bad magic # 0x0 for agi 22 bad version # 0 for agi 22 bad sequence # 0 for agi 22 bad length # 0 for agi 22, should be 45329664 reset bad sb for ag 22 reset bad agf for ag 22 reset bad agi for ag 22 bad agbno 0 for btbno root, agno 22 bad agbno 0 for btbcnt root, agno 22 bad agbno 0 for inobt root, agno 22 bad on-disk superblock 23 - bad magic number primary/secondary superblock 23 conflict - AG superblock geometry info conflicts with filesystem geometry bad magic # 0x0 for agf 23 bad version # 0 for agf 23 bad sequence # 0 for agf 23 bad length 0 for agf 23, should be 45329664 bad magic # 0x0 for agi 23 bad version # 0 for agi 23 bad sequence # 0 for agi 23 bad length # 0 for agi 23, should be 45329664 reset bad sb for ag 23 reset bad agf for ag 23 reset bad agi for ag 23 bad agbno 0 for btbno root, agno 23 bad agbno 0 for btbcnt root, agno 23 bad agbno 0 for inobt root, agno 23 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 9 unlinked list error following ag 10 unlinked list error following ag 11 unlinked list error following ag 21 unlinked list error following ag 22 unlinked list error following ag 23 unlinked list - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - agno = 16 - agno = 17 - agno = 18 - agno = 19 - agno = 20 - agno = 21 - agno = 22 - agno = 23 - agno = 24 - agno = 25 - agno = 26 - agno = 27 - agno = 28 - agno = 29 - agno = 30 - agno = 31 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done --------------010204080307010803060106-- From owner-linux-xfs@oss.sgi.com Thu Feb 26 11:33:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 11:33:35 -0800 (PST) Received: from c.pexit.com ([216.187.68.150]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QJXBKO007206 for ; Thu, 26 Feb 2004 11:33:12 -0800 Received: from consensyxdlcmm (CPE0002b38c3dc3-CM000a73663c85.cpe.net.cable.rogers.com [63.139.199.14]) by c.pexit.com (8.11.6/8.11.6) with SMTP id i1QJWTe05910; Thu, 26 Feb 2004 14:32:30 -0500 Message-ID: <02e401c3fc9f$53d42ec0$9002a8c0@consensys.com> From: "Alex Wun" To: "Nathan Scott" , "Steve Lord" Cc: References: <01fa01c3fafa$7c3482d0$9002a8c0@consensys.com> <20040225062907.GB1832@frodo> <403CAA00.20502@xfs.org> <20040226040651.GC1177@frodo> Subject: Re: XFS Writes: IOLOCK_EXCL Date: Thu, 26 Feb 2004 14:32:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-archive-position: 2249 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alexwun@consensys.com Precedence: bulk X-list: linux-xfs ----- Original Message ----- From: "Nathan Scott" To: "Steve Lord" Cc: "Alex Wun" ; Sent: Wednesday, February 25, 2004 11:06 PM Subject: Re: XFS Writes: IOLOCK_EXCL > Thanks Steve. > > On Wed, Feb 25, 2004 at 07:58:24AM -0600, Steve Lord wrote: > > > > Only speaking for 2.6 here, so take that under advisement. > > After an audit, this seems to be valid for both 2.4 and 2.6. > > > There are very few callers of fsync in the kernel, and they all do the > > data flush and wait for data themselves, the filesystem fsync code is > > not involved in the data flush at all for most filesystems, just the > > metadata for the file. The callers hold the i_sem, but not the nfs > > commit case. > > Mmmm? seems to me that i_sem is also held for nfs commit, both > in 2.4 and 2.6 (nfsd_commit -> nfsd_sync -> down(i_sem) -> > nfsd_dosync -> fop->fsync). > > > As for flushing data without the IO lock, I think this is OK in general, > > if a new read comes along there is no problem, if a new write modifies > > the page then it will get redirtied and flushed again later. If a > > truncate removes the page then it will delete the page before after > > it is flushed. The holding of the IO lock is partially a hold over > > from Irix where it is required around the VOP_FLUSH..... calls. > > Yep, OK, thanks. > > > The tosspages and flushinval pages cases do need the lock though. > > > > This is untested, but should generally speed things up in 2.6. A very > > quick scan of 2.4 seems to suggest a similar change will work there > > too. > > I think its always valid to do this (after auditing the callers), > but doesn't seem to do "general speedup" - the "usual suspects" > benchmarks don't show any improvements anyway. Alex, what was > your workload? (you didn't get back to me yet). > Sorry that I haven't gotten back to you in response to your question about the workload. Prior to your suggestion I had only tested a single application running on a single client over synchronous NFS v3. The application performs sequential writing of 4GB files to fill up the partition and then turns around and does sequential reading of those files to verify the their contents. I am now trying multiple clients running multiple instances of the app. This has led to some issues on the client side. After conferring with the lead developer, we have decided to produce a set of patches that reflect the work that we have done so far. The overall objective has been to improve NFS synchronous write performance. To accomplish this we have had to make changes to the Linux NFS client code, the Linux NFS server code and the XFS file system code on the server. We intend to submit these patches to the net shortly. Alex Wun From owner-linux-xfs@oss.sgi.com Thu Feb 26 13:00:52 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 13:01:04 -0800 (PST) Received: from bycast.com (bycast.com [207.61.255.246]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QL0pKO015692 for ; Thu, 26 Feb 2004 13:00:52 -0800 Received: from bycast.com (24.87.12.250) by bycast.com with ESMTP (Eudora Internet Mail Server 3.0); Thu, 26 Feb 2004 13:02:26 -0700 Message-ID: <403E5E7F.8090203@bycast.com> Date: Thu, 26 Feb 2004 13:00:47 -0800 From: Mike Montour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Roehrich CC: linux-xfs@oss.sgi.com Subject: Re: dm_write_invis() blocking problem References: <200402242357.i1ONur9i13910926@clink.americas.sgi.com> In-Reply-To: <200402242357.i1ONur9i13910926@clink.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2250 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mmontour@bycast.com Precedence: bulk X-list: linux-xfs Dean Roehrich wrote: >Mike, > > Can you try this new version of the patch for fixing the invis I/O blocking? >This goes on top of the last patch--or, on top of the code on oss.sgi.com. > It seems to work now - I tested dm_write_invis() while handling a DM_EVENT_READ, DM_EVENT_WRITE, and DM_EVENT_TRUNCATE, and nothing blocked. I tested truncation for the whole file, as well as starting at an offset. I will let you know if I find any other problems. Thanks, -Mike From owner-linux-xfs@oss.sgi.com Thu Feb 26 13:16:00 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 13:16:24 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.sgi.com [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1QLFxKO016225 for ; Thu, 26 Feb 2004 13:15:59 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1QLFsa5011505 for ; Thu, 26 Feb 2004 15:15:54 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1QLFru834690709; Thu, 26 Feb 2004 15:15:53 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1QLFrEq491614; Thu, 26 Feb 2004 15:15:53 -0600 (CST) Subject: Re: XFS on large block device problem From: Eric Sandeen To: Frank Hellmann Cc: XFS List In-Reply-To: <403E33DA.2070509@opticalart.de> References: <403E33DA.2070509@opticalart.de> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1077830153.1091.44.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 26 Feb 2004 15:15:53 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2251 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs If you are able to re-mkfs the filesystem, can you try a mkfs immediately followed by a repair, to see if the mkfs worked properly? I've been talking to someone else on 2.6.3 + xfs + lbd + md where mkfs wasn't even able to get bits down to the disk properly. This is just userspace; if we can't do writes and have md put them in the right place, we're in trouble. stracing mkfs, I see pwrites of superblocks to locations that never seem to make it to disk... I'm tempted to blame md, but I need to try to recreate here. Anyway, can you try mkfs.xfs; xfs_repair? -Eric On Thu, 2004-02-26 at 11:58, Frank Hellmann wrote: > Hi! > > I just upgraded one of our linux boxes (Redhat 9 + usual 2.6 and glibc > patches) to kernel 2.6.3 and wanted to try out the large block device > support. First attemp, beware... :-) > > I setup a md0 device consisting of four ~1.5TB large devices with mkraid > /dev/md0 and a simple /etc/raidtab. > > I had some issues makeing the filesystem on /dev/md0. mkfs.xfs > complained about a non-clean md0 device and would not let me do anything > with it. > > Upgrading to xfs-progs 2.6.3 and mdadm 1.5 tools didn't change that. > > First doing an mkfs.ext3, mounting and unmounting the device seems to > cure that. At least after that I could mkfs.xfs it. > > Unfortunatly restoring (tar not xfsrestore) some demo data back onto the > drive I was getting a lot of xfs/kernel messages into the logfile. The > tar process stopped with errors after about 200M of restore and the last > files got corrupted. pdflush has high activity (~95%). > > xfs_repair reports beside a lot of other problems a couple of: > > primary/secondary superblock XX conflict - AG superblock geometry info > conflicts with filesystem geometry > > which really makes me wonder, whats going on... See the attached files > for further info. Unfortunatly I currently don't have any debugging > tools on that machine... > > Everything is peachy (with LBD), if I stay below the usual 2TB limits > with the 2.6.3 kernel. > > Am I missing anything for XFS LBD support? Any ideas? > > > Cheers, > Frank... -- Eric Sandeen [C]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 Feb 26 21:06:06 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 21:06:18 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1R565KO030705 for ; Thu, 26 Feb 2004 21:06:06 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1R47tO9021502 for ; Thu, 26 Feb 2004 20:07:56 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14814; Fri, 27 Feb 2004 16:05:47 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1R55j7a027506; Fri, 27 Feb 2004 16:05:46 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1R55iP2027504; Fri, 27 Feb 2004 16:05:44 +1100 Date: Fri, 27 Feb 2004 16:05:44 +1100 From: Tim Shimmin Message-Id: <200402270505.i1R55iP2027504@sherman.melbourne.sgi.com> Subject: TAKE 892502 - v2 log stripe reservation fix Apparently-To: Apparently-To: X-archive-position: 2252 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Date: Thu Feb 26 20:57:03 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167580a fs/xfs/xfsidbg.c - 1.256 - Remove l_stripemask as it implicitly forces stripe size to power of 2 BBs which it shouldn't. fs/xfs/xfs_log.c - 1.289 - Add v2 log stripe padding to ic_roundoff so that padding will be catered for in update of reservation cursor. Remove l_stripemask as it implicitly forces stripe size to power of 2 BBs which it shouldn't. Simplify iclog count calculations. fs/xfs/xfs_log_priv.h - 1.100 - Remove l_stripemask as it implicitly forces stripe size to power of 2 BBs which it shouldn't. From owner-linux-xfs@oss.sgi.com Thu Feb 26 21:18:20 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Feb 2004 21:18:31 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1R5IJKO031225 for ; Thu, 26 Feb 2004 21:18:19 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1R5IAF6026851 for ; Thu, 26 Feb 2004 21:18:11 -0800 Received: from sherman.melbourne.sgi.com (sherman.melbourne.sgi.com [134.14.54.232]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14962 for ; Fri, 27 Feb 2004 16:18:09 +1100 Received: from sherman.melbourne.sgi.com (localhost.localdomain [127.0.0.1]) by sherman.melbourne.sgi.com (8.12.8/8.12.8) with ESMTP id i1R5I87a027593 for ; Fri, 27 Feb 2004 16:18:08 +1100 Received: (from tes@localhost) by sherman.melbourne.sgi.com (8.12.8/8.12.8/Submit) id i1R5I8IK027591 for linux-xfs@oss.sgi.com; Fri, 27 Feb 2004 16:18:08 +1100 Date: Fri, 27 Feb 2004 16:18:08 +1100 From: Tim Shimmin Message-Id: <200402270518.i1R5I8IK027591@sherman.melbourne.sgi.com> Subject: log DEBUG fixes Apparently-To: X-archive-position: 2253 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tes@sherman.melbourne.sgi.com Precedence: bulk X-list: linux-xfs Fix some stuff which gets turned on when XFS_LOUD_RECOVERY is set for debugging. Date: Thu Feb 26 21:15:53 PST 2004 Workarea: sherman.melbourne.sgi.com:/build/tes/isms/2.4.x-xfs Inspected by: nathans@sgi.com The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167581a fs/xfs/xfs_log_recover.c - 1.286 - fix up some code for when XFS_LOUD_RECOVERY is turned on. Missing definition of variable i :) Needed to compile xlog_unpack_data_checksum. hlen is in bytes and not BBs so give better name to local variable. Fixes to xlog_recover_check_summary() to do endian conversion on superblock. From owner-linux-xfs@oss.sgi.com Fri Feb 27 02:17:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 02:17:47 -0800 (PST) Received: from shksmtp02.so-net.com.hk (shksmtp02.so-net.com.hk [203.99.142.22]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RAHWKO006559 for ; Fri, 27 Feb 2004 02:17:33 -0800 Received: (qmail 27415 invoked from network); 27 Feb 2004 10:17:24 -0000 Received: from so232072.bbo232.so-net.com.hk (HELO linuxmail.org) ([203.176.232.72]) (envelope-sender ) by shksmtp02.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 27 Feb 2004 10:17:24 -0000 Message-ID: <403F1934.3020701@linuxmail.org> Date: Fri, 27 Feb 2004 18:17:24 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Performance problem with xfs Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2254 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Hi, I am having performance issues with a box running 3ware 0+1 mode where one of the filesystems is xfs based. xfs_ili and xfs_inode are the values that change xfs_bmap /var/catchall/bulkdb/ /var/catchall/bulkdb/: 0: [0..7]: 42235064..42235071 Also, kswapd chews substantial cpu. The filesystem was created using the latest xfs tools with zarro options besides -f to overwrite the existing filesystem. Please give me some pointers on how to tune the filesystem. Feizhou From owner-linux-xfs@oss.sgi.com Fri Feb 27 02:43:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 02:43:59 -0800 (PST) Received: from mail.vcc.de (mail.vcc.de [217.111.2.122]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RAhNKO008885 for ; Fri, 27 Feb 2004 02:43:23 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.vcc.de (Postfix) with ESMTP id 65EA716233F; Fri, 27 Feb 2004 11:43:22 +0100 (CET) Received: from mail.vcc.de ([127.0.0.1]) by localhost (mail.vcc.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30618-01; Fri, 27 Feb 2004 11:43:20 +0100 (CET) Received: from opticalart.de (wolverine.vcc.de [217.111.2.200]) by mail.vcc.de (Postfix) with ESMTP id 130EA161EDC; Fri, 27 Feb 2004 11:43:20 +0100 (CET) Message-ID: <403F1F47.7040003@opticalart.de> Date: Fri, 27 Feb 2004 11:43:19 +0100 From: Frank Hellmann Organization: Optical Art Film- und Special-Effects GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen Cc: XFS List Subject: Re: XFS on large block device problem References: <403E33DA.2070509@opticalart.de> <1077830153.1091.44.camel@stout.americas.sgi.com> In-Reply-To: <1077830153.1091.44.camel@stout.americas.sgi.com> Content-Type: multipart/mixed; boundary="------------040407050908070007050109" X-Virus-Scanned: by amavisd-new at vcc.de X-archive-position: 2255 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: frank@opticalart.de Precedence: bulk X-list: linux-xfs This is a multi-part message in MIME format. --------------040407050908070007050109 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Eric! Eric Sandeen wrote: > If you are able to re-mkfs the filesystem, can you try a mkfs > immediately followed by a repair, to see if the mkfs worked properly? > I've been talking to someone else on 2.6.3 + xfs + lbd + md where mkfs > wasn't even able to get bits down to the disk properly. This is just > userspace; if we can't do writes and have md put them in the right > place, we're in trouble. stracing mkfs, I see pwrites of superblocks to > locations that never seem to make it to disk... I'm tempted to blame > md, but I need to try to recreate here. > > Anyway, can you try mkfs.xfs; xfs_repair? Sure. I did a clean run of the mkfs.xfs and two runs of xfs_repair. It seems that the xfs_repair doesn't like the filesystem that much. I attached the output and strace. I was wondering if using the other LVM methods would help here? I will give the dm stuff a try and let you know, if it's just dependend on md. Cheers, Frank... > > -Eric > > On Thu, 2004-02-26 at 11:58, Frank Hellmann wrote: > >>Hi! >> >>I just upgraded one of our linux boxes (Redhat 9 + usual 2.6 and glibc >>patches) to kernel 2.6.3 and wanted to try out the large block device >>support. First attemp, beware... :-) >> >>I setup a md0 device consisting of four ~1.5TB large devices with mkraid >>/dev/md0 and a simple /etc/raidtab. >> >>I had some issues makeing the filesystem on /dev/md0. mkfs.xfs >>complained about a non-clean md0 device and would not let me do anything >>with it. >> >>Upgrading to xfs-progs 2.6.3 and mdadm 1.5 tools didn't change that. >> >>First doing an mkfs.ext3, mounting and unmounting the device seems to >>cure that. At least after that I could mkfs.xfs it. >> >>Unfortunatly restoring (tar not xfsrestore) some demo data back onto the >>drive I was getting a lot of xfs/kernel messages into the logfile. The >>tar process stopped with errors after about 200M of restore and the last >>files got corrupted. pdflush has high activity (~95%). >> >>xfs_repair reports beside a lot of other problems a couple of: >> >>primary/secondary superblock XX conflict - AG superblock geometry info >>conflicts with filesystem geometry >> >>which really makes me wonder, whats going on... See the attached files >>for further info. Unfortunatly I currently don't have any debugging >>tools on that machine... >> >>Everything is peachy (with LBD), if I stay below the usual 2TB limits >>with the 2.6.3 kernel. >> >>Am I missing anything for XFS LBD support? Any ideas? >> >> >> Cheers, >> Frank... -- -------------------------------------------------------------------------- Frank Hellmann Optical Art GmbH Waterloohain 7a Digital Cinema http://www.opticalart.de 22769 Hamburg frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 --------------040407050908070007050109 Content-Type: application/x-gzip; name="xfs_lbd_problems.tgz" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="xfs_lbd_problems.tgz" H4sIAFgJP0AAA+xda3PbOJbNZ/8KVrZqy5lyYrz4SpVn2+l2sq72JL1J+jE7 nnLJEm2zIlFekUqcfvz3BSSCksgLPqKLTPUu5Epsk+A5JHDuJQCDh7MPN/mz B/mveCgeWfoQSkggxCOy/tS/UyLII1mEhgHhjISyPCOyuEdsndD2Z5kXo4Xn PVrM560V0LX/T/qZle3vPb3xjifJx+PZhBwcHMySYvR0MipGJ3qjt/tJ8/TX 5IT5gfpldDueL7PihLMj+fNqj/A5i4NAeNfTD/lBddiJB3/yZFzkv574lHne geJtLX29piCxYr+ezscf8hMqfOKLiDFx5KWz0cP9uJCn14N5maWFvpD8Uzop 7k4oYesTP/KW2adFWhRJdkIPstEszW4V1sdkkafzzGPm8zqYzm9L5jQrkkU2 mnrVJuNVcBYG0ZFX4kvOQTVXXgxZV/oiGU2LdJZ4J9k8S4BDkwd1pKCx4ETo MyBH3qKQe5KskL8c/Kv16T52Pzr+n+XFYjROrNwGWvO/FHzgB1X+5z6V5eW3 0OX/r/FJHpLxx+Tw8fEyXxzLDDCaHufXaXasdfH4yPvH461fHj+9Uf/ru8Lj f8r9x3/xOPE+jha595fjfz6RqYocLGWyTA5/yz/nJ48v0mz5II/K5pPk5PFs NL5Ls0T+/uzZsz/Wpa8XHw7JE0OG2/rIsg8RiZVuDubTydVsNro/fP3jxcWR p/LokffD2zfvr96enX73++qnn9+evz878v52+sPVD2/Pfzp9f/a7+vn09ZvX f//bmx/fHXlP6ZFHVifxIKQEgxXyfZLJGkmK8fF08iyfP7tfJNP5aCJP+c3V 2+/evL74+5P12Tyl3tnrN2ev33uHr+cy+47vvJt0mnjzhTdJFzIzzxefnzTx xrIKkjqawuMHN1KORSAO+ZH3W15czVSVvbs6f/n27NXvKoiOPLl1deOgNGSR v12LtRrRBao62amII4/vXHmornw8nefJIe9siRXb+qqm6fVxMc3V97G6tqBZ S1zdiibqkh5f0jA8u3h5SVdfpPHFy396H2Pk50v6WF7jkSdvcep05bf2Wgp9 f6uWfB6wmIHVJC+crVORrCwWUEGbCjr75exbc72Vh+9CUnZTQrIo6ivJl+e/ nH23xn5YA2iK9W81Cs5WFJHsOg9iaJN/iTpMBBaCkAt1FnlSXBV3SjhXI/n/ 4W+yQ7L4fJUtZ9fJ4rkMvKd/9STX9ShPrkaTyeJ5eSyLZI1M01laPJcDi8gP lRiS2yvOrtWmI288z1adm+eqp6PgVQq8mmfTz8/1kVdpdnU/uk1yVV4dnM2L K5kEcnmcKrTMk9H1NHlOS0XNllnZMmUg6eB7AtTYOmxW6VaGzirlJuW3p6OF zI0ft1PD72+uLk7fvjp7eX5x9mRghuCEy4ym6mMjftVYrGwtRuKQ+qxnhuC+ apbd40VESPvhD1FCNQRbQ3xJsl8do36jq8joOoZ+AQ+tX15NzNDFxeymurjg SzOokkJ+J0W+K4Zno2k6yney6cAbTk1jSXb147vji2+vzr+TAOcvz789fX/+ 5jUqAxJ8KfFNN6Om9RcX30utB2Sl9YUsdDIbfUjk98NYSXYn26/PdAMER9Yq tNL5uJgermWrtB1TlZgerm/kh9ONlhTukIa+lbf+TxN5Fo/XqjIddOIxzEtH hFK95EJGYKzifV0jCYub0bVu4PPXP51eeIfn2Uep4Yk3WtwuZzJ1PhnUGP// KuLnt7VqUDAC8+zXAhdH64wuKAvp5iom0Y7A9X1GoNBFazq2oRvv0lVlJf67 d//96ux9FXrBeKt+V7F3J3OFCqeO6Bsap//H0o5uQVq7jG//8628DAZcBuXy jseemDoMGN07Jjsk8j6pZtUSdWaPu6Ya153/MFYAYbx14Na1gp/1gSJQB4pg 68Cu+cWScXVgGAxmBA7smjk0nmrXJGLJuKrdkAw+VX9Vq/52rXbNGq4PDFYH BrG6tanS85vJ6PPhb5SEYRQyrkIkoPKn6I8jT2mnERTLxSibzGfNQfD6nLkC vk8nhz2EHkpJqeLLdMJZ1wHl7dh8zlEY7Jxza+GY8J3Cm3EuZ/SSkfCS8/Cb S5n33n5zdfvvxaXsAf/XJaPB7Hd55XTV3jT4op6q7hGPWJ8e8arUwf26mYU6 webYu8eXbvxAzfSTtQTkz9vAv7x892I9dN867qflJeOiG1mO7UtcNcrHOl3f V2nNjwUVwhd+HAfR6tTV9t0BTUg4R8hwasxycDWd5knyQZ0+i0MSMj8mkVCj sX/s/P7PI+/d2dn3V+/O3q9FhHPVLGDychXi+icH62AdrIN1sA7WwTpYB+tg HayDdbAO1sE6WAfrYB2sg3WwDtbBOlgH62AdrIN1sA7WwTpYB+tgHayDdbAO 1sE6WAfrYB2sg3WwDtbBOlgH62AdrIN1sA7WwTpYB+tgHayDdbAO1sE6WAfr YB2sg3WwDtbBOlgH62AdrIN1sA7WwTpYB+tgHayDdbAO1sE6WAfrYB2sg3Ww DtbBOlgH62AdrIN1sA7WwTpYB+tgHayDdbAO1sE6WAfrYB2sg3WwDtbBOlgH 62AdrIN1sA7WwTpYB+tgHayDdbAO1sE6WAfrYB2sg3WwDtbBOlgH62AdrIN1 sA7WwTpYB+tgHayDdbAO1sE6WAfrYB2sg3WwDtbBOlgH62AdrIPFh50ts9no /pA8CMKCmBAiy4SE8+CJt/M58cjB/dY58DC45L5/yUIm/wUlC619Z2J3w/ok KGESg8UhCZkfk0hERJ2R2nxwv0hGk70v06dM/hcLeYW+z0QcM0Ugt25fwy8v 371Yn+XW8T8tLxkXPRkIhHr66mWtFiTDJQv4JZP1RWr7WPO0KXiyp6/Oe8Dq L96AVbUL4J6+eP+iwuVh2PpvXU5csjWuIHGw/l8Bq+815G/3Q47out3qyOcS enOlvZCrulgjU8aiCILeXxM08gMZQISHAqpvQB50kDw0vmB+0E8nEH6LTjR+ GERW9KIJwkgQO7opGSiNOahMBP2UDAHhoEL3lxEPKRckIKGIoGYAZMQGyUjj RzLl95MRhG+WUYUPp7P9ZVQSUOpHwo6MNIMfRKBQ95eRZojDEBTq/jLy/ZBQ ElPKuOGuUpcRH3az0vjGbFeXEYRvlpHGZ3C2219GmsDnDLwh7C8jzRALBgp1 fxmVDIz7DBTq/jIKBQsiKjuMcWi46dRlJAbJSOP7xmxXlxGEb5aRxg/gbLe/ jDRBLLu0dmRUMjB50wGFur+MNEPIAlCo+8soZhH3qU+jkPXsOvuDZKTxY2O2 q8sIwjfLqMKHs93+MioJZO+UWupTa4Ygppb61iUDp4TY6mJTKkerNGJMBD37 2MGwPnZFYMx3dSFBBGYhVQQcTngIvWzNEPiBrW52ScFJ4NvqZ2sKEfqWOtqU xXEQM8oCRnr2tMNhYqoIjFmvLiaIoEVMmiCE0x6CmEoGrsaFlsSkKYQglnrb FUUk4BkLBDGJyOcBE5LJ79nfpsNmhzSDbAhT7muM/wdOFFUMcPJDkJNmEERY 6nRXFFE53WlBTiWFkLchS91uGoSUcBZyHsQ9+93FMDVpAmFMfnU1QQQtYqoI 4OSHICbNEIbwbCGCmEoKQSN41hBBTJrCj+HpDNyJyZ697+yLZiZ5aEx+dTFB BC1i0gQRnPvw5iaF7L9a6oBXFH4Azx2izU4SOVqHJzX2FxMjgnGZlwSlUc8u +MdBYtoQGFNfXUwQgVlMFQGDU9/+YqoYfAZPIO4vpooi5vAM4v5i0hS+SuGW xCTHu0TwQIiY9eyC3wwTkybwjamvLiaIoEVMFQGc+hDEpBliAk8jIoippJBD d3geEUFMmiJk8AQHgpgEVdPqsYiCsGcXfDFMTJogNqa+upggghYxVQRw6kMQ U8ngsxCeTEQQk6YIIng2EUFMJUUgf7PUAWd+HMveBvMlV88OOB021bRhMOa+ xnhu2FxTxcDh5IcgJ80Q+PCkIoKcSopA/UnRkpw0hQjhSQ4EOYWRT3zh+wEN enbB6bDJpg2DMfs15DRstqliCOH0hyCnkiEgDJ5XRJCTphAcnldEkJOmiAQ8 yYEgp9UKKhFJ4ZKenXA2bLZJMwTEmP8aywSGzTZtGOD8tyUn1rutdxtCMwgC zyxuyWlfisiwFgpBTiWF7DjB0xwIS06oHJLGPg1kL7PvmpNha5cqBmHMfw05 DVu9tGGA8x/CuhPNEIbwzCLCwpOSQmVYWytPNIVvWCOFICc1qRj4siE4vPwS kNPANUwVgzH/NeQ0cBWTZojg/Icgp5IhpAKeW0SQk6bwDUulEOSkKWLDWikE OcnBSsj9MKSU9+yKs2FrmTYMxvzXkNOw1UwVA4PzH4KcNIPP4NlFBDlpitiw ZApBTiVFxA1rpnDXV/bsirNha5oqBt+Y/xpyGraqacMA5z+0RZYkjGJ4fhFt lSWJuGHpFNoySxKFhrVTCHKKZB88DHgYBeAye0hOw9Y2VQyxMf815DRsddOG Ac5/CHIqGSIWwjOMCHLSFIFhCRWCnEqKmBjWUO0vJ0EiEYogiBgHV+FDcho2 77RhMOa/hpyGzTtVDBzOfxhPnpQMgYDnGPeXk6aIiWEZ1f5yqiiEYRkVgpxY qAbwcRRQ08NFDTkNm3faMBjzX0NOw+adKoYQzn8IcioZYsLgOUYEOWkKYVhI hSAnTREZFlIhyEnNzUUhi+LI9AxS46mCYfNOmiEmxvzXeK5g2LzThgHOfwhy 0gw8hucYEeSkKSLDQioEOa0pOGGGhVQIcgoEDf3VTITpWaSGnIbNO1UMwpj/ GnIaNu+0YYDzH4KcNEMY2HresqQICDUspUKQk6bwDUupEOQke5cyCcoRC+/7 BCYfNu+0YTDmv4achs07VQwRnP8Q5LRmiAkVth7DrCh8w2IqBDlpitiwmArh CTpCOYkjRijp+yQmH/gMXcVgzH8NOQ18ik4zMDj/ITxGpxl8autxzIoiNiyn QniQrqSg3LCcCkFOVPZgg8iXN+zeT2QOm3eqGHxj/mvIadi804YBzn8IctIM UWztscySQra4tecyNUVoWFCFICceCcFlFzby+z6ZyYfNO1UMsTH/NeQ0bN5p wwDnPwQ5lQyrZ3AsyUlTBIYlVQhyKink6NTWA5rbj4v37YoPm3faMBjzX0NO w+adKgYO5z+8Z8ZXf8e2JCf93DsxLKlCe2qcMmFYUoUgp9BXfydSf+3v+6Am 38wKbXxuWuRUMRjzX0NOEEOLnDRDCOc/BDmVDKsOoCU5aQphWFKFICdNERmW VLVppktNJYU2dKJiW7GVYxSq9RKeD5V+lmQXFtseaRvYkqOTJWur6iTW3zWQ 9hTb0lufCt4rbNSjkuYq3ivo69C7ldymYQR/qLqY96jrEl4/04Itati7CVHc XfZTtg267LQAquq7/LMQ1A+3QlsUINhb4UWBho+3TfUQowC2nkKMgi73LNv+ YnZaADUKuuy/EKIAboW2KEBw58KLgmoEsW0ViBgFsHMWYhR0mX/Ztkez0wKo UdDlXoYQBXArtEUBgrkYXhRU3mLg6MGW8RdiFHR5l9l2d7PTAqhR0GW+hhAF cCu0RQGCNxpeFGhfMQIOO2z5liFGQZf1mm1zOjstgBoFXd5xCFEAt0JbFGA4 uyEOjzW+AAce1kzXMAfIXc5x1u31LLUC7hi5y/wOY5AMt0RbNGBY0yFGQ+VM Bw5ArLnGYUZDl/WddX9AS62AGw1d7n0Y0QC3ROvMKYa3HmI4aHwKjkSsud5h hkOXdZ99h0NLzYAbD132gxjxADdFWzxgmAMi/l1M4/vgkMSabx9mOHSZD1p3 aNw/GsBWwI2GLv9EjGiAW6ItGjDcDRGjoTI3BEcm1owHLfxpzeieaN1icv9o AFvBxl/XzAaQiH9eq7VEWzRg2DPiRcPGnREcmVhzTkSMhk77R+semXtHA9wK qNHQ6WCJEA2GlmiLBgx/SbyBQ4UfgAMTa9aPmNHQ5V9p3eTTUivgRkOXBSdG NMAt0RYNGAaZiNGgrSUJOC6x5l2JGQ1dBpzWXUottQJuNHR5iGJEA9wSrbNK GA6fiOFQ+XuCAxNr3puY4dBlIGrfZ9VSM+DGQ5cJKkY8wE3RGg8YFqWI8VAZ lIJDE2vmoZjx0OWAat8o1lIz4MZDl4srRjzATdG6UhXDYxUxHjQ+BQcn1txP oXiwZeFq3+nWUjOA8dC3lijp1RBgPOzNsdsUrfGAYRKLuHZb4/vg8MSafSvm 6u0uD1r7Vr2WmgF3BXeXjy7GEm64KVrjAcPlFjEeKo9bcHxizX8WMx66THTt ew1bagbceOgyAsaIB7gpWuMBw6YXMR4qk15wfGLNQBczHrpcgO2bJVtqBtx4 6HIyxogHuCla4wHDZxj/WbcwAMcn1hyA8Z92M9sY23d7ttQMNp54M1sx4z3y Vm+K1njAMErG+9N05TBMwPGJNQtjzHjo8mG2b1e9fzyAzYAbD11e0hjxADdF azxgOD3jxcPG5xkcn1jzYEY1vOgwkrbvt713PMDNgBoPnWbYKLYYYFO0xgOG VTViPFRG1eD4xJqJNGY8dDlh2zcM3z8ewGbAjYcuN2+MeICbotUjYNjMN+y1 jTd+qPApOD6x5oKNGQ9dVt72Hc8tNQNuPHTZkWPEA9wUrfGAYRaOGA8a3wfH J9ZsvDHjocuL3L5lu6VmwI2HLj91jHiAm6I1HjDczhHjofI6B8cn1nzIMeOh y0zdvue8pWbAjYcuQ3iMeICbojUeMOzaEV2VKrN2cHxizUgd01epyw3evmm+ pWbA9VbqcrTHMFeCm6I1HjD85hHjQeMH4PjEmhM8Zjx02dnbd/231Ay48dBl yY8RD3BTtMYDhmE+Yjxop3kCjk+sWdljxkOXH7/91xZYagbceOh6pwBGPMBN 0RoPGI7/+C6UlIPjE2te/BZ8KI0vFLD/3gVLzWDFi9L4UgREM8paU7TGA8Yr CxDjoXphATg+sfYyAcx46Hojgv0XR1hqBtx46HqrA0Y8wE2xHQ/1F2xAE9/6 q/l+DQpaaFt9lQPSmwb2Can2Fw3sE0o93zOw/ws/KGO2XuHY8y14gCK+2dXZ JTUprTWXfLnUUJ/n6PH2iS+F3lXFBvr8da0ien2tkdXpqloW+l1kagM2uK/7 wg3wjaD7hQrrUjQUK+jQ6PV9mxRFOkvmN5PR58PfKAnDKGQ8oFKnMWF/HHmv f7y4eOLJ4uQrBO2fKxX8qRp6J7BO5fjYl+j0sspQja/G9lb0gXf43rX9daIK vT7MYRXLcl8lrP41l0flcIhX1+eyxlfOGviB/ZXSxp/41L/Ciw8tMSBewsYg AF5fbYsB5xLWYYX/0t067k3+ORsfygbo+Ki8mc7HxVSdwouL719evHvx48sV Elh2PJ3nSU/c2TKbje4PyYMgLFDvW9Lde6Bs8pAWV7eL+VKWbwM/8f7j4BH6 5+Emv1ok96N08ax4KPDx1UfermREiEdk/al9pzzw6SNZRE3LcMqpLM+EHzzy iJ3T2f0s82K08LxHi/m89fK79v9JP5v2944nycfj2YR4f/WOi9n98a40Dg5+ uBvliUe9p95Nmk28kfz3MVmkN5+9fHmfLK6n8/EHGZFlOSbLLfM0u/XSrEgW 2WjqTee3B1rNT71fk8VcbVKHbLbm41Em8adJ/jkvkpl3s0iS/H40TlZ8aTaf JJ4MrVwddT2aePPs6STNP2ydghdLGLVrNrpNx162nF0nC5nE0tlo8fk4T8bz bCJ/2j1CbryZpuNCHnr6anvXbTKfJYUsnmY38wNdLPc+pcXd9nnqcgcb5n/z yAPxbuYLb3R748WrPbLC8nSeqX21PXnyP8skk9fZ3DVNslvJtrX5yMvv5svp xLtOPOFzFgeBMDCnRubUzJzuMu/sALkXSZ4Uq1rPr8uiEmKzVZ01uDndbF5v uM7mJdt1oX5WcXckt8sfwSLjrGgvIzVzDRQBhEPJYOXIQ+xLhxKjdspdoHjK fQ31UDJIPkb2tIU9rbHv7uktIQkCaqi2Pd3a3qkiuExNRkChho7KMpCQ6HAh 0a8hJGoWEm0REjUIiQ4Tkok9bWFPa+y7e/oLiRqERA1Coj2EBJapC6lZqCkk ahISGy4k9jWExMxCYi1CYgYhsWFCMrKnLexpjX13T28hMYOQmEFIrIeQ4DI1 IQGFGkJiZiGx4UJiX0NIzCwk1iIkZhASGyYkE3vawp7W2Hf39BcSMwiJGYTE eggJLFMXUrNQU0jMKCQ+XEj8awiJm4XEW4TEDULiw4RkYk9b2NMa++6e/kLi BiFxg5B4DyGBZepCahZqColvje1u5ks5hlN7y4Hc+G6ZfSjHi3xVYOElo/Gd FAkwKlQDwPE0Ga1raJlN0+xDImsvzYvVcDBZLOTxN/PpdP5JjTvVoGK3GFRE 9uC7y9DuMqxPGdajDK+V2dTC/WI+TvLc+5DNP2XrKsxXtSLDSVbdrKxVGbLj uZTi5906XLWHmnBqbKLNTay5iTc3ieYmv7kpaG4Km5ui5qYYOFXo9IHzp8AF UOAKKHAJFLgGClwEBa6CApdBgev43/a+tcltG0t7PvtXsLxf7Fk7xo0gmars rpO0U13jsVO2MzO77akuSqLcKqulXlHt2JvMf38BkuBNhxAhAZz1u1DK6aYa eA4APji4HZxDgHoQ6D0A9SBAPQhQDwLUgwD1IEA9CFAPAtSDAvWg7Xoozm6y X9dfampm1VZO3uwXMZF4fpOJMUFqgcX9nRgI0n0WFONE3lMH8mhMdJf7u1bC 7PM+EwpK9plu6lJnrLf5/l9LDfRotQxWe5FBao7HQS91XYaqg83X6epWStOX yXcv372m6l5ljwnFd7tsdr8SkwQxq7rJ0oWYfxQDwl7umnb5Wc4FoJ1aXrO+ GpW3m002368+rfZfAIyi54k0srflwXYpvk3X8qQ6mK32t+ldUYD8/lZOCKs+ 1ILINvn9TiIUva+YEQmIVudcrHZC+FZM9ZpM+11aTK1EttacUG7cF4VJ98Gz Xi+ucqRruVe9ym+EwgETFNnXazHkpvu9mHlksuizovmGEPMhyNvtp0JNSB1X tGCt5YL9tl3Fpukjka3aQy9mN9udrHwgh3/xcL8pJzaL7SZzcPTT2///JhdV nGcOjoG05z+UchqF9fkPY0SkF9/4859JPtnnbP4pe/Tw2X2+eyb0Qrp+ls9W m9bhz8MnwdXDzuNDdVL08O/ib8/+KNRU8CkVquePz/5e2qOI7nSbPfpNdNTv Hr5cbe4/i1yyJ3z38FZ0stUmE8+C2f8oU892H/VHn9VHpP0co0yy5sF2vbi+ lWes0ghGHQL//Ob1u+s3F89//L347a9vLt9dPAn+/Pzn65/fXP7l+buL3+Xv z1+9fvWff379y9snwVNcnRzLk9ri3qpAvss2oj2y/fzZevFNvv3mbpett+lC FPn19ZsfX796+Z+Py9I8xcHFq9cXr94Fj15thd6Yl0vWQM5flBZ7fIg3l3qm jxYUU4ClIOOes0di9fdbvr++lU329vryxZuLn36XXUgsCvfX+ep/su8wjkgc tlux1yIqQd0mnYZ4EtBOzSNZ8/KEm4464a5qtV7Nnu3Xufw5l3Xjh60kl6Hp Qlbp4XscRRcvXxQmIpDZHa3+NQ6B0V9b5j7KIEHbSlEYtlpJhmOVliVAM4mK k1IRSWMfjhk+ZNDF3y5+GG63KnsXEpNlBUnieCwlX1z+7eLHEvtzCaBElE89 EZQUImLEkJEEHf0rVDMSOOiEVHqxfyDmGdf7G0mc61T8/9FvYrKx+3Jdbjd9 Kzre038LhKyZGESv08Vi922Vl8SiRdZivr7/tjQmkmTIPlxTMpNfPaknLt+K dAW8VIDX2836y7cq5/Vqc32XfshymV5m3mz313dy7rPZy0T3eZbO1tm3uGJU y9ij7Eiq8z0GWqzsNoWyFV2nULhZ9eNpuhO68VNbNfz++vrl8zc/Xby4fHnx 2FBDyKDcmMv2aMgvXxap3hZBSYRDMlJD0FC+lm5+FiOkz/45zrCCICXEKcq+ yCOfcNEzjuXBJ8jB/er1yAxVLiHLunL8VA0qqZDfCJJ3yfBNul6leUebGg44 PY5lm+tf3j57+cP15Y8C4PLF5Q/P312+fmVVgiX4D2Ks/HUhBDwcMJuqW5E8 qLpDMyXp9YvvX/5J9AuOin6xE4m+u00/ZuLno0TSu905LELJSeVeUDaRHQR9 ni2Xyyxkh3QsW+Ty1V+evwweXW4+iZe+CNLdh/tboWvqdm7KA+uFQjH832uI v77pNUNQ7JlYLH1tHlioQIZJhJtaSOvgVndWiplZEReX4kgjLuqKa1suvn37 Xz9dvCuzLZZ81m7ewnLxRnQu2Z2O6KXGytFIg414K7SjWjEisYWpQmlZeZKi rweUcNSAcsrAFXbkRKPkRCfIiTpyklFykhPkJB05s1FyZifImXXkLEbJWZwg Z9GRsxwlZ3mCnGVbznLUBGZ5wgRm2eH1ko6SQ0+QQztyRvWfItWD0txbaLSH xwxJlV13adLdUR0hiWnMztUclNP+dM8ScFasXq7X6zzLPspJutD7V+jvT4K3 Fxd/un578e5xr3maxfF51vuEVddVyt/ai5KyUKqKwKLEkAEdzbbkoxjAe82C 41DMmMUSJZJLlqv2Y6ex7LUQqRygyp/tktTRD5hcrl+1HycuSeMPhIpectV+ nLgkERNjKyaYJZEYpa/ajxOXJBGcDXGI44jIntR+nLgkGGMx5cAxIYwXlG0/ T10WkiQ8IZhwgiRpO89Tl4XFcpONiSLIzYSrzvPUZeERRpRElHI5vbzqPA+X RSfw5KK0NBrqaTgNdV0URTwTKtqAYSxHuKvO88RFUYHumejJsijt54nJUodj j7lcZ111nqcuSx0Ku9iFvuo8T12W9h1AWZb289RlqUKbiuZABXXbz1NPFFRY SUHXYqbQfp66LHXoQypPN646z1OXpQ47h6nkbuf5nziZQ73Z3NTcrcMtxWI0 lGVpP0+rdptIN5RL6naeJy5KHWQEywvHV53niYtSxS2IEzE2y6K0nycmS+0z nnK5VLvqPE9dltqvOS0WZ53nqddEtU9pVCzPOs9Tl0X5qWVxuUBrP09dFuVL VfpLkGVpP/8T162ot3CdmrsdHwyyLO3nKcrS3ncpdpk0+y42fUO4CCMnI30I pSgmoUkTn6ZzBEy4mCtzF/txlqAJLu0JHEBTviCOoNk8Qo6gOSnO1F1AR1E6 dwQdL1jqCDolWewIehbH3BH0PCOueJ3RuSteLxPuiNchypaOeC3VnyNehzSl jngdsuXCEa9D6Z/XEXQ0w454HSZo5ojXYcpDV7yezTJXvF7g2BWvs4i44vVy PnfEa44FjCNouc3pCJouUke85mExeXICzeOFI17zKIsc8ZqLCbEjXvM0mcXQ MTnsR+n95qHcHS2WHUkrj1pedNwrlYmLGTzpLBBoxAuXfSQi4p/yuY17Pwnr ftH2F1fsxwrVGjMngawlvphDYRJWofQc4EdJYSerCYRxJr5YRnE5W3OFL09n VSgpF/iUkUQbGOFcfIQRIZGz9he6V0ancNb+hCdiSqQJtHU2PqOEaAI9no2P IzhwkS18JAOgu2v/MIloCAW6t4bPBEvdtX+YEEZDd+0fJhj252kPn4AuT+3h y8tZg/j1gCXGqpAE8vfNL0b4KE6gQNjWyo+SFj8Nza14x9xqlCFpkcrWQC9d LAMjvfx6YhGu3/ZE0yHLFejMRSN5n/bMmehsGXbM9fqvpj6Hr54PttUPQvac 1IEIJ7gcVMvfPKyH9bAe1sN6WA/rYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pY D+thPayH9bAe1sN6WA/rYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH 9bAe1sN6WA/rYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6 WA/rYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2s h/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2sh/WwHtbD elgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2sh/WwHtbDelgP62E9 rIf1sB7Ww3pYD+thPayH9bAe1j7s7f3mNr17hD7z2TLkCCGRJkKU8sdB5/Nd gB7ctcpAI/6ehuF7EhHxj1dScO8nYd0vykJgRAQGSSIUkTBBMYuRLJH8uqom ESKU5KdBPk83wXK1zvIv+T67DZa7LMvvSqywqEzIHtztsnRRlO1vL95+X0pv Vf8v9+8JZcPNo8oWYiG7KI74rQ36/KcXvcoJAe8Jp++JaAbU+xs5wBT/A1Ev j6P+R/ULVUlbsLLRDnGrhKq+Ckm9puhoC+BQMqCEne0+PkI9OkAfQZHPMVpG gkRlHvkUiydN3iqPTNUq/vPv331fNwaNIu2/qk3q8jOU8PL/sgLyZxf5hzOR Y5wQAPlSQNevcgwyabV5iYwJieMa2rDZ406zJ6OaPek2+/kdB8chF9oD0YgB rAT6EDbqQwqekZCP6kwQvPqPDsNHPHbRpyr4kMSAgmlxfhx/CmaSDn8qAVHM kJ77Z0rAOKFQ72r1ATRSQr8LVAI4olAnO5+hNMKUIY4iFgPvGGAoMWKogi/V 3giGQvDDDK3hwdHkbIYq+AQcVCwwtBKAcRgzNwxVEkIeQ33gfIYqAUkUQV3g fIaGYYQwSjAmFJ4x9BlKzeYhCn5IRfcZCsEPM1TBE1BFn83QGh5U0RYYqgSE lMRuGKokJIxAfeB8hlYCCA0J1AXOZ2jECI+xWD4kETwM9xnKjBiq4MMhFd1n KAQ/zFAFz0EVfTZDa3hQRVtgqBKQiNWTG4ZWEogYhqE+cD5DlYCIcKgLnM/Q hMQ0xCGOIzJuLRcaMVTBJ0Mqus9QCH6YoTU8qKLPZmgFTxCooi0wVAkgMT6y BjtXAk/wkbXYiQytBFCMENQFLKyUMGaI4JgQxsctlbjZUqnGH1LSfY5C+MMc rfEpqKXPJmmNz0A1bWO1pCTwkLtaLlUiKOKho/WSksCi0M2CCZMk4QnBhBM0 bsUUmRG1xh/S1X2iQvgaoir8CFTW5xO1xge1tQ2iVhKo3JpwRFQlgjHkZtlU S4gZuDFngagsDiknTAgKxy2csNkOrhIg3sKAyj7YfoIEaKhaCwB19vlUVfgY 1Nk2qKokMMQcLZ9qEXF1kGGfqpUEJsZmqDPo+DiOqTzCiJKIUp4Mv2cL+AxU 2RbxWyq7ObiZpYtgu3m6WOUfg/z+LtvN1tv5xyAJngbyT7dVW5cvr33ic7db 3aa7L8/ybL7dLMRv3exzdXoUlqdFYU/mbfphNQ/+JUCfUbDc7oL0wzJI3m8e ylOv8sSrl+FTtstX243MMi5Dnv33fbaZZ1COqMgR9XKss82H/U079ZMgv9ne rxfBrGoHWrQDPVqZlWlljmQAKrMaVZlOelWdqjLFq2HtN7PL8mxfvPh8VmVT UgotTQiYWLZVN3XRToQOpF4dTV2mm222VfFne/n7brvdPxHfb7ZlDWhRA9rn Vi/jfLNvclYZi1am/VZuZ1xttrP9sMTW8Sowluw1Q8nILtoV0B8NTxXQ1jEt AeeP5661ZOusangjyAY+OB+xhx+3piNHtTBGlRoe7LBaLSyyKy3MSy3cJzyk hcUYrlErkBrW5wD1sMpSsJHExxQxRrUmHhyQhhSxaX2O5QBV8aj6dDNUNarq U06z+RFdrMTo1euyn7y0IWHHtPFw8pHq+LhWHVDHRUvTfkuPUMdKol4db8y0 JdRX9er4RAEdZWNVHTtWlwQxQoWyZxjHw7ueNvDdDCc1PmkNiMfVMT5PHeOT 1DE2VsfaHLA6xmbqGJ+hjg3rcywHrI7H1Keb4SR1jM3UMTZTx4PJv3J1/MlI W4J9Va+OTxTQUTY21fERdWlBACExYpQzlpBx+75Lo920Gj8ExxPgHUP46r/D zbQGXzf9Pn0zrcbn4G6ghc20WoIyx7G/maZEhBSDtgLnb6bVEiICHgZaICrD 0iYnYTGPxu377syIqvATuKcdEhXC1xC1xtdNTM4gaoUfInA30AZRlQRlleOA qEoEj0GTAQtErSRw8eTGbIaESSIWACQUosbZzWCzM99GwJDKPjigMDv0rQVQ 3RrgDKrW+KDOtkFVJUGZ5zigaiWCSztNN1RVElgEHghaoGoUhyhkYcgxH2dA g81OfRsBQ0r7gKpmx761gEi3nDyDqjU+qLVtULWSwJWdjgOqKhGMgtYDFqiq JMQMPBC0QNXiGhGLRZ9A4wxpiNmxrxLA0ZDaPrDpNjv2bQSAavt8qip8DGpt C5dtagnKWMf+rZtaRAxf7LFA1UqCmKiCF3ws3D3AIRcjG+ZiTj/y8oHZ/Zha ABtS2wdUNbsh0wgA1fbZVK3xQ1Br27iBoCQocx0HVxAqEXLkcXQHQUkI4Xs4 Fqgqz/V4KF4zTcYtqojhRZlawJDaPqCq4VUZJSAG1fb5VK3xQa1tg6qVhEiZ 6zigqhIRwhdyLFBVSUjgCzkWqCqWnRENowhjOm5ZRcxuzDQChtT2AVXN7szU Agiots+nao0Pam0bVFUSQgLe27NBVSUigW/mWKBqJSGm8M0cu5cPxy2riNnV mVpAOKS2D6hqdnmmEQCq7fOpqvA5qLXtXUFEUZyAF/js3UFEMYWv6Fi7hIji CL6io+PjOKbGYjkVcRrFXONfwAJ+Aipti/gtnX30NJacdxpLTjqNJcansfoc 4GksMTuNJWecxprW51gO8DR2VH26GU45jSVmp7HE7DR2OPlXfhpLdPfdRnZW /XHsyRLa6sbmeaxrhclQzCLGeUyoxjmFDXxwamIPn7ZmJscVMjlPIZOTFDIx VsjaHLBCJmYKmZyhkA3rcywHrJDH1Keb4SSFTMwUMjFTyIPJv3aFrDvnG9lZ jyjkEyV01I1NhexcYZJIHggkMccaXyw28B0NKAo/ag2JxxUyPU8h05MUMjVW yNocsEKmZgqZnqGQDetzLAeskMfUp5vhJIVMzRQyNVPIg8m/doWsO80e2VmP KOQTJXTUjVWFrFeYFgTIs/I4InESD7iHO/CcZHYSrAQkCBxSIN9JZifBjQDd JPz03bUaH4PbgxZ212oJyoLH/u5aLSKG7xifv7tWSaCIwFeMLVCVMxyFxfHd gJ+4A6qanQTXAhjc2QCqmp0ENwJ005MzqKrwQ3CD0AZVlQRlweOAqqUIjnB0 zGfoqVRVEsIYPCO0QNWYREJ1x0lER/r0pGYnwY2AIbV9QFWzk+BaQKxbCZxB 1Rof1No2qFpKSJCy4HFAVSUiDB259qwlJNyRb88QYYqSmCCMRjr3pIa+E2sB Q2r7gKqG3hOVAKJbVJ7hPrHGB7W2Df+JSoKy4HHgQFGJSIgjH59KAqbUlZNP LObyPA7FFGasl0+zk+BaQDiktg+oanYS3AgA1fb5VFX4HNTaNqiqJCgLHgdU rUQIOrly9qkkRPANHgtUpTFjVAxtcTjS3Sc186ZYC0iG1PYBVc38KTYCQLV9 PlUrfIxArW2DqkqCsuBxQFUlgsOXeCxQtZJAEHyHx67r5JHLKrMbNo2AIbV9 QFWzGza1AAqq7fOpWuODWtuiA2WsLHjceVCWkww3y6paAoPv8FigahRKWzZp qD3S/ydtNvSaWCEaqtYChtT2AVUhARqqKgERqLbPp2qND2ptG1StJBTzeUdU VSIYfInHAlWVhLh9hwcKo7Pc3m8WxYa13LteZMH85n7zsdq2LvbvaXv//ueb NM8CWmTcBVk6vwme/yQSlzvyxcEPCUFBRbyeVMiar7O0PFy436hjhWJjnUV6 KgLbpuZBcBzHA3EczMGxJ37HbtQd+8B27b7YtddZ575C3TiQazp7ttsJpbDc rtfbX1ebD4XjPdnJV5uP2SJYryqtMp1rO13NLfhq0tYco1bVjY4BbXiR0tXc glsUfc3xqTW34bBFV3OrzkJc+3hwfjPf+X1q57dgnd9ddH7jzPk9Iee3OxxZ +mo1DDlZw1gxQtbW3YJRnb7u5OS627D309bdgv2Kvu705LrbMK2ZzqjD+VG8 8wNU58dezg8rnG8xO98YdLSdA63u73bbeZbnwcfN9tdNuZOQB2mJxIu3x+GM 0khO/LX0CIuTx2UgUpyYRjpNOpFOF6MinS66kU4vXz0vohfjorXIQfNUmqT/ TWW7ysXLlpsOTJ2IFN84h2+0nhN8zSvDB69Mk5iYJKYmiZlJ4tAkMTdJHJkk jk0SJyaJlWvlgv2i2ZE2MTZJTEwSU5PEzCRxaJKYmySOTBLHJokTg8TE5A0S kzdITN4gMXmDxOQNEpM3SEzeIDF5g8TkDRKTN0hN3iAd9QbV8LrJfl1/CRar fL79lO0Gr1uUu/RMZJzfZPOPxV794v5uvZqn+yyYqV336ngD3q7P9ns5676/ a+XMBm8BNBnL7f31Nt//a3m28Gi1DFa9jI5HRbBcdUtUs5P5Ol1VYWeq6R9c ocEZyj+hEn7o9UOvH3r90OuHXsdDbzmChiLxLpvdr9aL4PlPwY3Q99kul6fY 1XhWnq2TB7f3m9v0Tqw9GaKcimWlPD2QXkzlkUzrI4aR9pLtBC+LrHvQH3fc EnaQTZ0r9pAxIe3LA9prZdDelxrtoH2XgevDBgf+9YHF0IF/a13cWFOMM9gg rQJXVupt95LNu5ahMU9512PtRlgvyGF50odxx78f+M7PlMARBVkFufg1evW1 8UTb/EDLAd2uJx7GbxtngFQ4NQxkJSBqe3FsGEH5gkzIiOpoBocdN3o2GaEk JFEEcg66Y2rEiNrepW0xot/KN2IEaE9jkxGqhXDbWWLDCDaP0ISMUDvCScdb nU1GVBIIDQnIOchI0Wx4UJvabSMfLSN05wqHjABNoGwyQgkI2z4JG0ZwgrIJ GVGZZBHacQpnkxFKQlmXUYyADmqGGaGsysK2WZaWEbqDoENGgFZrNhmhBCRt 138NI6IonU/IiMqKjvAEH5s7nieBYoTGTiGhk7VhRtSGgG1DOi0jdCd3h4wA DQ1tMkK9AxJjaGYZL1g65cyyMnykiIeuppZKBIvCsXNL6DBUM7dU1pukbfyo JYXutBWYXILmoVZnl0qCeA3Q9DIlWTwlLSp7VWk+5mh+WYuIWTJ2ggmZcmho oYxu+WDQYxOrXoAWoFWvVVqoRpIrG4AWszjmU9JCWRnHHU8YVmlRiWCEsLGz TNBWWsOL2lZ6MPqqkTU2QAzQGtsqMZQE1vZ60hBjnpFJNygqI2yGY3jryAIx lIgwicdONiFLcg0vjsUwNzNVB2hxJAq7BVooCVHbw0hDi4zOp9ylqDdlQg5v K1nbuEIsicjYGSdkZn9852owlrKZHf/w1tVQNGh7e1cMt715NLRYSjO16WhR m+8nFN5bOp8WSkQo+9pIWkB3EIZpcTSmq9klh0NaHItKayHEkZIQtj1n1LQI Ubaccr9iIPqoVVrA4Ue1tICujmhoAcax1dJCdzcFoAV4N8UqLcBAsw0tCEum 3LQYiPVplRZwsE8tLaAbPxpagFFjtbTQXSkCaAFeKbJKCzCsa0MLmtIpdy4G 4mpapQUcWFO/FjHbuoBjtOrXImZ7F/BVMKvEAIOoNsRgy8WUexcDUSytEgMO Y6knhtnmBRwRVU8Ms90L+AqfVWKAIUsbYkhXFBNaTAzEjLRpOjEQNFJ/amq2 ewHHH9Wfm5rtXsBXL60SAwwQ2hAjmuEpdy8GIjRaPU2HQzTqiWFmYQFH+9QT w8zGAr4ya/VIHQzH2RAjQbNJrSzgeIhWiQEHRNQTw9DQAoytqSeGoakFeNXZ KjHA4JcNMVIeTrmDMRB90Cox4PCDemKY2VvAkSz1xDCzuICvqFslBhhqsiHG bJZNuYcxEOvPgWFWP9ifnhhmZhdw3Eg9McwML2DXAg6ss3qBHRtiLHA85S6G 8icgZp/wzpMFYlQiEjRg3jE2cJqGGMcCpxn6XQCIcST4mwViqDdBIgJNPrOI TLmPoZwtJCiE957OJ0Ytgg0YeYwN4DRMjKMBnAydUhwS41gQKgseyZUEzjg0 +VzO51PuYyhPFAmj8O6TBWIoEfGAmcfYQDIaYhwLJGPosQMgxpFgOBaIoZoJ EQRMPjkWfJiSGHDEE6vEgEOe6G19zfYx4Og5emtfs30M2NOKVWKA4W0aYshz lCmJAccXsUoMOMCInhhm+xhwrBo9Mcz2MWAPOVaJAQaTaYhBF+mU+xgD0Tys EgMO56Enhtk+BhwZRk8Ms30M2LORVWKAoVsaYoTFvbLpLo3AsTOs3hqBg2fo iWF4bwSMw6InhuHNEdAjldWrI2CglIYYPF5MuY8xEKnCKjHgUBV6YpjtY8BR T/TEMNvHgD2JWSUGGJakIUaURVPuYwzEhbBKDDgwhJ4YZvsYcIwRPTHM9jFg D3BWiQEGAWmIIeZPU+5jDERhsEoMOAyDnhhm+xhwRA89Mcz2MWDPfVaJAYbc aIiRJrMp9zEGYh5YJQYY9OAIMSB/iBpigPEz9MTQeVwEiAEG0LBKDDDARSmh 6yejjL7cROr+porzQItstO078azYJ2W54NHfJm5Tx9K9B6/dQlWhL7abTTbf rz4pT/XFC6DxcOMULrJEtn222efBdlmF/eZFPAse2XIRJb18dDxEyS/cgkNV zjb5/U7WOPu8yvdFcPG6ymERKySkU1XZsrsQKPaKFW8hTpvjg2TgbbZdLtIv j37DKIriiDAcizKECP3jSfDql5cvHx9o8/MDFY1cX/3vdODilqGtcn9lXX6w 6HQA/eB7U4Wy36Wfsl0uVcpytc7yL0Kr3CqFgksqDNbZdanStSjUZpXfZItA IFRDQkFQCnvna1UnXa+D+02636fzqjpll4EdUtUS87bISqIKlwJlvN1+ktIK h5DF2CUyrjaVxEOnhuWwF4mMQtxq+aWMx7Td7UTOYK0yVnv9w76LrbT8/w/g X8WsZ5l/2cwfdaf30EcOEqvtfL+WRfj+5Z9evHz7/S8vCiQw7Xy9zbORuA0F F9tNVkwiQyij4OsDMbnYX3/Ybe/v9P6/vwv+/cEf/OfzMr/eZXfpandNNotv 9p/39mWIhSTijP0BlZ/eT8wQJX8QSWRQPsYi8T2mhJA/BMh+UQ4/9/k+3QXB H2QMO126Y3//Sj+5GDzERPzpNni2v7171qND+VfJiqD5S/BskX16drtADx6U IwKW8fxWYiyQ40E1NHSWfVU6ItLdF+PbSix5dhsxRK63Hx4049H/ZLut/Epm ab4tQv+1BvjlLsvyO1lqKa9ce92md7nMNUsXwXbzVIxoH1tFCBIBI/90m35Y zYPN/e0s2wlFvLpNd1+e5ZkY/Rbit24O8eVyvRIj21PpvLH1pw/Z9jbbi+Sr zXL7QCXLg19X+5t2OVW6B43kfwnQZ1R4EU4/LIOk+Esx5m838m+9v+TZf98X y6TDP62zzQchrfX1kyC/2d6vF8EsE9N3ShLO2YDk1aDk1bDkVVdy5w+g7HL5 X6DNqqQCovlWlhr8etV8XX4x22wrabO9/F12xSelG04wyXyz16cRnJkBSQDi YGTMHJHFPXUwGuRO9SeQPNXfDtiDkRF9BqWvNNJXPendv4ymkAABOdT7ftX6 /iiL4DQ9GgGJDnhUpYGIhM2JhKcgEh4mEtYQCQ8QCZsRaUj6SiN91ZPe/ct4 IuEBIuEBIuERRALT9Il0mOiQSHiISMScSGQKIpFhIhENkcgAkYgZkQalrzTS Vz3p3b+MJhIZIBIZIBIZQSQ4TY9IQKIDIpFhIhFzIpEpiESGiUQ0RCIDRCJm RBqSvtJIX/Wkd/8ynkhkgEhkgEhkBJHANH0iHSY6JBIZJBI1JxKdgkh0mEhU QyQ6QCRqRqQh6SuN9FVPevcv44lEB4hEB4hERxAJTNMn0mGiQyLR1toOjh// YChOfH9VeBAQXsWKzvfFcvBYSOl8DyXpxF4eSoOPpyFj0pARaWgvTdMKcOA8 0SqiO4mmu61aVYX8+dJtQxWb5vArfPgVOfyKHn7FDr8KD7/ih19Fh1/Fh18l QFGh4gPlx0AFMFADDFQBA3XAQCUwUAsMVAMD9SBAPQj0HoB6EKAeBKgHAepB gHoQoB4EqAcB6kGBetB2PeBoVFm1lZM3+0XDEajEOJH31AEYcOqzPFkv+kw3 NRxlal+eTOePAyB1fXAtf3nYZH1YFruVfJGts/1wclEiMWi10MHIUsW5jLbG vvP6zjtV5z0WzybYyz3ZLj8B858Hxwxn9l8AjAMrmV2WrqXhQjBb7W/Tu6IA +f2tnG5WfagFAVudtLr+YiXPL7edPgmfLMuTgqIw6T541tMR8KkvDNk63ZXp 8vtZ0XxDiPkQJHx8W+iQ/bZdxabphw9vP4qH+005bZKnbP5w7P/EZ/DAx6IM 7fkfpZhjVp//Fd9jxqLIn/9N8ck+Z/NP2aOHz+7z3TOhptP1s3y22rQOAh8+ Ca4edh4fqgPAh38Xf3v2RzFqBJ9SMRL88dnfHxdTEqHdbrNHvwm9+d3Dl6vN /WeRSyqm7x7eCp232mTiWSiaf5SpzWJ1yxss6MF2vbi+lbbI0kZNWS38/Ob1 u+s3F89//L347a9vLt9dPAn+/Pzn65/fXP7l+buL3+Xvz1+9fvWff379y9sn wVNcmTrI0GvFzR+BfJdtRHtk+/mztegQ22/udtl6my5EkV9fv/nx9auX/1kF dHyKg4tXry9evQsevdoKNT4v9ycCOVlVg8rjQ7y5VPt9tKCYkS0FGfecPRJL /d/y/fWtbLK315cv3lz89LvsQk/EGHSdr/4n+w7jiMRhuxV7LaIS1G3SaYgn Ae3UXEYZqkwy6CiTjKpW69Xs2X6dy59zWTd+2EpyzyFdyCo9fI+j6OLli8Ka 5tCaubSjkf8aD0Lory0TP2Xcp22lKAxbrST9m0sjHKCZZAS2UhFJF/lCB+FD Bl387eKH4XarsnchMVlWkCSOx1LyxeXfLn4ssT+XAEpE+dQTQct7n/JisJEE Hf0rVDMSOOiExd3FB2Lad72/kcS5TsX/H/1WrJquy73Fb0XHe/pvgZA1E3Oa 63Sx2H1b5SWxaJG1WD7tvy3triQZsg/XlMzkV0/qeeS3Il0BLxXg9Xaz/vKt ynm92lzfpR+yXKaXmTfb/fWdnIpu9jLRfZ6ls3X2La4Y1YreWHYk1fkeAy1W dptC2YquUyjcrPrxNN0J3fiprRp+f3398vmbny5eXL68eGyoIWS4B8xlezTk ly+LVG+LoCTCIRmpIah0jdXLz2KE9Nk/xxlWEKSEOEXZF3nkEy56xrE8+AQ5 uF+9HpmhyiVkWVeOn6pBJRXyG0HyLhm+SderNO9oU8MBp8exbHP9y9tnL3+4 vvxRAFy+uPzh+bvL16+sSrAE/0GMlb8uhID97d1DZX0NtmL4oOoOzZSk1y++ f/kn0S84KvrFTiT67jb9mImfjxJJ73bnsAglJ5V7QdlEdhD0ebZcLrOQHdKx bJHLV395/jJ4dLn5JF76Ikh3H+5vha6p27kpD6wXCsXwf68h/vqm1wxBsYVl sfS1PWuhAhkmEW5qIe9XtbqzUszMiri4FEcacVFXXNvU9u3b//rp4l2ZbbHk s3bzFqa2N6JzVd1JbxJ7kgYb8VZoR7ViRGILUwXC41MVfT2ghKMGlFMGrrAj JxolJzpBTtSRk4ySk5wgJ+nImY2SMztBzqwjZzFKzuIEOYuOnOUoOcsT5Czb cpajJjDLEyYwyw6vl3SUHHqCHNqRM6r/FKkO7pEMWw2riwjlHYSO6ghJTGN2 ruYog6y7AM6K1cv1ep1n2Uc5SRd6/wr9/Unw9uLiT9dvL94dXJOuF8fnXasj rIq3Xv7WCSmflf6jyioCixJDBnQ025KPYgDvNUsTD0kuWa7aj53GstdCpPJz Jn+2S1K7+GRyuX7Vfpy4JI3bACp6yVX7ceKSqICzLInEKH3Vfpy4JCqSahwR 2ZPajxOXpIkPynhB2fbz1GWpg1ISJEnbeZ66LFUQQVEEuZlw1Xmeuiwqch3l cnp51XkeLotO4MlFaWk01NNwGuq6KEoTZAzLEe6q8zxxUVRUKCZ6sixK+3li stTBjmIu11lXneepy1JH8Cl2oa86z1OXpQ4ag+Wq9arzPHVZqhgfojlQQd32 89QTBRVWQtC1mCm0n6cuSx2NgcrTjavO89RlqQMAYCq523n+J07mUG82NzV3 ayfksRgNZVnaz9Oq3caxNuWSup3niYtSu3LG0mfHVed54qJUjnfjRIzNsijt 54nJUvt6pVwu1a46z1OXpXaRSovFWed56jVR7ZUTFcuzzvPUZVFOFFlcLtDa z1OXRXkGlK4lZFnaz//EdSvqLVyn5m7jYQ0Vq7TO8xRlae+7FLtMmn0XS55A ei6ValBdzlGY0nu2UIoyVmsTLaFzBFz5/nOwH2cJmuDSnsABNOUL4giazSPk CJqT4kzdBXQUpXNH0PGCpY6gU5LFjqBnccwdQc8z4orXGZ274nUVIt4BtAoz 7gK6ClXtAroKd+wCugqY6wK6CrnqAroK2ukCugr76AK6ChzoAroKPecCugpe 5gK6Cn/lAroKoOQAWoXgcQFdBXFxAV2FAXEBXQWScAFdhSJwAV05s3cBXblD dwFdOdQ+OCaHnWYVPvBIUiw7EtC3Y8uXVpm4mMGTzgKBRrzwbkgiIv7xagmA ez8J637RWiGU+7FCtcasFR3J3gpE4os5FCZhFQLHAX6UFHayLU/tlvHLEEHI VfsUp7NhO/y6ZXzKSNJxWG4bH2FESOSs/YXuleEEnLU/4YmYEjFn7S90CyUk dNb+hOMItUPSWMdHNEHMXfuHSURD5K79RQcWLHXX/mFCWBVzwBE+5u3QyQ7w CeIu21/eDhxu/3rAkoFiSSB/3/xihI/i1g6Xg/KjpMVPQ3Mr3jG3GmVIWqSy NdBLt+rASC+/nliE67c90XTIcgU6c9EIUXqmYTWfLcOOuV7/1dTn8NXzwbZ6 44n6nA5EuIobWv7mYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe 1sN6WA/rYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/r YT2sh/WwHtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2sh/Ww HtbDelgP62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2sh/WwHtbDelgP 62E9rIf1sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2sh/WwHtbDelgP62E9rIf1 sB7Ww3pYD+thPayH9bAe1sN6WA/rYT2sh/WwHtbDelgP62E9rIf1sB7Ww3pY D+thPayH9bAe1sN6WA/rYT2sh/Ww9mFv7ze36d0j9JnPliFHCIk0EaKUPw46 n+8C9OCuVQYa8fc0DN+TiIh/vJKCez8J635RFgIjIjBIEqGIhAmKWYxkieTX VTWJEKEkPw3yeboJlqt1ln/J99ltsNxlWX5XYoVFZUL24G6XpYuibH978fb7 Unqr+n+5f08oG24eVbYQC9lFccRvbdDnP73oVU4IeE84fU9EMzTflD/pAab4 H4h6eRz1P/qt24KVjaZwZ7uPj1DvvUEf8S4/x2gZibdd5pFPsXjS5K3yyFSt 8j///t33dalpFGn/lemYahWGEv4kiHFStIt86gL/cB4wJiSOAeRLAV235xhk 0nqTJbT8f41s2Ohxp9GTUY2edBv9fH7jOOSikyMaMTaK6tiI6gqekZCP4jwE j7ppIPiIx4fwLUqOe7+SOaTDnBIf44RyPTXPFMARhbjfYigaKaBHUNVCUcwQ IOB8AtEIU4Y4ilgMvAKAQMSIQAq+1EkjCATBDxOohgd18vkEqvBxyGOo+c8n kBKQRBHE0PMJpATgMGZOCBSGEcIowZhQeFjsE4iaDbYKfkjB9QkEwQ8TSMET UMGdTyCFnzACNf/5BKoEEBoSiKHnE0jVIKQEGoTPJ1DECI+xmMImETzG9AnE jAik4MMhBdcnEAQ/TCAFz0EFdz6BKnwixhio+c8nkBIQEQ4x9HwCqRZKxBrB CYESEtMQhziOyLjpfmhEIAWfDCm4PoEg+GEC1fCggjufQBU+4Qk+Mj0/TwDF CB2ZpZ9IIFUDEmNojLQwicaYIYJjQhgfN4vmZrPoGn9IxfUpBOEPU6jGp6CO szCPrgRQxENHE2klgUWho5m0aiRRBTdTaUyShCcEE07QuLl0ZEajGn9I0fVp BOFraKTwI1DTWaBRJYAyhtxMp2sJMUvczKdrCXLZ6oZGLA4pJ0wICsfNqLHZ /pUSICowoO4OVvWQAA2RagGgvrNAJCUgrrZA7ROpksDEmOBmXl3XgSEGjZs6 tozjEY8woiSilCfAW7CHz0B1ZxG/pe6aTeVZugi2m6eLVf4xyO/vst1svZ1/ DJLgaSD/dFu1dUmP9m703W51m+6+PMuz+XazEL91s8/VznZY7mSHPZm36YfV PPiXAH1GwXK7C9IPyyB5v3kod+TL3fhehk/ZLl9tNzLLuAx59t/32WaeQTmi IkfUy7HONh/2N+3UT4L8Znu/XgSzqh1o0Q70aGVWppU5kgGozGpUZTrpVXWq yhSvhrXfzC7Ls33x4vNZlU1JKXQoIWBi2Vbd1EU7ETqQenU0dZluttlWxZ/t 5e+77Xb/RHy/2ZY1oEUNaJ9bvYzzzb7JWWUsWpn2W7mdcbXZzvbDEltHP4Cm 32sU/cgu2hXQH6tOFdDWMS0B54+2rrVka4MemLRZxAdnC/bw49Zk4agWxqhS w4MdVquFRXalhXmphfuEh7SwmKVo1AqkhvU5QD2sshRsJPExRYxRrYkHB6Qh RWxan2M5QFU8qj7dDFWNqvqU02x+RBcrMXr1uuwnL8+32TFtPJx8pDo+rlUH 1HHR0rTf0iPUsZKoV8cbM20J9VW9Oj5RQEfZWFXHjtUlQYxQoewZxjGw9rGI 72Y4qfFJa0A8ro7xeeoYn6SOsbE61uaA1TE2U8f4DHVsWJ9jOWB1PKY+3Qwn qWNspo6xmToeTP6Vq+NPRtoS7Kt6dXyigI6ysamOj6hLCwIIiRGjnLGEjNsz XRrtddX4ITieAO8YwkfdNCA+OP0+f6tLCQgpBg94z9/qqiVEBDxfOX+rq26k BIGn4BZoxLA0dEhYzKNxe6Y7Mxop/ATuB4c0gvA1NKrxwWmDBRpVAkIeg8e8 FmhUSeDiyc2OaV0HEoFn4RZoFCaJmDyTUIgaZ4uAzU4CGwFD6u5g693sKLAW QEF9Z4FIlQAura7cEElJYBF4wmKBSKqReAieiVsgUhSHKGRhyDEfZ5OAzc4C GwFDCu+ASGaHgbWACNR4FohUCeCMgie+FoikJMQMPGGxQCQlARHwXNwCkQrT ehYLxqJxpgnE7DBQCeBoSOUdWGiaHQY2AkCVd77deS0gRuCZ7/kG6EqCmCCB Ju4WiKTqwBB4Mm7BzheHXAydmItp2EhDXzNT8VoAG1J5B0QyMxZvBIAqz4Kx byVAajxH1r5KQggbpFsw91WNFEXgybgFIsmzGB6Kl0CTcVNtYmgyXgsYUnkH RDI0GlcCYlDlWSBSJSAKYaNrC0RSEhLYMN0CkZQEzMDLNxaIJObxEQ2jCGM6 brJNzEzHGwFDKu+ASGbG47UAAqo8C0RSAhLY+NoCkSoJMYUN1C0QSdUhJOAd GbtXWMZNtomZCXktIBxSeQdEMjMibwSAKs/aPRYUU9gI29pFFhRHsKG6tZss KIoT8K6Mji3jeBSLSXbEaRRz4uJsqMZPQIVnEb+l746eDZHzzobISWdDxPhs SJ8DPBsiZmdD5IyzIdP6HMsBng2Nqk83wylnQ8TsbIiYnQ0NJ//Kz4aI7trH yM6qPxw6WUJb3dg8HXKtMBmKWcQ4jwmF7gdbxAcnDvbwaWvecFwhk/MUMjlJ IRNjhazNAStkYqaQyRkK2bA+x3LACnlMfboZTlLIxEwhEzOFPJj8a1fIupOT kZ31iEI+UUJH3dhUyM4VJonkNnEScwzdt7eI72hAUfhRa0g8rpDpeQqZnqSQ qbFC1uaAFTI1U8j0DIVsWJ9jOWCFPKY+3QwnKWRqppCpmUIeTP61K2TdCeTI znpEIZ8ooaNurCpkvcK0IEAePsYRiZN4wEPPgfsNs/NBJSBB4JACOeAwOx9s BICT8PP3vmoBMXzR7vy9r0oCRQS+jnj+3lddB5qAh+UWiMQZjsLiYGrAU88B kczOB2sBDO4KAJHMzgcbAeDkwQKRSgEc4eiYp7NzJYTxMY9npxJJNVLEwcNy C0SKSSTUXpxEdKRLMmp2PtgIGFJ5B0QyOx+sBcSgyrNApFJAgsLQkV+yWkLC HTkmqyVg5sgzWYgwRUlMEEYjXZNRQ9dStYAhlXdAJEPnUkoAAVWeBe9SSkBC HPknUxIwpY4clNV1CLErD2VYzCF5HIrhf6yLMrPzwVpAOKTyDohkdj7YCABV ngUiVQLEq3Dlp0xJiGA7dgtEUo0UJ448lYU0ZoyKaWocjnRVRs1cTdUCkiGV d0AkM2dTjQBQ5VkgUiUAc9hG2wKRKgkEwZbsFoik6kC4I49lbZ+JIyfbZnbm jYAhlXdAJDM781oABVWePceJclxwM9muJTDYkt2e68TCJtINkaJQWgdJk8uR nstos0XS9lM9SKRawJDKOyASJEBDJCUgAlWeBSJVAgiDbbQtEElJiGFLdgtE UhIQbt2tgRysL7f3m0WxQSf36hZZML+533ystumK/Ura3q/8+SbNs4AWGXdB ls5vguc/icTlDmSx0U1CUFDhyT0VsubrLC03U+83ahu12EhkkZ4oZ7hH1190 sOiC2rGDYsfuax07N3Xs+tK1W0TX/vKc+1Fz476n6ezZbieUwnK7Xm9/XW0+ FG6PZCdfbT5mi2C9qrTKdI6FdDW34ClDW3OMWlU3Ovaw4cNDV3MLl9L1Ncen 1tzGdfnJrmq7vsPr/G6n8zt/zu+COb8j5PzuiPM7Bc5tzR1ZNmo1DDlZw1gx utTW3YIRkb7u5OS627Bv0tbdwnm9vu705LrbMCWY7hDb+eGm80Mv54chzjfJ nW+eOt9Uc7TZAq3u73bbeZbnwcfN9tdNuZOQB2mJxIu3x+GM0ihI/LX0x4eT x2XsK5yYBtdKOsG1FqOCay26wbUuXz0v4trhoiHoQfNULdj/prLV4+Jly00H pvb6i29cw2uaFB80qSYxMUlMTRIzk8ShSWJukjgySRybJE5MEivHkwU7RbMj bWJskpiYJKYmiZlJ4tAkMTdJHJkkjk0SJwaJickbJCZvkJi8QWLyBonJGyQm b5CYvEFi8gaJyRskJm+QmrxBOuoNquFvk/26/hIsVvl8+ynbDZp/l7voTGSc 32Tzj8Ve+uL+br2ap/ssmKld8WrnHt5Oz/Z7OSu+v2vlzAatkpuM5fb7epvv /7Xc+3+0WgarXsZ/wqhVlEvWKPu8youqvX8oStk7IIByLrJ1tj+as7U+6NaJ DNTp4PsT6lS/3WpGNF+nqyrQQDXlhF/S4Kxo6MU4rISfTvjphJ9O+OmEn044 nk6Us4JQJN5ls/vVehE8/ym4Efo+2+Xy5Lwa0EqLAdKEb2eIclqGbyfSu588 Bmp9euHbbcft7iDbDdytvbpzegh27UbhOUYGrRmG5UjjzbuWwdBOeddWA2KD 79xqRGztq7cQklzLAQsGISAVbIb0bhhB+YJMyAg4wrVNRsAhrvX3+E5yz9SJ Ma4/PjjfhscmI8AY3Q0j2DxCEzICDlltkxFwzGotIywEDdcywoLZlU1GgEG3 G0ZwgrIJGQHHoLbJCDgItZYRFqKAaxlhwVLOJiPAKNoNI6IonU/ICDiotE1G wFGltYywENZbywgLxo02GQGGxW4YES9YOuXMEg4RbXVqCceI1nLCRqBuLSls mKRanV2CYa4bWqQki6ekBRzy2Sot4JjPWlrYCLytpYUNS2KrtADDVje0mMUx n5IWcABnq7SAIzjrV6I2Amnr16I2LMCtEgMMQ90QY56RSTcoKsNvhmN468gC MZSIMInHTjYh63UNL45FrTUzjwdocSTurgVaKAlR29dFQ4uMzqfcpag3ZUIO bytZ27hCLInI2BknZNp/fOdqMHqm2d2B4a2rofif9vauGG57rmhosZSmcdPR or4ykFB4b8lCEJlKRCj72khaQPceNBFYjkXxM7tYAVjdH4lDaCF8iZIQtv1Q 1LQIUbaccr9iIGaeVVrAQfO0tLARuVBLCxv3YazSAoz719CCsGTKTYuBGHhW aQEHwdPSwkYkQi0tbFxjskoLMI5fQwua0il3LgYi2lmlBRzSTr8WsRFZUL8W sXH9zCoxwLh8DTHYcjHl3sVAhDqrxIBD1OmJYSNSoJ4YNq4NWiUGGGevIYZ0 TjGhxcRAxDmbphMDIef0p6Y2Iv/pz01tXPe0Sgwwbl5DjGiGp9y9GIggZ/U0 HQ4hpyeGjUh+emLYuKZr9UgdjIPXECNBs0mtLOCIcFaJAYeE0xPDRmQ+PTFs XK+2Sgwwrl1DjJSHU+5gDER4s0oMOMSbnhg2Iu3piWHjWrxVYoBx6hpizGbZ lHsYAxHbHBhm9UO26YlhI3Kenhg23Bk4sM7qxZ1riLHA8ZS7GMqHgZh9wjtP FohRiUjQgHnH2OBUGmIcC05l6OsBIMaRAFsWiKHeBIkINPnMIjLlPoZy8JCg EN57suBWWolgA0YeY4PkaLx7HwuSY+gIA/B0cCTQjwXf2EoCZxyafC7n8yn3 MZT3i4RRePfJAjGUiHjAzGNssA4NMY4F6zD0EgIQ40jAEQvEUM2ECAImnxwL PkxJDDgyhlViwKEx9La+NiKU6K19bXh3sUoMML5HQwx5jjIlMeBIF1aJAYe6 0BPDRsQRPTFseOWxSgwwXkdDDLpIp9zHGIhcYZUYcOgKPTFsRBDRE8OGNyWr xADjbzTECIt7ZdNdGoEjUVi9NQKHotATw0ZEED0xbHjBsnp1BIyn0RCDx4sp 9zEGIktYJQYcWkJPDBsRPvTEsOG9zCoxwPgYDTGiLJpyH2MgUoRVYsChIvTE sBGxQ08MG17nrBIDjHfREEPMn6bcxxiI/GCVGHDoBz0xbETg0BPDhrdAq8QA 41c0xEiT2ZT7GAORHKwSAw7loCeGjYgaemLYCKlhlRij41GUEW6baMjfVLEl aJGNtv01nhUNpSwXPPrbxG3qWLr34LVbqCrcxnazyeb71SflHb94ATQebpzC w5XIts82+zzYLqvQyrxwdMUjWy6ipJePjoco+YVbcKjK2Sa/b9yCFQGc6yqH RXySkE5VZVcxSWx7C3HaHB8kA2+z7XKRfnn0G0ZRFEtNLpQ6JTHn6B9Pgle/ vHz5uK/Oz49dNHKB9b/Tg4tbirbK/ZX1+cGiG7oaHK9R9ru0iB4vdMpytc7y L0Kt3CqNgksq2HKAaFyqdC0KtVnlN9kiEAjVmFAQlMLu+VrVSdfr4H6T7vfp vKpO2WVgj1S1xLwtspKoYrRAGW+3n6S0wstlMXiJjKsqJDzg1bAc9yKRUYhb Lb+UQaC2u53IGaxVxmqz35rDZDMqf03gX8W0Z5l/2cwfdef30EcOEqvtfL+W Rfj+5Z9evHz7/S8vCiQw7Xy9zbORuA0FF9tNVswiQyij4OsDMbvYX3/Ybe/v 9E7Hvwv+/cEf/Md//Md//Md//Md//Md//Md//Md//Md//Md//Md//Md//Md/ /Md//Md//Md/Tvz8P4ci9dsAUAUA --------------040407050908070007050109-- From owner-linux-xfs@oss.sgi.com Fri Feb 27 02:45:50 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 02:45:51 -0800 (PST) Received: from megachips.co.jp (ns.megachips.co.jp [211.12.79.195]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RAjmKO009301 for ; Fri, 27 Feb 2004 02:45:49 -0800 Received: from motooka2.megachips.co.jp (fw0.megachips.co.jp [172.16.79.194]) by megachips.co.jp (8.12.9/8.12.8) with SMTP id i1RAjg9E085003 for ; Fri, 27 Feb 2004 19:45:42 +0900 (JST) Message-Id: <200402271045.AA07136@motooka2.megachips.co.jp> From: Shigenori Motooka Date: Fri, 27 Feb 2004 19:45:36 +0900 To: linux-xfs@oss.sgi.com Subject: question for xfs_repair and xfs_check MIME-Version: 1.0 X-Mailer: AL-Mail32 Version 1.12 Content-Type: text/plain; charset=us-ascii X-archive-position: 2256 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: motooka.shigenori@megachips.co.jp Precedence: bulk X-list: linux-xfs Dear linux-xfs@oss.sgi.com, We are using your "xfs" on PowerPC-405GP hardware. We have a problem which is xfs_repari and xfs_check hangup. 1) xfs_repair hangup is on damaged drive. 2) xfs_check problem is on correct drive. Drive size is 160Gbyte. Our linux enviroment is following, 1) linux kernel 2.4.17 (Montavista Hardat linux 2.1) 2) gcc 2.9.5 3) gcclib 2.2.3 Do you have any reasons and solutions for this problem ? Shigenori Motooka MegaChips Corporation SYSTEM BUSINESS UNIT 4-1-6,Miyahara,Yodogawa-ku,Osaka,532-0003 JAPAN Phone:+81-6-6399-2865 Fax :+81-6-6399-6204 E-mail:motooka.shigenori@megachips.co.jp From owner-linux-xfs@oss.sgi.com Fri Feb 27 02:57:58 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 02:58:20 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RAvvKO009937 for ; Fri, 27 Feb 2004 02:57:58 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Awfgp-00083z-Cn; Fri, 27 Feb 2004 10:57:55 +0000 Date: Fri, 27 Feb 2004 10:57:55 +0000 From: Christoph Hellwig To: Shigenori Motooka Cc: linux-xfs@oss.sgi.com Subject: Re: question for xfs_repair and xfs_check Message-ID: <20040227105755.A30838@infradead.org> References: <200402271045.AA07136@motooka2.megachips.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200402271045.AA07136@motooka2.megachips.co.jp>; from motooka.shigenori@megachips.co.jp on Fri, Feb 27, 2004 at 07:45:36PM +0900 X-archive-position: 2257 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Feb 27, 2004 at 07:45:36PM +0900, Shigenori Motooka wrote: > Our linux enviroment is following, > 1) linux kernel 2.4.17 (Montavista Hardat linux 2.1) Sorry, but please ask Montavista for support. Kernel 2.4.17 is before extremly old and we don't have a chance to support that anymore. Even worse montavista is know for lots (sometimes braindead) modifications to their kernels that we don't know off and couldn't support even if we wanted to. From owner-linux-xfs@oss.sgi.com Fri Feb 27 03:23:01 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 03:23:16 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RBN0KO015384 for ; Fri, 27 Feb 2004 03:23:01 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1Awg55-00086m-LI; Fri, 27 Feb 2004 11:22:59 +0000 Date: Fri, 27 Feb 2004 11:22:59 +0000 From: Christoph Hellwig To: Shigenori Motooka Cc: linux-xfs@oss.sgi.com Subject: Re: question for xfs_repair and xfs_check Message-ID: <20040227112259.A31123@infradead.org> References: <200402271045.AA07136@motooka2.megachips.co.jp> <20040227105755.A30838@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: <20040227105755.A30838@infradead.org>; from hch@infradead.org on Fri, Feb 27, 2004 at 10:57:55AM +0000 X-archive-position: 2258 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs As a simple addition: you could try to get newer XFS userspace from oss.sgi.com - but 2.4.17 was before XFS 1.1 and thus has a slightly different user <-> kernelspace api so it will probably not work. I still think it's probably your kernel corrupting the filesystem and not a userspace issues, though. Especially as powerpc is big endian and unsigned char - XFS was written for such an enviroment (IRIX/mips) first but for the linux port that combination has been broken a few times. From owner-linux-xfs@oss.sgi.com Fri Feb 27 07:11:55 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 07:12:07 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RFBsKO026374 for ; Fri, 27 Feb 2004 07:11:55 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1RFBnF6015820 for ; Fri, 27 Feb 2004 07:11:49 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1RFBmeY34688665; Fri, 27 Feb 2004 09:11:48 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1RFBmEr578297; Fri, 27 Feb 2004 09:11:48 -0600 (CST) Date: Fri, 27 Feb 2004 09:11:48 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Frank Hellmann cc: XFS List Subject: Re: XFS on large block device problem In-Reply-To: <403F1F47.7040003@opticalart.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2259 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Frank - I'm able to reproduce this using loopback devices as well, so you're not alone. We'll talk to Neil Brown about this, see if he knows about the problem. -Eric On Fri, 27 Feb 2004, Frank Hellmann wrote: > Sure. > > I did a clean run of the mkfs.xfs and two runs of xfs_repair. > > It seems that the xfs_repair doesn't like the filesystem that much. > > I attached the output and strace. > > > I was wondering if using the other LVM methods would help here? I will > give the dm stuff a try and let you know, if it's just dependend on md. > > Cheers, > Frank... > > > > > -Eric > > > > On Thu, 2004-02-26 at 11:58, Frank Hellmann wrote: > > > >>Hi! > >> > >>I just upgraded one of our linux boxes (Redhat 9 + usual 2.6 and glibc > >>patches) to kernel 2.6.3 and wanted to try out the large block device > >>support. First attemp, beware... :-) > >> > >>I setup a md0 device consisting of four ~1.5TB large devices with mkraid > >>/dev/md0 and a simple /etc/raidtab. > >> > >>I had some issues makeing the filesystem on /dev/md0. mkfs.xfs > >>complained about a non-clean md0 device and would not let me do anything > >>with it. > >> > >>Upgrading to xfs-progs 2.6.3 and mdadm 1.5 tools didn't change that. > >> > >>First doing an mkfs.ext3, mounting and unmounting the device seems to > >>cure that. At least after that I could mkfs.xfs it. > >> > >>Unfortunatly restoring (tar not xfsrestore) some demo data back onto the > >>drive I was getting a lot of xfs/kernel messages into the logfile. The > >>tar process stopped with errors after about 200M of restore and the last > >>files got corrupted. pdflush has high activity (~95%). > >> > >>xfs_repair reports beside a lot of other problems a couple of: > >> > >>primary/secondary superblock XX conflict - AG superblock geometry info > >>conflicts with filesystem geometry > >> > >>which really makes me wonder, whats going on... See the attached files > >>for further info. Unfortunatly I currently don't have any debugging > >>tools on that machine... > >> > >>Everything is peachy (with LBD), if I stay below the usual 2TB limits > >>with the 2.6.3 kernel. > >> > >>Am I missing anything for XFS LBD support? Any ideas? > >> > >> > >> Cheers, > >> Frank... > > -- > -------------------------------------------------------------------------- > Frank Hellmann Optical Art GmbH Waterloohain 7a > Digital Cinema http://www.opticalart.de 22769 Hamburg > frank@opticalart.de Tel: ++49 40 5111051 Fax: ++49 40 43169199 > From owner-linux-xfs@oss.sgi.com Fri Feb 27 07:31:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 07:31:19 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1RFVHKO027167 for ; Fri, 27 Feb 2004 07:31:17 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1RFVHCX027166 for linux-xfs@oss.sgi.com; Fri, 27 Feb 2004 07:31:17 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i1RFVFKQ027150 for ; Fri, 27 Feb 2004 07:31:15 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i1REmrLE025965; Fri, 27 Feb 2004 06:48:53 -0800 Date: Fri, 27 Feb 2004 06:48:53 -0800 Message-Id: <200402271448.i1REmrLE025965@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 312] New: xfsprogs does not compile on AMD64/x86_64 X-Bugzilla-Reason: AssignedTo X-archive-position: 2260 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=312 Summary: xfsprogs does not compile on AMD64/x86_64 Product: Linux XFS Version: Current Platform: AMD OS/Version: Linux Status: NEW Severity: normal Priority: Medium Component: xfsprogs AssignedTo: xfs-master@oss.sgi.com ReportedBy: kas@informatics.muni.cz I have Fedora Core 0.96 test release for AMD64, and I have tried to recompile the xfsprogs-2.6.3-1.src.rpm. It fails when it tries to link /usr/lib/libuuid.a to xfs_copy. The ./configure script incorrectly looks for some symbol in "-luuid" and then sets the variable libuuid to "/usr/lib/libuuid.a", no matter where the "-luuid" was taken from (in my case - and probably other AMD64 distros too - the library is in /usr/lib64/libuuid.a). You may want to add "-static -luuid" when the static libuuid is needed, and just "-luuid" otherwise. ./configure --enable-shared-uuid works for me. Default configuration does not. I suggest the following patch to ./configure.in, which works for me: --- configure.in.orig 2004-02-27 15:42:49.163908768 +0100 +++ configure.in 2004-02-27 15:43:21.889933656 +0100 @@ -32,9 +32,9 @@ AC_PACKAGE_NEED_UUIDCOMPARE AC_ARG_ENABLE(shared-uuid, [ --enable-shared-uuid=[yes/no] Link shared libuuid [default=no].], - libuuid="/usr/lib/libuuid.a" + libuuid="-static -luuid" test "$enable_shared_uuid" = yes && libuuid="-luuid", - libuuid="/usr/lib/libuuid.a") + libuuid="-static -luuid") AC_PACKAGE_CHECK_LIBUUID AC_SUBST(libuuid) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. From owner-linux-xfs@oss.sgi.com Fri Feb 27 08:36:54 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 08:37:07 -0800 (PST) Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RGaqKO031321 for ; Fri, 27 Feb 2004 08:36:53 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.24) id 1AwLtd-00022H-PE for linux-xfs@oss.sgi.com; Thu, 26 Feb 2004 13:49:49 +0000 Message-ID: <403DF97D.C717302E@moving-picture.com> Date: Thu, 26 Feb 2004 13:49:49 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs Subject: df and "Value too large for defined data type" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-archive-position: 2261 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: james-p@moving-picture.com Precedence: bulk X-list: linux-xfs I have a problem with df reporting "Value too large for defined data type" for file systems on a particular server. The problem occurs when using an NFS client running on a 2.6.3 kernel that mounts XFS file systems over NFS from a server running a 2.4.21 kernel with XFS 1.3 When I run df on these file systems using the 2.6.3 client I get: df: `/mnt/tmp': Value too large for defined data type However, running df on any other client running 2.4.X, or on the server itself works OK. Also, running df on the 2.6.3 client to any other NFS exported file system works OK. I initially thought this was an NFS issue, but it appears to be a problem with the number of inodes reported from the underlying XFS file system. My original posts to the NFS list can be seen via: http://marc.theaimsgroup.com/?t=107762984200002&r=1&w=2 It appears the number of inodes that is being reported back to statfs() from this file system (from any client or on the server itself) is 2^64 - 1. On 2.4.X clients, the kernel routine just takes the lower 32 bits and doesn't complain. But on the 2.6.X client, it checks for the overflow and returns EOVERFLOW to statfs() - hence the error above. When I run 'df -i /disk2' on the 2.4.21 server, I get: Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdc1 4294967295 3 4294967292 1% /disk2 df reports: Filesystem 1k-blocks Used Available Use% Mounted on /dev/sdc1 976428116 3744 976424372 1% /disk2 i.e. 2^32 - 1 inodes (which is in fact the lower 32 bits of 2^64 - 1) The server in question has an external 3.5TB RAID array, partitioned on the RAID into 4 separate volumes that are seen on the host server as separate LUNs. 3 of these devices are about 1TB, the forth is approx 500Gb. Each of 3 1TB devices have this problem, the 500Gb device reports sensible inode numbers (much less than 2^32) and hence df works OK when statfs'ing this file system from a 2.6.3 client. The question is why is this file system (and other similar file systems on the same file server) reporting so many available inodes? All the other XFS file systems on other servers of about 1TB (or more) report the number of inodes at much less than 2^32. The XFS file systems were initially made using a very old version of xfsprogs, but I've just remade one file system using v2.5.6-0 - and it still shows the same behaviour. xfs_info reports: meta-data=/disk2 isize=256 agcount=233, agsize=1048576 blks = sectsz=512 data = bsize=4096 blocks=244139797, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 Any idea as to what is going on? Thanks James Pearson From owner-linux-xfs@oss.sgi.com Fri Feb 27 09:59:44 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 09:59:56 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RHxhKO000706 for ; Fri, 27 Feb 2004 09:59:44 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1RHxcLS023451 for ; Fri, 27 Feb 2004 11:59:38 -0600 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1RHxbhc34312926; Fri, 27 Feb 2004 11:59:37 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1RHxaEq593241; Fri, 27 Feb 2004 11:59:37 -0600 (CST) Subject: Re: df and "Value too large for defined data type" From: Eric Sandeen To: James Pearson Cc: linux-xfs In-Reply-To: <403DF97D.C717302E@moving-picture.com> References: <403DF97D.C717302E@moving-picture.com> Content-Type: text/plain Organization: Eric Conspiracy Secret Labs Message-Id: <1077904776.7024.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 27 Feb 2004 11:59:36 -0600 Content-Transfer-Encoding: 7bit X-archive-position: 2262 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs the 2.4 statfs interface is 32 bits; I think that until you upgrade the server to 2.6, and (as Christoph tells me) you'll also need a very recent glibc to take advantage of it. On a large filesystem, xfs easily wraps around the ints in the statfs structure. -Eric On Thu, 2004-02-26 at 07:49, James Pearson wrote: > I have a problem with df reporting "Value too large for defined data > type" for file systems on a particular server. > > The problem occurs when using an NFS client running on a 2.6.3 kernel > that mounts XFS file systems over NFS from a server running a 2.4.21 > kernel with XFS 1.3 > > When I run df on these file systems using the 2.6.3 client I get: > > df: `/mnt/tmp': Value too large for defined data type > > However, running df on any other client running 2.4.X, or on the server > itself works OK. Also, running df on the 2.6.3 client to any other NFS > exported file system works OK. > > I initially thought this was an NFS issue, but it appears to be a > problem with the number of inodes reported from the underlying XFS file > system. > > My original posts to the NFS list can be seen via: > > http://marc.theaimsgroup.com/?t=107762984200002&r=1&w=2 > > It appears the number of inodes that is being reported back to statfs() > from this file system (from any client or on the server itself) is 2^64 > - 1. On 2.4.X clients, the kernel routine just takes the lower 32 bits > and doesn't complain. But on the 2.6.X client, it checks for the > overflow and returns EOVERFLOW to statfs() - hence the error above. > > When I run 'df -i /disk2' on the 2.4.21 server, I get: > > Filesystem Inodes IUsed IFree IUse% Mounted on > /dev/sdc1 4294967295 3 4294967292 1% /disk2 > > df reports: > > Filesystem 1k-blocks Used Available Use% Mounted on > /dev/sdc1 976428116 3744 976424372 1% /disk2 > > > i.e. 2^32 - 1 inodes (which is in fact the lower 32 bits of 2^64 - 1) > > The server in question has an external 3.5TB RAID array, partitioned on > the RAID into 4 separate volumes that are seen on the host server as > separate LUNs. 3 of these devices are about 1TB, the forth is approx > 500Gb. Each of 3 1TB devices have this problem, the 500Gb device reports > sensible inode numbers (much less than 2^32) and hence df works OK when > statfs'ing this file system from a 2.6.3 client. > > The question is why is this file system (and other similar file systems > on the same file server) reporting so many available inodes? > > All the other XFS file systems on other servers of about 1TB (or more) > report the number of inodes at much less than 2^32. > > The XFS file systems were initially made using a very old version of > xfsprogs, but I've just remade one file system using v2.5.6-0 - and it > still shows the same behaviour. > > xfs_info reports: > > meta-data=/disk2 isize=256 agcount=233, > agsize=1048576 blks > = sectsz=512 > data = bsize=4096 blocks=244139797, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=4096 blocks=32768, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > > Any idea as to what is going on? > > Thanks > > James Pearson -- Eric Sandeen [C]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 Feb 27 10:19:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 10:19:28 -0800 (PST) Received: from phoenix.infradead.org (phoenix.infradead.org [213.86.99.234]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RIJGKO001425 for ; Fri, 27 Feb 2004 10:19:16 -0800 Received: from hch by phoenix.infradead.org with local (Exim 4.30 #5 (Red Hat Linux)) id 1AwmZu-0000pn-Ev; Fri, 27 Feb 2004 18:19:14 +0000 Date: Fri, 27 Feb 2004 18:19:14 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: James Pearson , linux-xfs Subject: Re: df and "Value too large for defined data type" Message-ID: <20040227181914.A3175@infradead.org> References: <403DF97D.C717302E@moving-picture.com> <1077904776.7024.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1077904776.7024.5.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Fri, Feb 27, 2004 at 11:59:36AM -0600 X-archive-position: 2263 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs On Fri, Feb 27, 2004 at 11:59:36AM -0600, Eric Sandeen wrote: > the 2.4 statfs interface is 32 bits; I think that until you upgrade the > server to 2.6, and (as Christoph tells me) you'll also need a very > recent glibc to take advantage of it. > > On a large filesystem, xfs easily wraps around the ints in the statfs > structure. Well, in the case of free inodes we might be a bit over-eager and should just return some random lower value. Not that it really matters with dynamically allocated inodes.. From owner-linux-xfs@oss.sgi.com Fri Feb 27 10:56:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 10:56:48 -0800 (PST) Received: from stargate.coplanar.net (root@CPE0080c8c9b431-CM014280010574.cpe.net.cable.rogers.com [24.112.162.124]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RIu7KO003395 for ; Fri, 27 Feb 2004 10:56:08 -0800 Received: from coplanar.net (thunderdome.skynet.coplanar.net [192.168.7.3]) (authenticated bits=0) by stargate.coplanar.net (8.12.3/8.12.3/Debian-6.6) with ESMTP id i1RIu3hE009851 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 27 Feb 2004 13:56:05 -0500 Message-ID: <403F92BE.9070305@coplanar.net> Date: Fri, 27 Feb 2004 13:55:58 -0500 From: Jeremy Jackson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623 Debian/1.0.0-0.woody.1 MIME-Version: 1.0 To: XFS Linux Subject: 2.4.25 XFS patches? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (stargate.coplanar.net: domain of jerj@coplanar.net designates 192.168.7.3 as SASL permitted sender) X-archive-position: 2264 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: jerj@coplanar.net Precedence: bulk X-list: linux-xfs Hi, 2.4.25 is out and appears to have XFS. Will there be releases/patches for dmapi, etc, or will these only be available via CVS? Cheers, Jeremy Jackson From owner-linux-xfs@oss.sgi.com Fri Feb 27 14:10:42 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 14:10:45 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1RMAgKO019070 for ; Fri, 27 Feb 2004 14:10:42 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1RMAaLS002830 for ; Fri, 27 Feb 2004 16:10:36 -0600 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1RMAZvU34776776; Fri, 27 Feb 2004 16:10:35 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1AwqBm-000767-00; Fri, 27 Feb 2004 16:10:34 -0600 Subject: TAKE 908959 - Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Fri, 27 Feb 2004 16:10:34 -0600 X-archive-position: 2265 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Fri Feb 27 14:10:14 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: sandeen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:167609a fs/xfs/linux-2.6/xfs_buf.c - 1.153 - use kmem_alloc for noaddr buffers fs/xfs/linux-2.4/xfs_buf.c - 1.174 - use kmem_alloc for noaddr buffers From owner-linux-xfs@oss.sgi.com Fri Feb 27 19:01:40 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 19:01:42 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1S31eKO000395 for ; Fri, 27 Feb 2004 19:01:40 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1S31YF6012865 for ; Fri, 27 Feb 2004 19:01:35 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1S31Xh534679443; Fri, 27 Feb 2004 21:01:33 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1S31CEr646565; Fri, 27 Feb 2004 21:01:23 -0600 (CST) Date: Fri, 27 Feb 2004 21:01:12 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jeremy Jackson cc: XFS Linux Subject: Re: 2.4.25 XFS patches? In-Reply-To: <403F92BE.9070305@coplanar.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2266 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs easiest way would probably be to get the cvs checkout for fs/xfs, but I may also go back to making patches from the latest released kernel.org kernels to our cvs code... we'll see. There may also be point releases in the future, but we're still evaluating how to do that now that we're in the core kernel, and presumeably in upcoming distro releases of 2.6 as well. -Eric On Fri, 27 Feb 2004, Jeremy Jackson wrote: > Hi, > > 2.4.25 is out and appears to have XFS. Will there be releases/patches > for dmapi, etc, or will these only be available via CVS? > > Cheers, > > Jeremy Jackson > > From owner-linux-xfs@oss.sgi.com Fri Feb 27 23:05:51 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Feb 2004 23:06:13 -0800 (PST) Received: from shksmtp01.so-net.com.hk (mail.so-net.com.hk [203.99.142.21]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1S75nKO007092 for ; Fri, 27 Feb 2004 23:05:50 -0800 Received: (qmail 15526 invoked from network); 28 Feb 2004 07:05:43 -0000 Received: from so232072.bbo232.so-net.com.hk (HELO linuxmail.org) ([203.176.232.72]) (envelope-sender ) by shksmtp01.so-net.com.hk (qmail-ldap-1.03) with SMTP for ; 28 Feb 2004 07:05:43 -0000 Message-ID: <40403DC6.7070501@linuxmail.org> Date: Sat, 28 Feb 2004 15:05:42 +0800 From: Feizhou User-Agent: Mozilla Thunderbird 0.5 (X11/20040208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Cox CC: XFS Mailing List Subject: Re: Performance problem with xfs References: <403F1934.3020701@linuxmail.org> <1077894047.25678.7.camel@pip> In-Reply-To: <1077894047.25678.7.camel@pip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2267 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: feizhou@linuxmail.org Precedence: bulk X-list: linux-xfs Danny Cox wrote: > Feizhou, > > On Fri, 2004-02-27 at 05:17, Feizhou wrote: > >>I am having performance issues with a box running 3ware 0+1 mode where >>one of the filesystems is xfs based. >> >>xfs_ili and xfs_inode are the values that change >> >> xfs_bmap /var/catchall/bulkdb/ >>/var/catchall/bulkdb/: >> 0: [0..7]: 42235064..42235071 > > > Well, you didn't say what version of the kernel, so we can't figure out > if your XFS is very old or no. That might be a clue. XFS 1.3.0 The latest rh 2.4.20-30 kernels at http://atrpms.physik.fu-berlin.de/ > > >>Also, kswapd chews substantial cpu. > > > That's a clue right there. If you're already swapping, NO filesystem > will provide much performance. Can you try installing more memory? You > might try running vmstat for a bit (vmstat 5 5 or vmstat 5 10), and > check out the "si" and "so" columns. These are the "swap in" and "swap > out" stats for the past N seconds (5 in this case). If they're anything > but "0", then you're swapping. Sorry, wrong. Zero swapping. si and so are all zero. bi and bo are not very high either (under 1000 usually) so I/O bottleneck it is not. There are always a number of blocked processes which are mostly related to the xfs filesystem. > > Any others with insight? > From owner-linux-xfs@oss.sgi.com Sat Feb 28 04:08:21 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 04:09:01 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1SC8LKO016784 for ; Sat, 28 Feb 2004 04:08:21 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1SBAKOw026374 for ; Sat, 28 Feb 2004 03:10:20 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1SC8EY334391537; Sat, 28 Feb 2004 06:08:14 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ax3GP-0003gY-00; Sat, 28 Feb 2004 06:08:13 -0600 Subject: TAKE 908809 - Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Sat, 28 Feb 2004 06:08:13 -0600 X-archive-position: 2268 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Date: Sat Feb 28 04:07:56 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.6.x Inspected by: cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.6.x-xfs Modid: xfs-linux:xfs-kern:167627a fs/xfs/xfsidbg.c - 1.257 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_lrw.h - 1.43 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_lrw.c - 1.207 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_ioctl.c - 1.105 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_super.h - 1.55 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_aops.c - 1.65 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.4/xfs_lrw.h - 1.43 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.4/xfs_super.h - 1.61 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.4/xfs_aops.c - 1.73 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_buf.h - 1.89 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.6/xfs_buf.c - 1.154 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.4/xfs_buf.h - 1.95 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants fs/xfs/linux-2.4/xfs_buf.c - 1.175 - replace page_buf_t, pb_target_t and page_buf_daddr_t with their xfs_ variants From owner-linux-xfs@oss.sgi.com Sat Feb 28 05:43:31 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 05:43:34 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1SDhVKO021396 for ; Sat, 28 Feb 2004 05:43:31 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1SDhQF6017428 for ; Sat, 28 Feb 2004 05:43:26 -0800 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.232.87]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1SDhOAi34652407; Sat, 28 Feb 2004 07:43:25 -0600 (CST) Received: from hch by maine.americas.sgi.com with local (Exim 3.36 #1 (Debian)) id 1Ax4kW-0006TQ-00; Sat, 28 Feb 2004 07:43:24 -0600 Subject: TAKE 908809 - Message-Id: From: Christoph Hellwig To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@fido.engr.sgi.com Date: Sat, 28 Feb 2004 07:43:24 -0600 X-archive-position: 2269 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@sgi.com Precedence: bulk X-list: linux-xfs Fixup the last commit --- start blurb --- This checkin was brought to you by the foundation for the advancement of useable SCM systems. --- end blurb --- Date: Sat Feb 28 05:41:58 PST 2004 Workarea: maine.americas.sgi.com:/home/daisy40/hch/ptools/xfs-2.4.x Inspected by: cattelan The following file(s) were checked into: bonnie.engr.sgi.com:/isms/linux/2.4.x-xfs Modid: xfs-linux:xfs-kern:167628a fs/xfs/linux-2.6/xfs_lrw.h - 1.44 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.6/xfs_lrw.c - 1.208 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.6/xfs_ioctl.c - 1.106 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.6/xfs_super.h - 1.56 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.6/xfs_buf.h - 1.90 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.6/xfs_buf.c - 1.155 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.4/xfs_buf.h - 1.96 - really kill the pagebuf vs xfs_buf confusion fs/xfs/linux-2.4/xfs_buf.c - 1.176 - really kill the pagebuf vs xfs_buf confusion From owner-linux-xfs@oss.sgi.com Sat Feb 28 10:15:11 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 10:15:29 -0800 (PST) Received: from imo-m21.mx.aol.com (imo-m21.mx.aol.com [64.12.137.2]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1SIFBKO001013 for ; Sat, 28 Feb 2004 10:15:11 -0800 Received: from AndyLiebman@aol.com by imo-m21.mx.aol.com (mail_out_v36_r4.14.) id 4.1d7.1addc402 (30960) for ; Sat, 28 Feb 2004 13:15:02 -0500 (EST) From: AndyLiebman@aol.com Message-ID: <1d7.1addc402.2d7234a6@aol.com> Date: Sat, 28 Feb 2004 13:15:02 EST Subject: block size & 2.6 kernel To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Mail & IM Device Client sub 7 X-archive-position: 2270 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: AndyLiebman@aol.com Precedence: bulk X-list: linux-xfs Through the 2.4 kernel, xfs on linux was limited to a 4096K block size (the size of the page file, I believe). Has that changed with the 2.6 kernel? Is it now possible to use a block size that is > 4096? If so, what is the limit? And if it's possible to use a larger block size in Linux under the 2.6 kernel, what size would make sense for a RAID5 array that's mostly holding large audio and video files? And is there a rule of thumb for choosing block size, segment size, RAID chunk size (and balancing those with things like samba transmit sizes?) From owner-linux-xfs@oss.sgi.com Sat Feb 28 18:13:33 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 18:13:35 -0800 (PST) Received: from mail.dgap.mipt.ru (dgap-gw.mipt.ru [194.85.81.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1T2DVKO013817 for ; Sat, 28 Feb 2004 18:13:32 -0800 Received: (qmail 27817 invoked by uid 207); 29 Feb 2004 02:13:24 -0000 Message-ID: <20040229021324.27816.qmail@mail.dgap.mipt.ru> From: "Andrew Panphiloff" To: linux-xfs@oss.sgi.com Subject: are xfs working on amd64 ? Date: Sun, 29 Feb 2004 05:13:24 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251" Content-Transfer-Encoding: 7bit X-archive-position: 2271 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: borisych@dgap.mipt.ru Precedence: bulk X-list: linux-xfs I have dual opteron gentoo box with xfsed / I tried use this kernel ftp://oss.sgi.com/projects/xfs/testing/RHEL/SRPMS/kernel-2.4.21-9.EL.sgi1.sr c.rpm but after "insmod /modules/xfs.o" (I use initrd) system hangs up, in 32-bin mode all works ok. I tried compile kernel without oot-patch but get the same result. From owner-linux-xfs@oss.sgi.com Sat Feb 28 21:04:45 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 21:04:55 -0800 (PST) Received: from zok.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1T54iKO018866 for ; Sat, 28 Feb 2004 21:04:44 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [192.48.203.135]) by zok.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with ESMTP id i1T54SF6011118 for ; Sat, 28 Feb 2004 21:04:28 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id i1T54RY234765131; Sat, 28 Feb 2004 23:04:28 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by poppy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id i1T53lEr740059; Sat, 28 Feb 2004 23:04:17 -0600 (CST) Date: Sat, 28 Feb 2004 23:03:47 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Andrew Panphiloff cc: linux-xfs@oss.sgi.com Subject: Re: are xfs working on amd64 ? In-Reply-To: <20040229021324.27816.qmail@mail.dgap.mipt.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 2272 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs I have not tried that particular src.rpm on an amd64 (I don't have the hardware...) but as far as I know, xfs works fine on the platform - I'd suggest trying a stock 2.4.25 kernel first, and see how that goes. Otherwise, I could put a newer src.rpm up that has kdb, you could use that to start tracking down what went wrong... -Eric On Sun, 29 Feb 2004, Andrew Panphiloff wrote: > I have dual opteron gentoo box with xfsed / > I tried use this kernel > ftp://oss.sgi.com/projects/xfs/testing/RHEL/SRPMS/kernel-2.4.21-9.EL.sgi1.sr > c.rpm > but after "insmod /modules/xfs.o" (I use initrd) system hangs up, > in 32-bin mode all works ok. I tried compile kernel without oot-patch but > get the same result. > > From owner-linux-xfs@oss.sgi.com Sat Feb 28 21:22:08 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 21:22:37 -0800 (PST) Received: from mail.ocs.com.au (pr-117-210.ains.net.au [202.147.117.210] (may be forged)) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1T5M7KO019734 for ; Sat, 28 Feb 2004 21:22:07 -0800 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id 1F5E71800B6 for ; Sun, 29 Feb 2004 16:22:01 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 7A7D8C00AF; Sun, 29 Feb 2004 16:21:46 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 77EE8140085 for ; Sun, 29 Feb 2004 16:21:46 +1100 (EST) X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: are xfs working on amd64 ? In-reply-to: Your message of "Sat, 28 Feb 2004 23:03:47 MDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Feb 2004 16:21:45 +1100 Message-ID: <8350.1078032105@ocs3.ocs.com.au> X-archive-position: 2273 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: kaos@sgi.com Precedence: bulk X-list: linux-xfs On Sat, 28 Feb 2004 23:03:47 -0600 (CST), Eric Sandeen wrote: >Otherwise, I could put a newer src.rpm up that has >kdb, you could use that to start tracking down what >went wrong... No kdb support for AMD x86_64. The x86_64 maintainers have not sent any patches, nor do I have any hardware to test on. From owner-linux-xfs@oss.sgi.com Sat Feb 28 21:50:17 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Feb 2004 21:50:42 -0800 (PST) Received: from mail.dgap.mipt.ru (dgap-gw.mipt.ru [194.85.81.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1T5oFKO020416 for ; Sat, 28 Feb 2004 21:50:16 -0800 Received: (qmail 3699 invoked from network); 29 Feb 2004 05:50:10 -0000 Received: from unknown (HELO dgap.mipt.ru) ([127.0.0.1]) (envelope-sender ) by localhost (qmail-ldap-1.03) with SMTP for ; 29 Feb 2004 05:50:10 -0000 Received: from 213.181.22.135 (SquirrelMail authenticated user borisych) by mail.dgap.mipt.ru with HTTP; Sun, 29 Feb 2004 08:50:10 +0300 (MSK) Message-ID: <3759.213.181.22.135.1078033810.squirrel@mail.dgap.mipt.ru> Date: Sun, 29 Feb 2004 08:50:10 +0300 (MSK) Subject: Re: are xfs working on amd64 ? From: "Andrew B. Panphiloff" To: X-XheaderVersion: 1.1 X-UserAgent: In-Reply-To: References: <20040229021324.27816.qmail@mail.dgap.mipt.ru> X-Priority: 3 Importance: Normal Cc: , Reply-To: borisych@dgap.mipt.ru X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-archive-position: 2274 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: borisych@dgap.mipt.ru Precedence: bulk X-list: linux-xfs <"Eric Sandeen"> > I have not tried that particular src.rpm on an amd64 > (I don't have the hardware...) but as far as I know, > xfs works fine on the platform - I'd suggest trying > a stock 2.4.25 kernel first, and see how that goes. Due to nptled glibc I can't use pure 2.4.x kernels only redhat kernels or 2.6.x. I tried use kernels from atrpms but all fedora and rh9 kernel failed to compile, for example : 08:38 AMsunduck| linux-2.4.20-30_37 # make dep make[1]: Entering directory `/usr/src/testing/kernels/linux-2.4.20-30_37/arch/x86_64/tools' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/usr/src/testing/kernels/linux-2.4.20-30_37/arch/x86_64/tools' make[1]: Entering directory `/usr/src/testing/kernels/linux-2.4.20-30_37/arch/x86_64/boot' make[1]: Nothing to be done for `dep'. make[1]: Leaving directory `/usr/src/testing/kernels/linux-2.4.20-30_37/arch/x86_64/boot' scripts/mkdep -- init/*.c > .depend scripts/mkdep -- `find /usr/src/testing/kernels/linux-2.4.20-30_37/include/asm /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux /usr/src/testing/kernels/linux-2.4.20-30_37/include/scsi /usr/src/testing/kernels/linux-2.4.20-30_37/include/net /usr/src/testing/kernels/linux-2.4.20-30_37/include/math-emu \( -name SCCS -o -name .svn \) -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/i2c-elektor.h is empty make _sfdep_arch/x86_64/tools _sfdep_kernel _sfdep_drivers _sfdep_mm _sfdep_fs _sfdep_net _sfdep_ipc _sfdep_lib _sfdep_crypto _sfdep_arch/x86_64/kernel _sfdep_arch/x86_64/mm _sfdep_arch/x86_64/lib _FASTDEP_ALL_SUB_DIRS="arch/x86_64/tools kernel drivers mm fs net ipc lib crypto arch/x86_64/kernel arch/x86_64/mm arch/x86_64/lib" make[1]: Entering directory `/usr/src/testing/kernels/linux-2.4.20-30_37' make -C arch/x86_64/tools fastdep make[2]: Entering directory `/usr/src/testing/kernels/linux-2.4.20-30_37/arch/x86_64/tools' gcc -D__KERNEL__ -I/usr/src/testing/kernels/linux-2.4.20-30_37/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -finline-limit=2000 -fno-strength-reduce -S -o offset.tmp offset.c In file included from /usr/src/testing/kernels/linux-2.4.20-30_37/include/asm/smp.h:10, from /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/smp.h:14, from /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/sched.h:25, from offset.c:9: /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/ptrace.h: In function `ptrace_link': /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/ptrace.h:67: error: dereferencing pointer to incomplete type /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/ptrace.h: In function `ptrace_unlink': /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/ptrace.h:72: error: dereferencing pointer to incomplete type In file included from offset.c:9: /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/sched.h: At top level: /usr/src/testing/kernels/linux-2.4.20-30_37/include/linux/sched.h:571: error: syntax error before '*' token offset.c: In function `main': offset.c:35: error: structure has no member named `processor' make[2]: *** [offset.h] Error 1 make[2]: Leaving directory `/usr/src/testing/kernels/linux-2.4.20-30_37/arch/x86_64/tools' make[1]: *** [_sfdep_arch/x86_64/tools] Error 2 make[1]: Leaving directory `/usr/src/testing/kernels/linux-2.4.20-30_37' make: *** [dep-files] Error 2 08:38 AMsunduck| linux-2.4.20-30_37 # 2.6.x kernels (exclude 2.6.0-test11) hang after a while (2.6.0 after 3-7 days, 2.6.1 and higher after 30 minutes). Once I have caught a problem on 2.6.0 - it "forgot" about mount points. It is necessary to note that all xfsed kernels (fedora, RH9, RHEL and 2.6.x) works fine in 32-bit mode. > > Otherwise, I could put a newer src.rpm up that has > kdb, you could use that to start tracking down what > went wrong... It would be wonderful. > > -Eric > > On Sun, 29 Feb 2004, Andrew Panphiloff wrote: > >> I have dual opteron gentoo box with xfsed / >> I tried use this kernel >> ftp://oss.sgi.com/projects/xfs/testing/RHEL/SRPMS/kernel-2.4.21-9.EL.sgi1.sr >> c.rpm >> but after "insmod /modules/xfs.o" (I use initrd) system hangs up, in >> 32-bin mode all works ok. I tried compile kernel without oot-patch but >> get the same result. >> >> From owner-linux-xfs@oss.sgi.com Sun Feb 29 02:08:35 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Feb 2004 02:08:47 -0800 (PST) Received: from cellus.no (ns.cellus.no [193.91.191.71]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1TA8YKO028954 for ; Sun, 29 Feb 2004 02:08:35 -0800 Received: from fwall (cD9089052.sdsl.catch.no [217.8.144.82]) by cellus.no (8.9.3/8.9.3) with ESMTP id LAA19020; Sun, 29 Feb 2004 11:08:28 +0100 Content-Type: text/plain; charset="windows-1251" From: Christian To: "Andrew Panphiloff" , linux-xfs@oss.sgi.com Subject: Re: are xfs working on amd64 ? Date: Sun, 29 Feb 2004 11:08:46 +0100 User-Agent: KMail/1.4.3 References: <20040229021324.27816.qmail@mail.dgap.mipt.ru> In-Reply-To: <20040229021324.27816.qmail@mail.dgap.mipt.ru> MIME-Version: 1.0 Message-Id: <200402291108.46219.csr@cellus.no> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id i1TA8ZKO028955 X-archive-position: 2275 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: csr@cellus.no Precedence: bulk X-list: linux-xfs On Sunday 29 February 2004 03:13, Andrew Panphiloff wrote: > I have dual opteron gentoo box with xfsed / > I tried use this kernel >ftp://oss.sgi.com/projects/xfs/testing/RHEL/SRPMS/kernel-2.4.21-9.EL.sgi1.src.rpm > but after "insmod /modules/xfs.o" (I use initrd) system hangs up, > in 32-bin mode all works ok. I tried compile kernel without oot-patch but > get the same result. I've been using XFS on x86-64 systems running 2.4 and 2.6 kernels without any problems. Distribution used was Suse 9.0 for x86-64. The 2.4 kernels (x86-64) were the precompiled ones supplied by Suse. The 2.6 kernel (x86-64) was 2.6.2 from ftp.kernel.org, and compiled from source. Christian From owner-linux-xfs@oss.sgi.com Sun Feb 29 03:27:22 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Feb 2004 03:27:24 -0800 (PST) Received: from eik.ii.uib.no (eik.ii.uib.no [129.177.16.3]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1TBRLKO032018 for ; Sun, 29 Feb 2004 03:27:22 -0800 Received: from lapprose.ii.uib.no ([129.177.20.37]:38665) by eik.ii.uib.no with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1AxP6H-0004ZV-UL; Sun, 29 Feb 2004 12:27:13 +0100 Received: (from jfm@localhost) by lapprose.ii.uib.no (8.12.8/8.12.8/Submit) id i1TBRDnN001493; Sun, 29 Feb 2004 12:27:13 +0100 Date: Sun, 29 Feb 2004 12:27:13 +0100 From: Jan-Frode Myklebust To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: are xfs working on amd64 ? Message-ID: <20040229112713.GA1385@ii.uib.no> References: <20040229021324.27816.qmail@mail.dgap.mipt.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-archive-position: 2276 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: janfrode@parallab.uib.no Precedence: bulk X-list: linux-xfs On Sat, Feb 28, 2004 at 11:03:47PM -0600, Eric Sandeen wrote: > > Otherwise, I could put a newer src.rpm up that has > kdb, you could use that to start tracking down what > went wrong... If you have any newer version of the RHEL+xfs kernel, it would be nice if you could upload it. The current one didn't work for me.. wouldn't boot with root-fs on LVM. This works fine with the 2.4.21-9.0.1.ELsmp kernel from whitebox. -jf From owner-linux-xfs@oss.sgi.com Sun Feb 29 04:09:48 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Feb 2004 04:10:20 -0800 (PST) Received: from mail.dgap.mipt.ru (dgap-gw.mipt.ru [194.85.81.130]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1TC9kKO003455 for ; Sun, 29 Feb 2004 04:09:48 -0800 Received: (qmail 28409 invoked from network); 29 Feb 2004 12:09:40 -0000 Received: from unknown (HELO behigh.8ka.mipt.ru) (borisych@dgap.mipt.ru@[194.85.83.30]) (envelope-sender ) by dgap-gw.mipt.ru (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 29 Feb 2004 12:09:40 -0000 Subject: Re: are xfs working on amd64 ? From: "Andrew B. Panphiloff" Reply-To: borisych@dgap.mipt.ru To: Christian Cc: linux-xfs@oss.sgi.com In-Reply-To: <200402291108.46219.csr@cellus.no> References: <20040229021324.27816.qmail@mail.dgap.mipt.ru> <200402291108.46219.csr@cellus.no> Content-Type: text/plain; charset=koi8-r Message-Id: <1078056813.31169.29.camel@behigh.8ka.mipt.ru> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sun, 29 Feb 2004 15:13:33 +0300 Content-Transfer-Encoding: 8bit X-archive-position: 2277 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: borisych@dgap.mipt.ru Precedence: bulk X-list: linux-xfs В Вск, 29.02.2004, в 13:08, Christian пишет: > On Sunday 29 February 2004 03:13, Andrew Panphiloff wrote: > > I have dual opteron gentoo box with xfsed / > > I tried use this kernel > >ftp://oss.sgi.com/projects/xfs/testing/RHEL/SRPMS/kernel-2.4.21-9.EL.sgi1.src.rpm > > but after "insmod /modules/xfs.o" (I use initrd) system hangs up, > > in 32-bin mode all works ok. I tried compile kernel without oot-patch but > > get the same result. > > I've been using XFS on x86-64 systems running 2.4 and 2.6 kernels without > any problems. Can you post your kernel and hardware config? Suse does not support nptl. RedHat support it and also their kernels have new sheduler (http://www.redhat.com/software/rhel/kernel26/). > > Distribution used was Suse 9.0 for x86-64. > > The 2.4 kernels (x86-64) were the precompiled ones supplied by Suse. > > The 2.6 kernel (x86-64) was 2.6.2 from ftp.kernel.org, and compiled from > source. > > Christian > From owner-linux-xfs@oss.sgi.com Sun Feb 29 14:34:24 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Feb 2004 14:34:38 -0800 (PST) Received: from rj.sgi.com (mtvcafw.SGI.COM [192.48.171.6]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1TMYNKO032095 for ; Sun, 29 Feb 2004 14:34:23 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by rj.sgi.com (8.12.9/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1TLM2Ow000912 for ; Sun, 29 Feb 2004 13:22:03 -0800 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 JAA22218; Mon, 1 Mar 2004 09:19:35 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1TMJX8n556804; Mon, 1 Mar 2004 09:19:33 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1TMJQFs000813; Mon, 1 Mar 2004 09:19:26 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1TMJO7B000811; Mon, 1 Mar 2004 09:19:24 +1100 Date: Mon, 1 Mar 2004 09:19:24 +1100 From: Nathan Scott To: Michael Lampe Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.25 & xfs & ide write barriers Message-ID: <20040229221924.GA731@frodo> References: <403E0A7A.3040505@iwr.uni-heidelberg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <403E0A7A.3040505@iwr.uni-heidelberg.de> User-Agent: Mutt/1.5.3i X-archive-position: 2278 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Thu, Feb 26, 2004 at 04:02:18PM +0100, Michael Lampe wrote: > fs/xfs/linux/xfs_buf.c already has > > #ifdef RQ_WRITE_ORDERED > if (flush) > set_bit(BH_Ordered_Flush, &bufferlist[cnt-1]->b_state); > #endif > > in _pagebuf_page_io. > > Is this all I need (I already have applied the ide write barrier patch) > to safely use disk write back caching? > (which IDE write barrier patch is that, out of curiousity?) This stuff is untested by anyone here at SGI, so YMMV. It is also not going to work in the presence of unwritten extents (which were implemented after this change), some additional code would be needed there. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 29 15:34:12 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Feb 2004 15:34:26 -0800 (PST) Received: from omx1.americas.sgi.com (cfcafw.SGI.COM [198.149.23.1]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i1TNYCKO005388 for ; Sun, 29 Feb 2004 15:34:12 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id i1TNY5KU024987 for ; Sun, 29 Feb 2004 17:34:06 -0600 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 KAA23406; Mon, 1 Mar 2004 10:34:03 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id i1TNXs8n578295; Mon, 1 Mar 2004 10:33:54 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id i1TNXdFs001149; Mon, 1 Mar 2004 10:33:39 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id i1TNXcNk001147; Mon, 1 Mar 2004 10:33:38 +1100 Date: Mon, 1 Mar 2004 10:33:38 +1100 From: Nathan Scott To: AndyLiebman@aol.com Cc: linux-xfs@oss.sgi.com Subject: Re: block size & 2.6 kernel Message-ID: <20040229233338.GE731@frodo> References: <1d7.1addc402.2d7234a6@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d7.1addc402.2d7234a6@aol.com> User-Agent: Mutt/1.5.3i X-archive-position: 2279 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs On Sat, Feb 28, 2004 at 01:15:02PM -0500, AndyLiebman@aol.com wrote: > Through the 2.4 kernel, xfs on linux was limited to a 4096K block size (the > size of the page file, I believe). On IA32, it is 4K, yes. Other architectures (like IA64) can (and do) use larger page sizes and hence larger blocksizes are an option there. > Has that changed with the 2.6 kernel? Is it No change. > now possible to use a block size that is > 4096? If so, what is the limit? And The limit is the kernel page size, which is architecture dependent. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Feb 29 17:31:29 2004 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Feb 2004 17:31:30 -0800 (PST) Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i211VTKO010013 for ; Sun, 29 Feb 2004 17:31:29 -0800 Received: (from xfs@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i211VToT010012 for linux-xfs@oss.sgi.com; Sun, 29 Feb 2004 17:31:29 -0800 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.10/8.12.9) with ESMTP id i211VRKQ009997 for ; Sun, 29 Feb 2004 17:31:27 -0800 Received: (from apache@localhost) by oss.sgi.com (8.12.10/8.12.8/Submit) id i210kic3009350; Sun, 29 Feb 2004 16:46:44 -0800 Date: Sun, 29 Feb 2004 16:46:44 -0800 Message-Id: <200403010046.i210kic3009350@oss.sgi.com> From: bugzilla-daemon@oss.sgi.com To: xfs-master@oss.sgi.com Subject: [Bug 312] xfsprogs does not compile on AMD64/x86_64 X-Bugzilla-Reason: AssignedTo X-archive-position: 2280 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bugzilla-daemon@oss.sgi.com Precedence: bulk X-list: linux-xfs http://oss.sgi.com/bugzilla/show_bug.cgi?id=312 ------- Additional Comments From nathans@sgi.com 2004-29-02 16:46 PDT ------- hi there, Yep, this is definately something we need to fix - thanks for doing this. > - libuuid="/usr/lib/libuuid.a") > + libuuid="-static -luuid") this unfortunately doesn't work either - if you run ldd on the resulting xfs_repair for example, you'll see it has no longer statically linked in the uuid library. This area of the config stuff could use some cleanups anyway, the BSD side is a bit wacky too. I think we'll need to use AC_LINK_IFELSE directly, and we should call it three times - once with no libuuid.a (this is the IRIX & BSD cases, where libc has these routines), once with /usr/lib/libuuid.a and then finally with /usr/lib64/libuuid.a. I think theres three macros in our configure scripts atm, they should be collapsed down to just one, and fold the --enable processing in there too. Would you be interested in hacking that up & testing the different options a bit? cheers. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.