Re: [zfs-discuss] shrinking a zpool - roadmap

2010-02-23 Thread Robert Milkowski
On 23/02/2010 02:52, Richard Elling wrote: On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote: I talked with our enterprise systems people recently. I don't believe they'd consider ZFS until it's more flexible. Shrink is a big one, as is removing an slog. We also need to be able to expand

Re: [zfs-discuss] shrinking a zpool - roadmap

2010-02-23 Thread Richard Elling
On Feb 23, 2010, at 5:10 AM, Robert Milkowski wrote: On 23/02/2010 02:52, Richard Elling wrote: On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote: I talked with our enterprise systems people recently. I don't believe they'd consider ZFS until it's more flexible. Shrink is a big one, as

Re: [zfs-discuss] shrinking a zpool - roadmap

2010-02-23 Thread Robert Milkowski
On 23/02/2010 17:20, Richard Elling wrote: On Feb 23, 2010, at 5:10 AM, Robert Milkowski wrote: On 23/02/2010 02:52, Richard Elling wrote: On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote: I talked with our enterprise systems people recently. I don't believe they'd

Re: [zfs-discuss] shrinking a zpool - roadmap

2010-02-22 Thread Charles Hedrick
I talked with our enterprise systems people recently. I don't believe they'd consider ZFS until it's more flexible. Shrink is a big one, as is removing an slog. We also need to be able to expand a raidz, possibly by striping it with a second one and then rebalancing the sizes. -- This message

Re: [zfs-discuss] shrinking a zpool - roadmap

2010-02-22 Thread Richard Elling
On Feb 22, 2010, at 6:42 PM, Charles Hedrick wrote: I talked with our enterprise systems people recently. I don't believe they'd consider ZFS until it's more flexible. Shrink is a big one, as is removing an slog. We also need to be able to expand a raidz, possibly by striping it with a

Re: [zfs-discuss] shrinking a zpool - roadmap

2010-02-21 Thread Ralf Gans
Hello out there, is there any progress in shrinking zpools? i.e. removing vdevs from a pool? Cheers, Ralf -- This message posted from opensolaris.org ___ zfs-discuss mailing list zfs-discuss@opensolaris.org

Re: [zfs-discuss] shrinking a zpool - roadmap

2009-07-30 Thread Ralf Gans
Hello there, I'm working for a bigger customer in germany. The customer ist some thousend TB big. The information that the zpool shrink feature will not be implemented soon is no problem, we just keep using Veritas Storage Foundation. Shirinking a pool is not the only problem with ZFS, try

Re: [zfs-discuss] shrinking a zpool - roadmap

2009-07-30 Thread Kyle McDonald
Ralf Gans wrote: Jumpstart puts a loopback mount into the vfstab, and the next boot fails. The Solaris will do the mountall before ZFS starts, so the filesystem service fails and you have not even an sshd to login over the network. This is why I don't use the mountpoint settings in ZFS. I

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-21 Thread Mertol Ozyoney
] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Will Murnane Sent: Thursday, August 21, 2008 1:57 AM To: Bob Friesenhahn Cc: zfs-discuss@opensolaris.org Subject: Re: [zfs-discuss] shrinking a zpool - roadmap On Wed, Aug 20, 2008 at 18:40, Bob Friesenhahn [EMAIL

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-21 Thread Chris Siebenmann
| The errant command which accidentally adds a vdev could just as easily | be a command which scrambles up or erases all of the data. The difference between a mistaken command that accidentally adds a vdev and the other ways to loose your data with ZFS is that the 'add a vdev' accident is only

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread John
WOW! This is quite a departure from what we've been told for the past 2 years... In fact if your comments are true that we'll never be able to shrink a ZFS pool, i will be, for lack of a better word, PISSED. Like others not being able to shrink is a feature that truly prevents us from

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Mario Goebbels
WOW! This is quite a departure from what we've been told for the past 2 years... This must be misinformation. The reason there's no project (yet) is very likely because pool shrinking depends strictly on the availability of bp_rewrite functionality, which is still in development. The last

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Kyle McDonald
Mario Goebbels wrote: WOW! This is quite a departure from what we've been told for the past 2 years... This must be misinformation. The reason there's no project (yet) is very likely because pool shrinking depends strictly on the availability of bp_rewrite functionality, which is

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread John
Our enterprise is about 300TB.. maybe a bit more... You are correct that most of the time we grow and not shrink... however, we are fairly dynamic and occasionally do shrink. DBA's have been known to be off on their space requirements/requests. There is also the human error factor. If someone

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Miles Nordin
j == John [EMAIL PROTECTED] writes: j There is also the human error factor. If someone accidentally j grows a zpool or worse, accidentally adds an unredundant vdev to a redundant pool. Once you press return, all you can do is scramble to find mirrors for it. vdev removal is also

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Ian Collins
John wrote: Our enterprise is about 300TB.. maybe a bit more... You are correct that most of the time we grow and not shrink... however, we are fairly dynamic and occasionally do shrink. DBA's have been known to be off on their space requirements/requests. Isn't that one of the

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Bob Friesenhahn
On Wed, 20 Aug 2008, Miles Nordin wrote: j == John [EMAIL PROTECTED] writes: j There is also the human error factor. If someone accidentally j grows a zpool or worse, accidentally adds an unredundant vdev to a redundant pool. Once you press return, all you can do is scramble to

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Will Murnane
On Wed, Aug 20, 2008 at 18:40, Bob Friesenhahn [EMAIL PROTECTED] wrote: The errant command which accidentally adds a vdev could just as easily be a command which scrambles up or erases all of the data. True enough---but if there's a way to undo accidentally adding a vdev, there's one source of

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread paul
Kyle wrote: ... If I recall, the low priority was based on the percieved low demand for the feature in enterprise organizations. As I understood it shrinking a pool is percieved as being a feature most desired by home/hobby/development users, and that enterprises mainly only grow thier

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Kyle McDonald
John wrote: Our enterprise is about 300TB.. maybe a bit more... You are correct that most of the time we grow and not shrink... however, we are fairly dynamic and occasionally do shrink. DBA's have been known to be off on their space requirements/requests. For the record I agree with

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-20 Thread Kyle McDonald
Zlotnick Fred wrote: On Aug 20, 2008, at 6:39 PM, Kyle McDonald wrote: My suggestion still remains though. Log your enterprises wish for this feature through as many channels as you have into Sun. This list, Sales, Support, every way you can think of. Get it documented, so that when they go

Re: [zfs-discuss] shrinking a zpool - roadmap

2008-08-18 Thread Tim
Long story short, There isn't a project, there are no plans to start a project, and don't expect to see it in Solaris10 in this lifetime without some serious pushback from large Sun customers. Even then, it's unlikely to happen anytime soon due to the technical complications of doing so