On 1/7/08, 韓家標 Bill Hacker <askbill@conducive.net> wrote:
quoted text
> Finally - the principle architect/miracle worker of ZFS on FreeBSD - pjd@ -
> 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@:/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@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...
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"