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