Request for opinions - gvinum or ccd?

[krad]

Zfs has been designed for highly scalable redundant disk pools therefore
using it on a single drive kind of goes against it ethos. Remember a lot of
the blurb in the man page was written by sun and therefore is written with
corporates in mind, therefore the cost with of the data vs an extra drive
being so large why wouldn't you make it redundant.

Having said that sata drives are cheap these days so you would have to be on
the tightest of budgets not to do a mirror.

Having said all this we quite often us zfs on a single drive, well sort of.
The sun clusters have external storage for the shared file systems. These
are usually a bunch of drives, raid 5, 10 or whatever. Then export a single
lun, which is presented to the various nodes. There is a zpool created on
this LUN. So to all intents and purposes zfs thinks its on a single drive
(the redundancy provided by the external array). This is common practice and
we see no issues with it.

-----Original Message-----
From: owner-freebsd-hackers at freebsd.org
[mailto:owner-freebsd-hackers at freebsd.org] On Behalf Of
xorquewasp at googlemail.com
Sent: 01 June 2009 01:00
To: freebsd-hackers at freebsd.org
Subject: Re: Request for opinions - gvinum or ccd?

There is one last thing I'd like clarified. From the zpool
manpage:

  In order  to take advantage of these features, a pool must make use of
  some form of redundancy, using either mirrored or raidz  groups.  While
  ZFS  supports running in a non-redundant configuration, where each root
  vdev is simply a disk or file, this is strongly discouraged.  A  single
  case of bit corruption can render some or all of your data unavailable.

Is this supposed to mean:

  "ZFS is more fragile than most. If you don't use redundancy, one
   case of bit corruption will destroy the filesystem"

Or:

  "Hard disks explode often. Use redundancy."

_______________________________________________
freebsd-hackers at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"