Re: Sudden wierd SATA problem on RELENG_7 (Re: ZFS hanging at kernel boot now, but didn't before... (Re: ZFS MFC heads up))
on 23/05/2009 05:26 Alexander Motin said the following: Hi. Joe Karthauser wrote: I spoke too soon. It must have just randomly booted, because it is now hanging again. No amount of jiggling cables has made any difference. Can you provide verbose boot messages of your system from the beginning up to the problem? Especially, all related to the ATA. Attached. Do you have AHCI mode enabled in BIOS, or you using legacy ATA emulation? It's set up as AHCI in the bios. What is strange is that it has now started working again. I can't make any sense of it. The machine boots up fine. It was definitely hanging at the ata probes though, just after the ZFS messages are output. Joe Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-STABLE #7: Fri May 22 23:10:15 BST 2009 r...@athenaeum.tao.org.uk:/usr/obj/usr/src/sys/ATHENAEUM Preloaded elf kernel /boot/kernel/kernel at 0x80b47000. Preloaded elf module /boot/kernel/zfs.ko at 0x80b4719c. Preloaded elf module /boot/kernel/opensolaris.ko at 0x80b47244. Preloaded elf module /boot/kernel/geom_eli.ko at 0x80b472f4. Preloaded elf module /boot/kernel/crypto.ko at 0x80b473a4. Preloaded elf module /boot/kernel/zlib.ko at 0x80b47450. Preloaded elf module /boot/kernel/geom_label.ko at 0x80b474fc. Preloaded elf module /boot/kernel/geom_mirror.ko at 0x80b475ac. Preloaded /boot/zfs/zpool.cache /boot/zfs/zpool.cache at 0x80b4765c. Preloaded elf module /boot/kernel/acpi.ko at 0x80b476b4. module_register: module g_label already exists! Module g_label failed to register: 17 Calibrating clock(s) ... i8254 clock: 1192003 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2402413236 Hz CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2402.41-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line real memory = 3756916736 (3582 MB) Physical memory chunk(s): 0x1000 - 0x0009dfff, 643072 bytes (157 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0xdbf7, 3677728768 bytes (897883 pages) avail memory = 3673681920 (3503 MB) Table 'FACP' at 0xdfee30c0 Table 'HPET' at 0xdfee7e00 Table 'MCFG' at 0xdfee7e80 Table 'APIC' at 0xdfee7d00 MADT: Found table at 0xdfee7d00 MP Configuration Table version 1.4 found at 0x800f0d00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 3 ACPI ID 1: enabled SMP: Added CPU 3 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 1 ACPI ID 3: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: GBTGBTUACPI INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 bios32: Found BIOS32 Service Directory header at 0x800fad30 bios32: Entry = 0xfb3f0 (800fb3f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb420 pnpbios: Found PnP BIOS data at 0x800fbf90 pnpbios: Entry = f:bfc0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 3 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu group 1 ULE: setup cpu 1 ULE: adding cpu 1 to group 1: cpus 1 mask 0x2 ULE: setup cpu group 2 ULE: setup cpu 2 ULE: adding cpu 2 to group 2: cpus 1 mask 0x4 ULE: setup cpu group 3 ULE: setup cpu 3 ULE: adding cpu 3 to group 3: cpus 1 mask 0x8 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ACPI: RSDP @ 0x0xf6c30/0x0014 (v 0 GBT ) ACPI: RSDT @ 0x0xdfee3040/0x0034 (v 1 GBTGBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: FACP @ 0x0xdfee30c0/0x0074 (v 1 GBTGBTUACPI 0x42302E31 GBTU 0x01010101) ACPI: DSDT @ 0x0xdfee3180/0x4B32 (v 1 GBTGBTUACPI 0x1000 MSFT 0x010C) ACPI: FACS @ 0x0xdfee/0x0040 ACPI: HPET @
Re: ZFS NAS configuration question
On Sat, 30 May 2009 21:41:36 +0300 Dan Naumov dan.nau...@gmail.com wrote about ZFS NAS configuration question: DN So, this leaves me with 1 SATA port used for a FreeBSD disk and 4 SATA DN ports available for tinketing with ZFS. Do you have a USB port available to boot from? A conventional USB stick (I use 4 GB or 8GB these days, but smaller ones would certainly also do) is enough to hold the base system on UFS, and you can give the whole of your disks to ZFS without having to bother with booting from them. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /boot/loader can't load kernel if too many pool/devices
On 1 Jun 2009, at 11:22, Henri Hennebert wrote: Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error can't boot 'kernel' if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/ loader from 8.0-CURRENT. I recently increased the number of file descriptors available for / boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
On Tue, Jun 2, 2009 at 12:30 AM, Daniel Eischen deisc...@freebsd.org wrote: [...] Thank you all for your swift replies. It seems to indeed work for forked processes. The app at $work (written on and for Linux) transported an unnamed semaphore over a POSIX shared memory object. I'll probably make it a named semaphore and only send its name over the shared memory space. Regards, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
USB root partition for booting off UFS is something I have considered. I have looked around and it seems that all the install FreeBSD onto USB stick guides seem to involve a lot of manual work from a fixit environment, does sysinstall not recognise USB drives as a valid disk device to parition/label/install FreeBSD on? If I do go with an USB boot/root, what things I should absolutely keep on it and which are safe to move to a ZFS pool? The idea is that in case my ZFS configuration goes bonkers for some reason, I still have a fully workable singleuser configuration to boot from for recovery. I haven't really used USB flash for many years, but I remember when they first started appearing on the shelves, they got well known for their horrible reliability (stick would die within a year of use, etc). Have they improved to the point of being good enough to host a root partition on, without having to setup some crazy GEOM mirror setup using 2 of them? - Dan Naumov 2009/6/2 Gerrit Kühn ger...@pmp.uni-hannover.de On Sat, 30 May 2009 21:41:36 +0300 Dan Naumov dan.nau...@gmail.com wrote about ZFS NAS configuration question: DN So, this leaves me with 1 SATA port used for a FreeBSD disk and 4 SATA DN ports available for tinketing with ZFS. Do you have a USB port available to boot from? A conventional USB stick (I use 4 GB or 8GB these days, but smaller ones would certainly also do) is enough to hold the base system on UFS, and you can give the whole of your disks to ZFS without having to bother with booting from them. cu Gerrit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS weird device tasting loop since MFC
On Tue, 02.06.2009 at 11:16:10 +0200, Ulrich Spörlein wrote: Hi all, so I went ahead and updated my ~7.2 file server to the new ZFS goodness, and before running any further tests, I already discovered something weird and annoying. I'm using a mirror on GELI, where one disk is usually *not* attached as a means of poor man's backup. (I had to go that route, as send/recv of snapshots frequently deadlocked the system, whereas a mirror scrubbing did not) r...@coyote:~# zpool status pool: tank state: DEGRADED status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli errors: No known data errors When imported, there is a constant tasting of all devices in the system, which also makes the floppy drive go spinning constantly, which is really annoying. It did not do this with the old ZFS, are there any remedies? gstat(8) is displaying the following every other second, together with a spinning fd0 drive. dT: 1.010s w: 1.000s filter: ^...$ L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 0 0 00.0 0 00.00.0| fd0 0 8 8 10140.1 0 00.00.1| md0 0 32 32 40559.2 0 00.0 29.2| ad0 0 77 10 12677.1 63 11252.3 31.8| ad4 There is no activity going on, especially md0 is for /tmp, yet it constantly tries to read stuff from everywhere. I will now insert the second drive and see if ZFS shuts up then ... It does, but it also did not start resilvering the second disk: r...@coyote:~# zpool status pool: tank state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://www.sun.com/msg/ZFS-8000-9P scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 ad4.eli ONLINE 0 0 0 da0.eli ONLINE 0 016 errors: No known data errors Will now run the scrub and report back in 6-9h. Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS weird device tasting loop since MFC
Hi all, so I went ahead and updated my ~7.2 file server to the new ZFS goodness, and before running any further tests, I already discovered something weird and annoying. I'm using a mirror on GELI, where one disk is usually *not* attached as a means of poor man's backup. (I had to go that route, as send/recv of snapshots frequently deadlocked the system, whereas a mirror scrubbing did not) r...@coyote:~# zpool status pool: tank state: DEGRADED status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror DEGRADED 0 0 0 ad4.eli ONLINE 0 0 0 12333765091756463941 REMOVED 0 0 0 was /dev/da0.eli errors: No known data errors When imported, there is a constant tasting of all devices in the system, which also makes the floppy drive go spinning constantly, which is really annoying. It did not do this with the old ZFS, are there any remedies? gstat(8) is displaying the following every other second, together with a spinning fd0 drive. dT: 1.010s w: 1.000s filter: ^...$ L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name 0 0 0 00.0 0 00.00.0| fd0 0 8 8 10140.1 0 00.00.1| md0 0 32 32 40559.2 0 00.0 29.2| ad0 0 77 10 12677.1 63 11252.3 31.8| ad4 There is no activity going on, especially md0 is for /tmp, yet it constantly tries to read stuff from everywhere. I will now insert the second drive and see if ZFS shuts up then ... Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
On Tue, 2 Jun 2009, Dan Naumov wrote: USB root partition for booting off UFS is something I have considered. I have looked around and it seems that all the install FreeBSD onto USB stick guides seem to involve a lot of manual work from a fixit environment, does sysinstall not recognise USB drives as a valid disk device to parition/label/install FreeBSD on? If I do go with an USB boot/root, what things I should absolutely keep on it and which are safe to move to a ZFS pool? The idea is that in case my ZFS configuration goes bonkers for some reason, I still have a fully workable singleuser configuration to boot from for recovery. It should see them as SCSI disks, note that if you plug them in after the installer boots you will need to go into Options and tell it to rescan the devices. I haven't really used USB flash for many years, but I remember when they first started appearing on the shelves, they got well known for their horrible reliability (stick would die within a year of use, etc). Have they improved to the point of being good enough to host a root partition on, without having to setup some crazy GEOM mirror setup using 2 of them? I would expect one to last a long time if you only use it for /boot and use ZFS for the rest (or even just moving /var onto ZFS would save heaps of writes). Also, you could setup 2 USB sticks (install on one then dd onto the other) so you have a cold spare. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part.
Re: ZFS NAS configuration question
Daniel O'Connor wrote: On Tue, 2 Jun 2009, Dan Naumov wrote: USB root partition for booting off UFS is something I have considered. I have looked around and it seems that all the install FreeBSD onto USB stick guides seem to involve a lot of manual work from a fixit environment, does sysinstall not recognise USB drives as a valid disk device to parition/label/install FreeBSD on? If I do go with an USB boot/root, what things I should absolutely keep on it and which are safe to move to a ZFS pool? The idea is that in case my ZFS configuration goes bonkers for some reason, I still have a fully workable singleuser configuration to boot from for recovery. It should see them as SCSI disks, note that if you plug them in after the installer boots you will need to go into Options and tell it to rescan the devices. I haven't really used USB flash for many years, but I remember when they first started appearing on the shelves, they got well known for their horrible reliability (stick would die within a year of use, etc). Have they improved to the point of being good enough to host a root partition on, without having to setup some crazy GEOM mirror setup using 2 of them? I would expect one to last a long time if you only use it for /boot and use ZFS for the rest (or even just moving /var onto ZFS would save heaps of writes). I am using this setup (booting from USB with UFS) in our backup storage server with FreeBSD 7.2 + ZFS. 2GB USB flash disk contains normal installation of the whole system, but is set to read only in fstab. ZFS is used for /tmp /var /usr/ports /usr/src /usr/obj and storage. root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Miroslav Lachman # df -h Filesystem Size Used Avail Capacity Mounted on /dev/ufs/2gLive 1.6G 863M 642M57%/ devfs1.0K 1.0K 0B 100%/dev tank 1.1T 128K 1.1T 0%/tank tank/system 1.1T 128K 1.1T 0%/tank/system tank/system/usr 1.1T 128K 1.1T 0% /tank/system/usr tank/system/tmp 1.1T 128K 1.1T 0%/tmp tank/system/usr/obj 1.1T 128K 1.1T 0%/usr/obj tank/system/usr/ports1.1T 218M 1.1T 0%/usr/ports tank/system/usr/ports/distfiles 1.1T 108M 1.1T 0% /usr/ports/distfiles tank/system/usr/ports/packages 1.1T 125M 1.1T 0% /usr/ports/packages tank/system/usr/src 1.1T 171M 1.1T 0%/usr/src tank/system/var 1.1T 256K 1.1T 0%/var tank/system/var/db 1.1T 716M 1.1T 0%/var/db tank/system/var/db/pkg 1.1T 384K 1.1T 0%/var/db/pkg tank/system/var/log 1.1T 45M 1.1T 0%/var/log tank/system/var/run 1.1T 128K 1.1T 0%/var/run tank/vol02.6T 1.5T 1.1T57%/vol0 tank/vol0/mon1.1T 128K 1.1T 0%/vol0/mon (some filesystems are using compression, that's why ports and var are splitted in to more filesystems) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /boot/loader can't load kernel if too many pool/devices
Doug Rabson wrote: On 1 Jun 2009, at 11:22, Henri Hennebert wrote: Hello, During my tests (succesful) to directly boot from ZFS (with zfsboot and gptzfsboot) I encounter the error can't boot 'kernel' if too many devices/pools are connected to the machine. In my case: 2 SAS disks with 2 pools 2 SATA disks with 2 pools 1 USB key with one pool `heap` command: Active Allocations: 171/173 536576 bytes reserved 527800 bytes allocated `ls` command: open '/' failed: too many open files If I reboot without the USB key all is OK. If I reboot from the USB key after disconnecting 2 disks all is OK. By the way, the /boot/loader in 7.2-STABLE don't work, complains about forth not found. The previous tests were made with 7.2-STABLE (May 31) with /boot/loader from 8.0-CURRENT. I recently increased the number of file descriptors available for /boot/loader. Could you rebuild and try again please. Make sure you rebuild libstand.a as well as /boot/loader. OK - I can boot with the USB key and 4 disks Thanks Henri ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Does this work reliably for you? I tried doing the remounting trick, both for root and /usr, back in the 4.x time frame. And could never get it to work - would always end up with inconsistent file systems. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Crash with GJournal switcher
FreeBSD 7.2-RELEASE GPT + gmirror + gjournal May 31 10:15:48 netserv1 kernel: Fatal trap 9: general protection fault while in kernel mode May 31 10:15:48 netserv1 kernel: cpuid = 0; apic id = 00 May 31 10:15:48 netserv1 kernel: instruction pointer= 0x8:0x8059f667 May 31 10:15:48 netserv1 kernel: stack pointer = 0x10:0xfffe801e0a60 May 31 10:15:48 netserv1 kernel: frame pointer = 0x10:0xfffe801e0a90 May 31 10:15:48 netserv1 kernel: code segment = base 0x0, limit 0xf, type 0x1b May 31 10:15:48 netserv1 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 31 10:15:48 netserv1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 May 31 10:15:48 netserv1 kernel: current process= 39 (g_journal switcher) This caused one of my mirrors to become stale upon reboot. There wasn't any crash dumps. I've got WITNESS compiled at the moment, hopefully a crash/lockup will show something. Would the gjournal fail if one of the gmirror disks was faulty? Regards David N ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Crash with GJournal switcher
2009/6/2 David N david...@gmail.com: FreeBSD 7.2-RELEASE GPT + gmirror + gjournal May 31 10:15:48 netserv1 kernel: Fatal trap 9: general protection fault while in kernel mode May 31 10:15:48 netserv1 kernel: cpuid = 0; apic id = 00 May 31 10:15:48 netserv1 kernel: instruction pointer = 0x8:0x8059f667 May 31 10:15:48 netserv1 kernel: stack pointer = 0x10:0xfffe801e0a60 May 31 10:15:48 netserv1 kernel: frame pointer = 0x10:0xfffe801e0a90 May 31 10:15:48 netserv1 kernel: code segment = base 0x0, limit 0xf, type 0x1b May 31 10:15:48 netserv1 kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 31 10:15:48 netserv1 kernel: processor eflags = interrupt enabled, resume, IOPL = 0 May 31 10:15:48 netserv1 kernel: current process = 39 (g_journal switcher) This caused one of my mirrors to become stale upon reboot. There wasn't any crash dumps. I've got WITNESS compiled at the moment, hopefully a crash/lockup will show something. Would the gjournal fail if one of the gmirror disks was faulty? Regards David N lock order reversal: 1st 0x80b184c0 sleepq chain (sleepq chain) @ /usr/src/sys/kern/kern_sig.c:2291 2nd 0x80afb5b0 scrlock (scrlock) @ /usr/src/sys/dev/syscons/syscons.c:2519 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d sc_puts() at sc_puts+0x93 sc_cnputc() at sc_cnputc+0x5a cnputc() at cnputc+0x49 putchar() at putchar+0x6b kvprintf() at kvprintf+0x72 printf() at printf+0xa4 witness_checkorder() at witness_checkorder+0x44c _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d wakeup() at wakeup+0x11 tdsignal() at tdsignal+0x526 realitexpire() at realitexpire+0x3e softclock() at softclock+0x270 ithread_loop() at ithread_loop+0xe7 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffe8001cd30, rbp = 0 --- acquiring duplicate lock of same type: sleepq chain 1st sleepq chain @ /usr/src/sys/kern/kern_sig.c:2291 2nd sleepq chain @ /usr/src/sys/kern/subr_sleepqueue.c:232 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a witness_checkorder() at witness_checkorder+0x565 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x3d wakeup() at wakeup+0x11 tdsignal() at tdsignal+0x526 realitexpire() at realitexpire+0x3e softclock() at softclock+0x270 ithread_loop() at ithread_loop+0xe7 fork_exit() at fork_exit+0x112 fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xfffe8001cd30, rbp = 0 --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Unnamed POSIX shared semaphores
On Monday 01 June 2009 5:17:48 pm Bruce Simpson wrote: Jilles Tjoelker wrote: If process-shared semaphores really work, then the above structure is not a pathological case. Effectively, sem_t is carved in stone. So process-private semaphores should continue to have most of their stuff in a separately allocated structure, to preserve flexibility. There was an inadvertent race in FreeBSD's POSIX semaphores which I fixed in HEAD and STABLE about 6 weeks before 7.2 was released. I believe process-shared POSIX semaphores now work -- the Python 'multiprocessing' regression test now runs to completion with no errors on both HEAD and STABLE. The semaphores in recent 7 and 8 are definitely not process-shared (at least not intentionally). They may work across a fork accidentally, but you can't store it in an mmap() region and share it with an arbitrary process. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
sth...@nethelp.no wrote: root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Does this work reliably for you? I tried doing the remounting trick, both for root and /usr, back in the 4.x time frame. And could never get it to work - would always end up with inconsistent file systems. There were many fixes in this area lately. The case where a file system with softdeps would fail to update to read-only is fixed in -CURRENT and these changes are merged to -STABLE. It is believed to work correctly. http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046001.html Remounting with soft updates enabled used to be too fragile to be useful. Now it seems very solid. Nikos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: libzpool assert vs libc assert
on 01/06/2009 19:22 Andriy Gapon said the following: Henri, thank you very much for testing! It look like the patch did its job. P.S. hopefully someone is looking into the cause of the assertion. I think I cracked it. This is where ds-ds_lock.m_owner gets corrupted: (gdb) c Continuing. Watchpoint 8: *(void **) 34385649856 Old value = (void *) 0x0 New value = (void *) 0x8018f7ce0 0x000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 (gdb) bt #0 0x000800a731e6 in pthread_mutexattr_init () from /lib/libthr.so.3 #1 0x000800a733ca in pthread_mutex_getyieldloops_np () from /lib/libthr.so.3 #2 0x000800a736ab in pthread_mutex_isowned_np () from /lib/libthr.so.3 #3 0x0008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 ... (gdb) fr 3 #3 0x0008010398e5 in dsl_dataset_evict (db=0x8018c7cf0, dsv=0x8018b6000) at /usr/src/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264 264 if (mutex_owned(ds-ds_lock)) (gdb) list 259 if (ds-ds_dir) 260 dsl_dir_close(ds-ds_dir, ds); 261 262 ASSERT(!list_link_active(ds-ds_synced_link)); 263 264 if (mutex_owned(ds-ds_lock)) 265 mutex_exit(ds-ds_lock); mutex_owned is defined: cddl/contrib/opensolaris/head/thread.h #define mutex_owned(l) pthread_mutex_isowned_np(l) So we pass kmutex_t* parameter to pthread_mutex_isowned_np call where in fact we should be passing pthread_mutex_t* parameter. So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)-m_lock) Or it should be called on m_lock member of kmutex_t. Thanks to Henri for all the debugging info! -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: libzpool assert vs libc assert
on 02/06/2009 17:06 Andriy Gapon said the following: So I am quite sure that mutex_owned should be defined as follows: #define mutex_owned(l) pthread_mutex_isowned_np((l)-m_lock) Actually: #define mutex_owned(l) pthread_mutex_isowned_np((l)-m_lock) And on dangers of ignored compiler warnings: /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dmu.c:606: warning: passing argument 6 of 'dmu_buf_hold_array' discards qualifiers from pointer target type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:264: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:267: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type /usr/src-head/cddl/lib/libzpool/../../../sys/cddl/contrib/opensolaris/uts/common/fs/zfs/dsl_dataset.c:270: warning: passing argument 1 of 'pthread_mutex_isowned_np' from incompatible pointer type This is during libzpool compilation. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD-7.2 works excellent
Hello, just a word to say that the upgrade from FreeBSD-7.1 to 7.2 has solved all problems i had on my desktop (very slow windowing, etc.) without changing anything to the installed ports. Now everything works excellent in accordance with the FreeBSD tradition. Thanks for the good work of the developers -- Michel TALON ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
On Sun, May 31, 2009 at 4:43 AM, Aristedes Maniatis a...@ish.com.au wrote: On 31/05/2009, at 4:41 AM, Dan Naumov wrote: To top that off, even when/if you do it right, not your entire disk goes to ZFS anyway, because you still do need a swap and a /boot to be non-ZFS, so you will have to install ZFS onto a slice and not the entire disk and even SUN discourages to do that. ZFS on root is still pretty new to FreeBSD, and until it gets ironed out and all the sysinstall tools support it nicely, it isn't hard to use a small UFS slice to get things going during boot. And there is nothing wrong with putting ZFS onto a slice rather than the entire disk: that is a very common approach. It's worth noting that there are a few sensible appliance designs... (although as a ZFS server, you might want 4, 8 or 16G in your appliance). You could, for instance, boot from flash. If your true purpose is an appliance, this is very reasonable. It means that your appliance boots when no disks are attached. Useful to instruct the appliance user how to attache disks and do diagnostics, for instance. My own ZFS is 5x 1.5TB disks running on a few week old 8-CURRENT. I gave up waiting for v13 in 7.x. Maybe I should have waited. But I've avoided most of the most recent foo-for-ah by not tracking current incessantly. If I was installing new, I'd probably stick with 7.x for a server... for now. I must admit, however, that the system seems happy with 8-CURRENT. The system boots from a pair of drives in a gmirror. Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem. This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment. ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
sth...@nethelp.no wrote: root filesystem is remounted read write only for some configuration changes, then remounted back to read only. Does this work reliably for you? I tried doing the remounting trick, both for root and /usr, back in the 4.x time frame. And could never get it to work - would always end up with inconsistent file systems. The system is in production from October 2008 and never paniced in remounting. In this time frame, we got only two deadlocks caused by earlier versions of ZFS. At this time, files on ZFS are using 28151719 inodes, storage is for daily rsync backups of dozen webservers and mailserver. I am using mount -u -o current,rw / [do some configuration work] sync; sync; sync; mount -u -o current,ro / The sync command is maybe useless, but I feel safer with it ;o) (root filesystem is not using soft-updates) Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Do you use a value other than AUTO for network_interfaces?
Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
This reminds me. I was reading the release and upgrade notes of OpenSolaris 2009.6 and noted one thing about upgrading from a previous version to the new one:: When you pick the upgrade OS option in the OpenSolaris installer, it will check if you are using a ZFS root partition and if you do, it intelligently suggests to take a current snapshot of the root filesystem. After you finish the upgrade and do a reboot, the boot menu offers you the option of booting the new upgraded version of the OS or alternatively _booting from the snapshot taken by the upgrade installation procedure_. Reading that made me pause for a second and made me go WOW, this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) - Dan Naumov On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox zbee...@gmail.com wrote: The system boots from a pair of drives in a gmirror. Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem. This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment. ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
A little more info for the (perhaps) curious: Managing Multiple Boot Environments: http://dlc.sun.com/osol/docs/content/2009.06/getstart/bootenv.html#bootenvmgr Introduction to Boot Environments: http://dlc.sun.com/osol/docs/content/2009.06/snapupgrade/index.html - Dan Naumov On Tue, Jun 2, 2009 at 10:39 PM, Dan Naumov dan.nau...@gmail.com wrote: This reminds me. I was reading the release and upgrade notes of OpenSolaris 2009.6 and noted one thing about upgrading from a previous version to the new one:: When you pick the upgrade OS option in the OpenSolaris installer, it will check if you are using a ZFS root partition and if you do, it intelligently suggests to take a current snapshot of the root filesystem. After you finish the upgrade and do a reboot, the boot menu offers you the option of booting the new upgraded version of the OS or alternatively _booting from the snapshot taken by the upgrade installation procedure_. Reading that made me pause for a second and made me go WOW, this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) - Dan Naumov On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox zbee...@gmail.com wrote: The system boots from a pair of drives in a gmirror. Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem. This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment. ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
On 2 Jun 2009, at 21:20, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a ipv6_ifconfig_bge1=down and nail network_interfaces to bge0 bge1 lo0 only I'll get autoconfiguration of v6 where I don't want it to be. Being a bit of my own devils advocate here, network_interfaces=AUTO is already true for ipv6. with network_interfaces=bge0 lo0 network.subr nevertheless sees bge1, and no configuration and takes the responsibility of starting ipv6 autoconfiguration for it. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. you want to have a system where one still can control which interfaces are explicitly configured or skipped, with no side effects of default actions Thanks, Doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Regards, Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
Ruben van Staveren wrote: Being a bit of my own devils advocate here, network_interfaces=AUTO is already true for ipv6. FYI, ipv6_network_interfaces exists for this purpose. Thanks for your post, it's good information to add to the pile. Doug ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: On 2 Jun 2009, at 21:20, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. And while I'm not currently using anything other than AUTO I would think there is a security ramification if someone were to plug in to a supposedly unused port, then reboot the machine to prompt AUTO to configure their interface. Its not just a security thing, its an idiot-proof thing. If someone is moving machines around I don't want them to come up and partially work if the wires are plugged into the wrong holes. Would rather it be completely broken. I think its good that there is an AUTO *option*. Is also OK that it be the default. I don't think mandatory AUTO is good, if I want a port disabled then I want it to stay disabled. A quick glance of my 7.2-STABLE machine only found network_interfaces used in /etc/defaults/rc.conf. ipv6_network_interfaces is used in many places. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
On Tue, Jun 02, 2009 at 03:51:25PM -0500, David Kelly wrote: On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: On 2 Jun 2009, at 21:20, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. And while I'm not currently using anything other than AUTO I would think there is a security ramification if someone were to plug in to a supposedly unused port, then reboot the machine to prompt AUTO to configure their interface. Its not just a security thing, its an idiot-proof thing. If someone is moving machines around I don't want them to come up and partially work if the wires are plugged into the wrong holes. Would rather it be completely broken. I think its good that there is an AUTO *option*. Is also OK that it be the default. I don't think mandatory AUTO is good, if I want a port disabled then I want it to stay disabled. To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. For the system to do something with an interface the following must be true: - It makes it in to the list of interfaces somehow (either by adding it to network_interfaces or leaving network_interfaces alone) - It actually exists or is create early in the process via cloned_interfaces, gif_interfaces, etc - The ifconfig_if variable is set (I think i can be , but up is always a good choice if you just want a stub. - The ifconfig_if variable must not contain the NOAUTO keyword. If all of those things are true, the interface will be configured at startup or on insert. Otherwise, it won't be. -- Brooks [0] This is at least true in the IPv4 case, the IPv6 case really needs work. I thought someone had patches to bring the IPv6 support up to par with the IPv4 case, but they haven't been committed yet. pgpQtryU3OduY.pgp Description: PGP signature
Re: Do you use a value other than AUTO for network_interfaces?
On Tue, Jun 02, 2009 at 10:30:46PM +0200, Ruben van Staveren wrote: On 2 Jun 2009, at 21:20, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. See my other post on why this is a needless worry for the IPv4 case. e.g. bge0 connected, bge1 not, v6 autoconf on the lan. if I don't do a ipv6_ifconfig_bge1=down and nail network_interfaces to bge0 bge1 lo0 only I'll get autoconfiguration of v6 where I don't want it to be. Being a bit of my own devils advocate here, network_interfaces=AUTO is already true for ipv6. with network_interfaces=bge0 lo0 network.subr nevertheless sees bge1, and no configuration and takes the responsibility of starting ipv6 autoconfiguration for it. The IPv6 case is clearly a bug. We should really consolidate the two cases and I think there are patches to do so if someone wants to setup up and help get them in. -- Brooks pgpmOFAe0FIRr.pgp Description: PGP signature
Re: Do you use a value other than AUTO for network_interfaces?
I only want to configure only the interfaces that are connected and that I know about. especially in combination with IPv6 there is a nit that you'll get autoconfiguration for all interfaces unless they are all explicitly configured. bingo! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. such as detected by services such as bind/unbound? randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
Ruben van Staveren writes: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. Well, I do. I only want to configure only the interfaces that are connected and that I know about. What he said. In my case complicated by the fact the interfaces in question do some wierd-ass initialization (which is legacy from like sometime in 5.x and might be unnecessary ... but it took a long time to get working and isn't broke). Robert Huff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS NAS configuration question
I have a proof of concept system doing this. I started with a 7.2 install on zfs root, compiled world and kernel from 8, took a snapshot and made a clone for the 7.2 install, and proceeded to upgrade the current fs to 8.0. After updating the loader.conf in the 7.2 zfs to point to its own cloned fs, I can pick which one to boot with a simple zpool set bootfs=z/ROOT/7.2 or zpool set bootfs=z/ROOT/8.0 before rebooting. I also tried rsyncing from a FFS based system into a new ZFS in that same zpool, used DESTDIR with installkernel and installworld to update the imported OS to support zfs, setup its boot loader and misc config files, and was able to boot from it using zpool to set it as the bootfs. Somewhat like shifting around OS images in a virtualization environment except its easy to reach inside the image to upgrade/modify it, copy them between systems, and no execution overhead while running one since its still on bare metal (but only one running OS per server of course). This makes it very easy to swap an OS onto another server if you need better/lesser hardware or just want to test. Dan Naumov wrote: This reminds me. I was reading the release and upgrade notes of OpenSolaris 2009.6 and noted one thing about upgrading from a previous version to the new one:: When you pick the upgrade OS option in the OpenSolaris installer, it will check if you are using a ZFS root partition and if you do, it intelligently suggests to take a current snapshot of the root filesystem. After you finish the upgrade and do a reboot, the boot menu offers you the option of booting the new upgraded version of the OS or alternatively _booting from the snapshot taken by the upgrade installation procedure_. Reading that made me pause for a second and made me go WOW, this is how UNIX system upgrades should be done. Any hope of us lowly users ever seeing something like this implemented in FreeBSD? :) - Dan Naumov On Tue, Jun 2, 2009 at 9:47 PM, Zaphod Beeblebrox zbee...@gmail.com wrote: The system boots from a pair of drives in a gmirror. Mot because you can't boot from ZFS, but because it's just so darn stable (and it predates the use of ZFS). Really there are two camps here --- booting from ZFS is the use of ZFS as the machine's own filesystem. This is one goal of ZFS that is somewhat imperfect on FreeBSD at the momment. ZFS file servers are another goal where booting from ZFS is not really required and only marginally beneficial. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Do you use a value other than AUTO for network_interfaces?
On Wed, Jun 03, 2009 at 07:22:34AM +0900, Randy Bush wrote: To repeat what I wrote earlier today on another list there's no need to worry about hot plugged or newly added interfaces getting magically configured to do dhcp or anything else[0]. such as detected by services such as bind/unbound? The rc system will do nothing with interfaces that don't pass the tests I enumerated so if you don't have an ifconfig_if interface there won't be any difference no matter how you set network_interfaces. I'd be rather supprised if bind did anything with interaces that weren't configured with an address (or even up in the case of correctly funtioning drivers). -- Brooks pgpvekOcFGdVy.pgp Description: PGP signature
Re: Do you use a value other than AUTO for network_interfaces?
On Tue, Jun 02, 2009 at 12:20:34PM -0700, Doug Barton wrote: Up till Sunday in 8-current, and for a long time in general network.subr (part of the rc.d system) has emitted a warning that values of network_interfaces other than AUTO are deprecated. I removed that warning in HEAD Sunday, and there is no a discussion about whether or not it should be put back, and whether or not there is any need for the user to specify the list of network interfaces at all. If you use a value of network_interfaces other than AUTO please speak up so that we can make an intelligent decision about this issue. Thanks, Doug I'll have to preface this by disclosing that I have not been running -current, nor following any changes to the RC system. In 7.1, if you compile a custom kernel and comment out an interface (such that it is compiled as a module), one way to ensure that the module is loaded is to explicitly list it in network_interfaces. If -current works the same way, then users will be required to modify /boot/loader.conf in order to load the module. Could there could be possible side-effects to this change, since the loading of the module happens at a different time? At best, users doing things the 'network_interfaces' way may be in for a surprise when the update (remotely), and this may be worthy of a note in UPDATING. If this has changed in 7.2 or -current, then I apologize for the noise! Erik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
