Error in 7.0p5 upgrade
Hi all, I'm upgrading a FreeBSD amd64 box from 6.2p9 to 7.0p5. After update the sources amd make world with success, I get this error: [...] newfs.lo(.text+0x659): In function `main': : undefined reference to `__mb_sb_limit' newfs_msdos.lo(.text+0x13): In function `mklabel': : undefined reference to `__mb_sb_limit' restore.lo(.text+0xc60): In function `mkentry': : undefined reference to `__mb_sb_limit' restore.lo(.text+0xa6d6): In function `rmthost': : undefined reference to `__mb_sb_limit' sysctl.lo(.text+0xf9f): more undefined references to `__mb_sb_limit' follow tar.lo(.text+0x28f4): In function `read_archive': : undefined reference to `archive_read_support_compression_program' tar.lo(.text+0x3a81): In function `yes': : undefined reference to `__mb_sb_limit' tar.lo(.text+0x432a): In function `safe_fprintf': : undefined reference to `__mb_sb_limit' tar.lo(.text+0x6156): In function `tar_mode_c': : undefined reference to `archive_write_set_compression_program' vi.lo(.text+0x2f80): In function `cut': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x2fb0): In function `cut': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x311e): In function `cut': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x5c29): In function `v_key_name': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x5cf3): In function `v_key_name': : undefined reference to `__mb_sb_limit' vi.lo(.text+0x63b8): more undefined references to `__mb_sb_limit' follow *** Error code 1 Stop in /usr/obj/usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue/rescue. *** Error code 1 Stop in /usr/src/rescue. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. after try the classical kernel compilation ( cd /usr/src && make -DINSTALL_NODEBUG KERNCONF=MYKERNEL) I've not found any related info in the net. Anyones knows about? Last week I upgraded two others 6.2 amd boxes without problem. PD1. I use the "classical" method over "new" binary method because of my kernel is customized. PD2. I use -DINSTALL_NODEBUG flag because of my / partition is so small and need to preserve the maximum space. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Want one of the affected systems for your lab? (Was: 6.4 RC1 locks up solid on first reboot)
John, I can ship you one of these machines for your own testing if you like. Or send me a public key and I can give you SSH access to the console serial port, whichever would be easiest for you to get what you need. Let me know how I can help. On Nov 5, 2008, at 3:41 PM, Jo Rhett wrote: On Oct 27, 2008, at 8:51 AM, John Baldwin wrote: On Friday 24 October 2008 02:48:13 pm Jo Rhett wrote: So I booted up by CD and used Fixit mode to switch the system to boot via serial (keyboard detached), but this gathered me even less. /boot.config: -Dh Consoles: internal video/keyboard serial port BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/4062144kB available memory FreeBSD/i386 bootstrap loader, Revision 1.1 ([EMAIL PROTECTED] Plugging back in the monitor after lockup showed only a single char more: ([EMAIL PROTECTED] This confirms it is hanging in one of the two BIOS routines to output a character. One thing you can do would be to boot up and do the following: dd if=/dev/mem bs=0x400 count=1 of=idt.out dd if=/dev/mem bs=64k iseek=15 count=1 of=bios.out Then place those files some place I can fetch them. Both files are at http://support.netconsonance.com/freebsd/ FYI, this is notable -- the keyboard does not respond at the boot prompt. I mean the menu where you can escape to the loader prompt, with the fat freebsd ascii art. No keyboard presses are observed here. This is also true for the boot menu on the 6.4 installation CD too. No problems with 6.2 or 6.3 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED] " ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will XFS be adopted
Bartosz Stec wrote: Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) How did it crash ? Just the system went down or did you lose any data ? I'm planning to build new home server and put all my valuable data on ZFS but after reading all the mailing lists I'm not so sure about it. :( M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LORs in RELENG_7
Hi, I'm running my RELENG_7 kernel with WITNESS and there's always a LOR when pf(4) is enabled: lock order reversal: 1st 0xc09ca828 ifnet (ifnet) @ /usr/src/sys/net/if.c:849 2nd 0xc45d604c pf task mtx (pf task mtx) @ /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:916 KDB: stack backtrace: db_trace_self_wrapper(c08df797,fb671764,c0630e8e,c08e1c96,c45d604c,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08e1c96,c45d604c,c45d3b1c,c45d3b1c,c45d379e,...) at kdb_backtrace+0x29 witness_checkorder(c45d604c,9,c45d379e,394,c08e9058,...) at witness_checkorder+0x6de _mtx_lock_flags(c45d604c,0,c45d379e,394,fb6717dc,...) at _mtx_lock_flags+0xbc pfi_attach_group_event(0,c445,c08e9058,374,c44a920c,...) at pfi_attach_group_event+0x4e if_addgroup(c441c000,c08f70d6,4,0,0,...) at if_addgroup+0x2c7 if_clone_createif(0,0,c08e9563,87,0,...) at if_clone_createif+0x81 if_clone_create(fb671943,4,0,44,180,...) at if_clone_create+0x8c tunclone(0,c461e400,fb671943,4,fb67195c,...) at tunclone+0x17a devfs_lookup(fb6719d0,fb6719d0,fb671b7c,c418de04,2,...) at devfs_lookup+0x50e VOP_LOOKUP_APV(c0928f40,fb6719d0,c412f230,c08e77ef,2a9,...) at VOP_LOOKUP_APV+0xa5 lookup(fb671b7c,c08e77ef,c6,bf,c461e92c,...) at lookup+0x58e namei(fb671b7c,c412f230,fb671a74,246,c0983774,...) at namei+0x34b vn_open_cred(fb671b7c,fb671c78,ce8,c461e400,c4460558,...) at vn_open_cred+0x2c9 vn_open(fb671b7c,fb671c78,ce8,c4460558,c05e807d,...) at vn_open+0x33 kern_open(c412f230,80a0f18,0,3,808ecfa,...) at kern_open+0xe7 open(c412f230,fb671cfc,c,c08e28c3,c092c0b8,...) at open+0x30 syscall(fb671d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2835a65b, esp = 0xbfbfeafc, ebp = 0xbfbfeb38 --- And there are these LORs when I shut down my external firewire attached disk: fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=2, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex sbp r = 0 (0xc402f7ac) locked @ /usr/src/sys/dev/firewire/sbp.c:2203 KDB: stack backtrace: db_trace_self_wrapper(c08df797,f93a931c,c0630007,c08dfb5a,f93a9330,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08dfb5a,f93a9330,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c0901ae5,c08c59ce,86,...) at witness_warn+0x1d7 uma_zalloc_arg(c1472960,0,2,2,f93a93e0,...) at uma_zalloc_arg+0x34 malloc(b,c09308c0,2,c05be59a,c08d7a2c,...) at malloc+0xd2 notify(c4150a00,4,c08d7856,34f,c05be4ea,...) at notify+0x49 destroy_devl(f93a9410,c046a6ce,c4150a00,0,c3f18370,...) at destroy_devl+0x236 destroy_dev(c4150a00,0,c3f18370,c3f69000,f93a9690,...) at destroy_dev+0x10 passcleanup(c3f69000,c08b50c7,0,0,0,...) at passcleanup+0x2e camperiphfree(c3f69000,0,f93a96b0,c04568dd,c3f69000,...) at camperiphfree+0xbb cam_periph_invalidate(c3f69000,c0983774,f93a96e4,c046a5ea,c3f69000,...) at cam_periph_invalidate+0x3e cam_periph_async(c3f69000,100,c418a260,0,f93a96e0,...) at cam_periph_async+0x2d passasync(c3f69000,100,c418a260,0,c42f8c00,...) at passasync+0xca xpt_async_bcast(0,4,c08b53c5,11a5,c404d280,...) at xpt_async_bcast+0x32 xpt_async(100,c418a260,0,89b,0,...) at xpt_async+0x194 sbp_cam_detach_sdev(c402f45c,0,c402f418,0,f93a982c,...) at sbp_cam_detach_sdev+0xa4 sbp_cam_detach_target(c14729a8,c14729a8,c08250c6,c7373b40,10,...) at sbp_cam_detach_target+0x5b sbp_post_explore(c402f400,f93a9ce8,f93a9ce4,675,0,...) at sbp_post_explore+0xa2 fw_bus_probe_thread(c404f000,f93a9d38,c08d8d0f,31c,c402b570,...) at fw_bus_probe_thread+0x69b fork_exit(c0513500,c404f000,f93a9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf93a9d70, ebp = 0 --- (da0:sbp0:0:0:0): lost device (da0:sbp0:0:0:0): removing device entry cam_periph_alloc: attempt to re-allocate valid device pass1 rejected passasync: Unable to attach new device due to status 0x6: CCB request was invalid cam_periph_alloc: attempt to re-allocate valid device da1 rejected daasync: Unable to attach to new device due to status 0x6 fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=3, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex sbp r = 0 (0xc402f7ac) locked @ /usr/src/sys/dev/firewire/sbp.c:2203 KDB: stack backtrace: db_trace_self_wrapper(c08df797,f93a931c,c0630007,c08dfb5a,f93a9330,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08dfb5a,f93a9330,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c0901ae5,c08c59ce,86,...) at witness_warn+0x1d7 uma_zalloc_arg(c1472960,0,2,2,f93a93e0,...) at uma_zalloc_arg+0x34 malloc(b,c09308c0,2,c05be59a,c08d7a2c,...) at malloc+0xd2 notify(c4150d00,4,c08d7856,34f,c05be4ea,...) at notify+0x49 destroy_devl(f93a9410,c046a6ce,c4150d00,0,c3f18370,...) at destroy_devl+0x236 destroy_dev(c4150d00,0,c3f18370,c42c6700,f93a9690,...) at destro
Re: LORs in RELENG_7
On Thu, Nov 20, 2008 at 4:11 PM, Ulrich Spoerlein <[EMAIL PROTECTED]>wrote: > Hi, > > I'm running my RELENG_7 kernel with WITNESS and there's always a LOR > when pf(4) is enabled: > > lock order reversal: > 1st 0xc09ca828 ifnet (ifnet) @ /usr/src/sys/net/if.c:849 > 2nd 0xc45d604c pf task mtx (pf task mtx) @ > /usr/src/sys/modules/pf/../../contrib/pf/net/pf_if.c:916 > KDB: stack backtrace: > db_trace_self_wrapper(c08df797,fb671764,c0630e8e,c08e1c96,c45d604c,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08e1c96,c45d604c,c45d3b1c,c45d3b1c,c45d379e,...) at > kdb_backtrace+0x29 > witness_checkorder(c45d604c,9,c45d379e,394,c08e9058,...) at > witness_checkorder+0x6de > _mtx_lock_flags(c45d604c,0,c45d379e,394,fb6717dc,...) at > _mtx_lock_flags+0xbc > pfi_attach_group_event(0,c445,c08e9058,374,c44a920c,...) at > pfi_attach_group_event+0x4e > if_addgroup(c441c000,c08f70d6,4,0,0,...) at if_addgroup+0x2c7 > if_clone_createif(0,0,c08e9563,87,0,...) at if_clone_createif+0x81 > if_clone_create(fb671943,4,0,44,180,...) at if_clone_create+0x8c > tunclone(0,c461e400,fb671943,4,fb67195c,...) at tunclone+0x17a > devfs_lookup(fb6719d0,fb6719d0,fb671b7c,c418de04,2,...) at > devfs_lookup+0x50e > VOP_LOOKUP_APV(c0928f40,fb6719d0,c412f230,c08e77ef,2a9,...) at > VOP_LOOKUP_APV+0xa5 > lookup(fb671b7c,c08e77ef,c6,bf,c461e92c,...) at lookup+0x58e > namei(fb671b7c,c412f230,fb671a74,246,c0983774,...) at namei+0x34b > vn_open_cred(fb671b7c,fb671c78,ce8,c461e400,c4460558,...) at > vn_open_cred+0x2c9 > vn_open(fb671b7c,fb671c78,ce8,c4460558,c05e807d,...) at vn_open+0x33 > kern_open(c412f230,80a0f18,0,3,808ecfa,...) at kern_open+0xe7 > open(c412f230,fb671cfc,c,c08e28c3,c092c0b8,...) at open+0x30 > syscall(fb671d38) at syscall+0x2b3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x2835a65b, esp = 0xbfbfeafc, > ebp = 0xbfbfeb38 --- > > > Are you using user or group rules in your pf.conf? IIRC there is still a known LOR in the socket layer with rules using the user or group filters. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Modest MFC request: src/Makefile.inc1, rev. 1.614 (SVN rev 184860)
I'm writing to encourage an MFC for src/Makefile.inc1, rev. 1.614. I tested it for the committer. :-} And if we're to make use of amd64 arch "build" machines at $WORK, we'll need that change. (Symptoms prior to the commit are that 32-bit executables that use crypto libraries will fail to run because the 32-bit crypto libraries won't be found. And since the version of CVS that our developers use is linked against crypto libraries (as that's the default), that's just one example of a fairly basic bit of infrastructure that would be broken.) It's been in CURRENT for over a week --and as obrien@ noted, we've been building the libraries all along; the install32 target just didn't include them, so we weren't installing them. Please? Thanks! Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpb4lOJxIP9r.pgp Description: PGP signature
Re: LORs in RELENG_7
And there are these LORs when I shut down my external firewire attached disk: fwohci0: BUS reset fwohci0: node_id=0xc800ffc1, gen=2, CYCLEMASTER mode firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me) firewire0: bus manager 1 (me) uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex sbp r = 0 (0xc402f7ac) locked @ /usr/src/sys/dev/firewire/sbp.c:2203 KDB: stack backtrace: db_trace_self_wrapper(c08df797,f93a931c,c0630007,c08dfb5a,f93a9330,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08dfb5a,f93a9330,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c0901ae5,c08c59ce,86,...) at witness_warn+0x1d7 uma_zalloc_arg(c1472960,0,2,2,f93a93e0,...) at uma_zalloc_arg+0x34 malloc(b,c09308c0,2,c05be59a,c08d7a2c,...) at malloc+0xd2 notify(c4150a00,4,c08d7856,34f,c05be4ea,...) at notify+0x49 destroy_devl(f93a9410,c046a6ce,c4150a00,0,c3f18370,...) at destroy_devl+0x236 destroy_dev(c4150a00,0,c3f18370,c3f69000,f93a9690,...) at destroy_dev+0x10 passcleanup(c3f69000,c08b50c7,0,0,0,...) at passcleanup+0x2e camperiphfree(c3f69000,0,f93a96b0,c04568dd,c3f69000,...) at camperiphfree+0xbb cam_periph_invalidate(c3f69000,c0983774,f93a96e4,c046a5ea,c3f69000,...) at cam_periph_invalidate+0x3e cam_periph_async(c3f69000,100,c418a260,0,f93a96e0,...) at cam_periph_async+0x2d passasync(c3f69000,100,c418a260,0,c42f8c00,...) at passasync+0xca xpt_async_bcast(0,4,c08b53c5,11a5,c404d280,...) at xpt_async_bcast+0x32 xpt_async(100,c418a260,0,89b,0,...) at xpt_async+0x194 sbp_cam_detach_sdev(c402f45c,0,c402f418,0,f93a982c,...) at sbp_cam_detach_sdev+0xa4 sbp_cam_detach_target(c14729a8,c14729a8,c08250c6,c7373b40,10,...) at sbp_cam_detach_target+0x5b sbp_post_explore(c402f400,f93a9ce8,f93a9ce4,675,0,...) at sbp_post_explore+0xa2 fw_bus_probe_thread(c404f000,f93a9d38,c08d8d0f,31c,c402b570,...) at fw_bus_probe_thread+0x69b fork_exit(c0513500,c404f000,f93a9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf93a9d70, ebp = 0 --- (da0:sbp0:0:0:0): lost device (da0:sbp0:0:0:0): removing device entry cam_periph_alloc: attempt to re-allocate valid device pass1 rejected passasync: Unable to attach new device due to status 0x6: CCB request was invalid cam_periph_alloc: attempt to re-allocate valid device da1 rejected daasync: Unable to attach to new device due to status 0x6 fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=3, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) uma_zalloc_arg: zone "16" with the following non-sleepable locks held: exclusive sleep mutex sbp r = 0 (0xc402f7ac) locked @ /usr/src/sys/dev/firewire/sbp.c:2203 KDB: stack backtrace: db_trace_self_wrapper(c08df797,f93a931c,c0630007,c08dfb5a,f93a9330,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08dfb5a,f93a9330,4,1,0,...) at kdb_backtrace+0x29 witness_warn(5,0,c0901ae5,c08c59ce,86,...) at witness_warn+0x1d7 uma_zalloc_arg(c1472960,0,2,2,f93a93e0,...) at uma_zalloc_arg+0x34 malloc(b,c09308c0,2,c05be59a,c08d7a2c,...) at malloc+0xd2 notify(c4150d00,4,c08d7856,34f,c05be4ea,...) at notify+0x49 destroy_devl(f93a9410,c046a6ce,c4150d00,0,c3f18370,...) at destroy_devl+0x236 destroy_dev(c4150d00,0,c3f18370,c42c6700,f93a9690,...) at destroy_dev+0x10 passcleanup(c42c6700,c08b50c7,c09eff00,4,c08db41b,...) at passcleanup+0x2e camperiphfree(c42c6700,0,f93a96b0,c04568dd,c42c6700,...) at camperiphfree+0xbb cam_periph_invalidate(c42c6700,c0983774,f93a96e4,c046a5ea,c42c6700,...) at cam_periph_invalidate+0x3e cam_periph_async(c42c6700,100,c418a250,0,f93a96e0,...) at cam_periph_async+0x2d passasync(c42c6700,100,c418a250,0,c42f8a00,...) at passasync+0xca xpt_async_bcast(0,4,c08b53c5,11a5,c404d280,...) at xpt_async_bcast+0x32 xpt_async(100,c418a250,0,89b,0,...) at xpt_async+0x194 sbp_cam_detach_sdev(c402f4c8,0,c402f484,1,f93a982c,...) at sbp_cam_detach_sdev+0xa4 sbp_cam_detach_target(c14729a8,c14729a8,c08250c6,c44263f0,10,...) at sbp_cam_detach_target+0x5b sbp_post_explore(c402f400,f93a9ce8,f93a9ce4,675,0,...) at sbp_post_explore+0xa2 fw_bus_probe_thread(c404f000,f93a9d38,c08d8d0f,31c,c402b570,...) at fw_bus_probe_thread+0x69b fork_exit(c0513500,c404f000,f93a9d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf93a9d70, ebp = 0 --- (da1:sbp0:0:1:0): lost device (da1:sbp0:0:1:0): removing device entry I reckon these problems should appear in -STABLE ... Cheers, Ulrich Spoerlein You are able to make this happen simply by powering off your Firewire Hard Drive? What about pulling the cable out? -- Sean Bruno MiraLink Corporation 6015 NE 80th Ave, Ste 100 Portland, OR 97218 Cell 503-358-6832 Phone 503-621-5143 Fax 503-621-5199 MSN: [EMAIL PROTECTED] Google: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
(actually ZFS) Re: Will XFS be adopted
martinko wrote: Bartosz Stec wrote: Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) How did it crash ? Just the system went down or did you lose any data ? Read my previous email on tuning your system so ZFS doesn't crash. I'm planning to build new home server and put all my valuable data on ZFS but after reading all the mailing lists I'm not so sure about it. :( I've been using it on a shared machine with hundreds of customers for over 8 months. It has worked flawlessly. People who complain about the crashes often have not searched the net for: "freebsd zfs tuning". Speaking of losing data on a ZFS system, I haven't yet (knock on wood) had a disk failure. Anyone have a disk failure occur and have an easy/hard time replacing the bad disk? Rudy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (actually ZFS) Re: Will XFS be adopted
Rudy wrote: Speaking of losing data on a ZFS system, I haven't yet (knock on wood) had a disk failure. Anyone have a disk failure occur and have an easy/hard time replacing the bad disk? On a system with AHCI, I can literally yank the SATA disks, zfs keeps working after a pause, and when I replace them, it rebuilds without intervention. However with the latest 8-current this stopped working and now the system crashes when I try this without using "atacontrol". But it seems related to ATA code and not ZFS. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: (actually ZFS) Re: Will XFS be adopted
On Thu, 20 Nov 2008, Rudy wrote: martinko wrote: Bartosz Stec wrote: Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) How did it crash ? Just the system went down or did you lose any data ? Read my previous email on tuning your system so ZFS doesn't crash. I'm planning to build new home server and put all my valuable data on ZFS but after reading all the mailing lists I'm not so sure about it. :( I've been using it on a shared machine with hundreds of customers for over 8 months. It has worked flawlessly. People who complain about the crashes often have not searched the net for: "freebsd zfs tuning". Speaking of losing data on a ZFS system, I haven't yet (knock on wood) had a disk failure. Anyone have a disk failure occur and have an easy/hard time replacing the bad disk? I had a Samsung drive fail on me a few months back. Samsung does not do "advance shipment" like Seagate or WD. I had to run a raidz one drive short for about a week. The replacement was as simple as you'd expect - "zpool replace ..." Note, I will not be purchasing any more Samsung drives :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Will XFS be adopted
martinko pisze: Bartosz Stec wrote: Well it's not simple indeed. I use ZFS on my home (not critical) box (RAIDZ1). After 4 weeks uptime with varied workload I assumed it's stable. Unfortunately ZFS crashed next week ;) How did it crash ? Just the system went down or did you lose any data ? I'm planning to build new home server and put all my valuable data on ZFS but after reading all the mailing lists I'm not so sure about it. :( M. I didn't loose any data , and system was up (ping and packet filter did still working), but filesystem was unaccesible so any kind of process which need hdd acces didn't work correctly (like ssh shell or mail server). Hard reboot was one and only solution ;) Feel free to test ZFS for yourself. Good tuning should made it stable enough for you. You also shouldn't worry for your data, ZFS problems are mainly related to kernel memory exhaustion, not a data corruption (Backups however are always recomended before tasks like this). Check the ZFS tuning guide http://wiki.freebsd.org/ZFSTuningGuide and good luck. My home system is i386 with 1,5GB of memory and tuned with: KERNEL: options KVA_PAGES=512 loader.conf: vm.kmem_size="1024M" vm.kmem_size_max="1024M" It's a very simple tuning, just for tests. My system probably needs ARC settings or vfs.zfs.prefetch_disable=1 to be (more) stable. I'll do more tests, but you probably should do your own - there's no one good tuning solution for every system configuration. Just search this list - there's a lot of examples and hints. Jeremy Chadwick explained a lot of those settings too. -- Bartosz Stec AUXILIA Spółka z o.o. ul. Wałbrzyska 43/2 52-314 Wrocław tel. (71) 79 99 760 w. 69 GSM: 662171775 E-Mail: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
