On Mon, Oct 20, 2008 at 03:10, gm_sjo <[EMAIL PROTECTED]> wrote: > I appreciate 99% of the time people only comment if they have a > problem, which is why I think it'd be nice for some people who have > successfully implemented ZFS, including making various use of the > features (recovery, replacing disks, etc), could just reply to this > post with a sentence or paragraph detailing how great it is for them. My initial test of zfs was with a few IDE disks which I had found flaky on other platforms (md5 mismatches, that kind of thing). I put them all in a non-redundant pool, and loaded some data on the pool. Then I let it sit in the corner serving NFS for a couple weeks, scrubbed the pool every once in a while, and watched the error counters. It confirmed what I'd seen: these disks gave off errors spontaneously. This was a good start: the first time I'd seen a storage stack that had the audacity to complain about problems with its hardware.
So I upgraded, and put in "known-good" disks. I started with a mirrored pair of 750s, then added another pair, then added a pair of log disks. At each step, things moved smoothly, and speed increased. I've also helped my brother set up a Solaris/ZFS setup, on a bit larger scale but with a more static configuration. He started with Linux, md raid, and XFS, using raid 5 on 8 320GB disks and a Supermicro AOC-SAT2-MV8 Marvell controller. Unfortunately, he lost basically the entire array due to corruption in some layer of the stack. So I suggested ZFS as an alternative. This was around Build 67 of Nevada. He put his 8 disks in a raidz pool. About a year ago, he bought six 500gb disks and another Marvell controller, made a new raidz vdev (in a new pool) out of them, and added six of the 320gb disks in another vdev. A month or so ago, he bought six 1TB disks, made a new pool out of them, and moved all his data over to it. At each step of the way, he upgraded to solve a problem. Moving from Linux to Solaris was because it had better drivers for the Marvell-based card. Adding the 500GB disks was because he was out of space, and the reason we didn't just add another vdev to the existing pool is because his case only has room for 13 disks. Finally, the 320 gig disks have started returning checksum errors, so he wanted to get them out of the pool. The system as a whole has been very reliable, but due to some ZFS limitations (no vdev removal, no stripe width changing) a new pool has been needed at each stage. My experiences with ZFS at home have been very positive, but I also use it at work. I'm concerned about the speed of "zfs send" and with being able to remove vdevs before I will recommend it unilaterally for work purposes, but despite these issues I have a couple pools in production: one serving mail, one serving user home directories, and one serving data for research groups. We have had no problems with these pools, but I keep an eye on the backup logs for them. I hope that eventually such careful watching will not be necessary. Will _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
