Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-10-05 Thread Brandon High
Replying to a few folks in a digest format, because I'm lazy and don't have that much to say. On Wed, Sep 30, 2009 at 5:53 PM, Tim Cook wrote: > What are you hoping to accomplish?  You're still going to need a drives > worth of free space, and if you're so performance strapped that one drive > ma

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-10-01 Thread Bob Friesenhahn
On Wed, 30 Sep 2009, Richard Elling wrote: a big impact. With 2+ TB drives, the resilver time is becoming dominant. As disks becoming larger and not faster, there will be a day when the logistical response time will become insignificant. In other words, you won't need a spare to improve logistica

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-10-01 Thread paul
> Yes, this is something that should be possible once we have bp rewrite > (the > ability to move blocks around). [snip] > FYI, I am currently working on bprewrite for device removal. > > --matt That's very cool. I don't code (much/enough to help), but I'd like to help if I can. If nothing else,

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-09-30 Thread Richard Elling
On Sep 30, 2009, at 6:03 PM, Matthew Ahrens wrote: Erik Trimble wrote: From a global perspective, multi-disk parity (e.g. raidz2 or raidz3) is the way to go instead of hot spares. Hot spares are useful for adding protection to a number of vdevs, not a single vdev. Even when using raidz2 or

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-09-30 Thread Matthew Ahrens
Erik Trimble wrote: From a global perspective, multi-disk parity (e.g. raidz2 or raidz3) is the way to go instead of hot spares. Hot spares are useful for adding protection to a number of vdevs, not a single vdev. Even when using raidz2 or 3, it is useful to have hot spares so that reconstru

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-09-30 Thread Matthew Ahrens
Brandon, Yes, this is something that should be possible once we have bp rewrite (the ability to move blocks around). One minor downside to "hot space" would be that it couldn't be shared among multiple pools the way that hot spares can. Also depending on the pool configuration, hot space may

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-09-30 Thread Erik Trimble
Brandon High wrote: I might have this mentioned already on the list and can't find it now, or I might have misread something and come up with this ... Right now, using hot spares is a typical method to increase storage pool resiliency, since it minimizes the time that an array is degraded. The d

Re: [zfs-discuss] "Hot Space" vs. hot spares

2009-09-30 Thread Tim Cook
On Wed, Sep 30, 2009 at 7:06 PM, Brandon High wrote: > I might have this mentioned already on the list and can't find it now, > or I might have misread something and come up with this ... > > Right now, using hot spares is a typical method to increase storage > pool resiliency, since it minimizes

[zfs-discuss] "Hot Space" vs. hot spares

2009-09-30 Thread Brandon High
I might have this mentioned already on the list and can't find it now, or I might have misread something and come up with this ... Right now, using hot spares is a typical method to increase storage pool resiliency, since it minimizes the time that an array is degraded. The downside is that drives