On 1/7/08, 韓家標 Bill Hacker <askbill_at_conducive.net> wrote: > Finally - the principle architect/miracle worker of ZFS on FreeBSD - pjd_at_ - > seems to be heavily committed on other matters now, and may be so for some time > to come. > > Ergo 'caution' remains appropriate for production use w/r ZFS - perhaps until 8.X. I agree. I build a new backup server ( DualCore processor, AMD64 Kernel, 3GB Ram, 10x 500GB Sata disks, areca 1230) to receive data from all my local servers on a 4TB zfs pool (using compression, ~ 300 snapshots and ~90 filesystems) and after write to LTO3 Tape Drives. It worked fine after the required tuning (vm patch, prefetch disable, etc) But I lost my data two times. The first was in 11/12/2007, the system freeze and after reboot I get the panic when trying to mount the zfs pool: Dump header from device /dev/ad0s1b Architecture: amd64 Architecture Version: 2 Dump Length: 103477248B (98 MB) Blocksize: 512 Dumptime: Mon Nov 12 14:56:12 2007 Hostname: Magic: FreeBSD Kernel Dump Version String: FreeBSD 7.0-BETA2 #0: Mon Nov 12 11:49:07 BRST 2007 root_at_:/usr/src/sys/amd64/compile/MANNY.debug Panic String: solaris assert: ss == NULL, file: /usr/src/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/space_map.c, line: 110 Dump Parity: 2217569595 Bounds: 3 Dump Status: good after some days giving some shots with Pawel (and his contact with solaris people), we can't figure out the problem, I assume the lost and recreate the zpool. I decided to give another try, put more memory, do more "tuning" and after one month all worked fine except the slowness when coping small files to a tape drive (a started a new thread about that on -performance http://www.mail-archive.com/freebsd-performance_at_freebsd.org/msg01764.html) when I get another crash, this time with: ZFS(panic): zfs: allocating allocated segment(offset=2781261201408 size=131072) And again, I can't recover my zpool. I had choose zfs because the fantastic features available, instant snapshots, clones, native/transparent compression, the way that you can create filesystems inside the pool limiting and reserving space, all this make my backup solution simple amazing. But this crashes forced me to step back and without a filesystem that can handle TB without tedious fsck a had to go with CentOS+ext3. I'm a FreeBSD lover, using this as much as I can, at work all gateways, firewalls, proxy, fileservers, pop, imap, smtp, ldap and were FreeBSD fit this is my preference. I work with Free since 2.2.6 and I only give up when there is no choice. This case unfortunately was one of that I have no choice. Best Regards, Alexandre Biancalana ps: excuse me for my bad english...Received on Mon Jan 07 2008 - 14:23:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:25 UTC