The "limitations" section of the Wikipedia article on ZFS currently
includes the statement:
"You cannot mix vdev types in a zpool. For example, if you had a
striped ZFS pool consisting of disks on a SAN, you cannot add the local-disks as
a mirrored vdev."
As I understand it, this is simply wrong. You can add any kind of vdev to any
zpool. Right?
As I understand it, mixing vdev types is in general a bad idea. The reliability
of a zpool is dictated by its least reliable vdev and the performance of a zpool
tends to be limited by its lowest-performing vdevs. So mixing vdev types tends
to give you the worst of all possible worlds.
But this is merely a logical consequence of mixing storage types, not anything
to do with ZFS. Precisely analogous considerations would apply when setting up
RAID-10, for example.
Do I have that right?
Cheers,
Al.
--
This message posted from opensolaris.org
you can''t without forcing...and even if you do, it''s not a good idea. if you do your pool will have the lowest redundancy/speed of the worst one... sooo if you add a single drive to a raidz vdev, your entire pool loses it''s redundancy, if you add a single drive to a mirror, likewise if you add a raidz group to a group of 3 mirrors, the entire pool slows down to the speed of the raidz..... while you technically CAN do it, it''s a horrible idea. On Sun, Sep 6, 2009 at 2:19 PM, Al Lang <al451 at pobox.com> wrote:> The "limitations" section of the Wikipedia article on ZFS currently > includes the statement: > > "You cannot mix vdev types in a zpool. For example, if you had a striped > ZFS pool consisting of disks on a SAN, you cannot add the local-disks as a > mirrored vdev." > > As I understand it, this is simply wrong. You can add any kind of vdev to > any zpool. Right? > > As I understand it, mixing vdev types is in general a bad idea. The > reliability of a zpool is dictated by its least reliable vdev and the > performance of a zpool tends to be limited by its lowest-performing vdevs. > So mixing vdev types tends to give you the worst of all possible worlds. > > But this is merely a logical consequence of mixing storage types, not > anything to do with ZFS. Precisely analogous considerations would apply when > setting up RAID-10, for example. > > Do I have that right? > > Cheers, > Al. > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090906/2db31f47/attachment.html>
> if you add a raidz group to a group of 3 mirrors, the entire pool slows > down to the speed of the raidz.....That''s not true. Blocks are being randomly spread across all vdevs. Unless all requests keep pulling blocks from the RAID-Z, the speed is a mean of the performance of all vdevs. -mg
yes, but it stripes across the vdevs, and when it needs to read data back, it will absolutely be limited. On Sun, Sep 6, 2009 at 3:14 PM, Mario Goebbels <me at tomservo.cc> wrote:> if you add a raidz group to a group of 3 mirrors, the entire pool slows >> down to the speed of the raidz..... >> > > That''s not true. Blocks are being randomly spread across all vdevs. Unless > all requests keep pulling blocks from the RAID-Z, the speed is a mean of the > performance of all vdevs. > > -mg >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090906/5bcbf96d/attachment.html>
On Sep 6, 2009, at 3:32 PM, Thomas Burgess <wonslung at gmail.com> wrote:> > yes, but it stripes across the vdevs, and when it needs to read data > back, it will absolutely be limited.During reads the raidz will be the fastest vdev, during writes it should have about the same write performance as any one mirror vdev depending on how many disks it''s comprised of. Random io on raidz should perform equal to any one mirror vdev except be a little faster on reads. -Ross
On Sep 6, 2009, at 11:19 AM, Al Lang wrote:> The "limitations" section of the Wikipedia article on ZFS currently > includes the statement: > > "You cannot mix vdev types in a zpool. For example, if you had a > striped ZFS pool consisting of disks on a SAN, you cannot add the > local-disks as a mirrored vdev." > > As I understand it, this is simply wrong. You can add any kind of > vdev to any zpool. Right?This is so confusing that it makes absolutely no sense. I suspect the author intended to explain the limitation as described in the zpool(1m) man page: Virtual devices cannot be nested, so a mirror or raidz vir- tual device can only contain files or disks. Mirrors of mir- rors (or other combinations) are not allowed. so I edited it :-)> As I understand it, mixing vdev types is in general a bad idea. The > reliability of a zpool is dictated by its least reliable vdev and > the performance of a zpool tends to be limited by its lowest- > performing vdevs. So mixing vdev types tends to give you the worst > of all possible worlds.It is really a data management issue, not a functionality issue. We really do try to help people not hurt themselves with complexity ;-) -- richard> But this is merely a logical consequence of mixing storage types, > not anything to do with ZFS. Precisely analogous considerations > would apply when setting up RAID-10, for example. > > Do I have that right? > > Cheers, > Al. > -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
On Sun, 6 Sep 2009, Thomas Burgess wrote:> > if you add a raidz group to a group of 3 mirrors, the entire pool slows down > to the speed of the raidz..... > > while you technically CAN do it, it''s a horrible idea.I don''t think it is necessarily as horrid as you say. Zfs does distribute writes to faster vdevs under heavy write load. There can be vdevs of somewhat different type and size (e.g. raidz and raidz2) which behave similarly enough to not cause much imbalance in the pool. Saying that mixing vdev types is horrid is similar in nature to saying that not using the same type and model of drive throughout the pool is horrid. If you added a raidz vdev to a pool already using raidz vdevs, but the new drives are much faster than the existing drives, then the same sort of imbalance exists. boB -- Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
i don''t think it''s the same at all. I think it''s about the same as filling a radiator in a car with oatmeal to make it stop leaking. On Sun, Sep 6, 2009 at 6:26 PM, Bob Friesenhahn < bfriesen at simple.dallas.tx.us> wrote:> On Sun, 6 Sep 2009, Thomas Burgess wrote: > >> >> if you add a raidz group to a group of 3 mirrors, the entire pool slows >> down >> to the speed of the raidz..... >> >> while you technically CAN do it, it''s a horrible idea. >> > > I don''t think it is necessarily as horrid as you say. Zfs does distribute > writes to faster vdevs under heavy write load. There can be vdevs of > somewhat different type and size (e.g. raidz and raidz2) which behave > similarly enough to not cause much imbalance in the pool. > > Saying that mixing vdev types is horrid is similar in nature to saying that > not using the same type and model of drive throughout the pool is horrid. > If you added a raidz vdev to a pool already using raidz vdevs, but the new > drives are much faster than the existing drives, then the same sort of > imbalance exists. > > boB > -- > Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090906/9b32d675/attachment.html>