On Aug 20, 2008, at 6:39 PM, Kyle McDonald wrote:

> 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 you and I'm wating for this feature  
> also. I
> was only citing my recolection of the explanatin given in the past.
>
> To add more from my memory, I think the 'Enterprise grows not shrinks'
> idea is coming from the idea that in ZFS you should be creating fewer
> data pools from a few different specific sized LUNs, and using ZFS to
> allocate filesystems and zVOL's from the pool, instead of customizing
> LUN sizes to create more pools each for different purposes. If true,  
> (if
> you can make all your LUNs one size, and make a few [prefferably one I
> think] data zPool per server host.) then the need to reduce pool  
> size is
> diminished.
>
> That's not realistic in the home/hobby/developer market, and I'm not
> convinced that's realistic in the enterprise either.
>> There is also the human error factor.  If someone accidentally  
>> grows a zpool there is no easy way to recover that space without  
>> down time.  Some of my LUNs are in the 1TB range and if that gets  
>> added to the wrong zpool that space is basically stuck there until  
>> i can get a maintenance window. And then I'm not that's even  
>> possible since my windows are only 3 hours... for example what if I  
>> add a LUN to 20TB zpool.  What would I do to remove the LUN?  I  
>> think I would have to create a new 20TB pool and move the data from  
>> the original to the new zpool... so that would assume I have a free  
>> 20TB and the down time....
>>
>>
> I agree here also, even with a single zpool per server. Consider a
> policy where when the pool grows you always add a RAIDz2 of 10 200GB
> LUNs. So your single data pool is currently 3 of these RAIDz2 vdevs,  
> and
> an admin goes to add 10 more, but forgets the 'raidz2, so you end up
> with 3 RAIDz2, and 10 single LUN non redundant vdevs. How do you fix  
> that?
>
> 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 to set priorities on RFE's there'll be more data on this one.

Knock yourself out, but it's really unnecessary.  As has been amply
documented, on this thread and others, this is already a very high
priority for us.  It just happens to be rather difficult to do it right.
We're working on it.  We've heard the message (years ago, actually, just
about as soon as we shipped ZFS in S10 6/06.)  Your further  
encouragement
is appreciated, but it's unlikely to speed up what already is deemed
a high priority.

My 2 cents,
Fred
>
>
>  -Kyle
>>
>> This message posted from opensolaris.org
>> _______________________________________________
>> zfs-discuss mailing list
>> zfs-discuss@opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
>>
>
> _______________________________________________
> zfs-discuss mailing list
> zfs-discuss@opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

--
Fred Zlotnick
Senior Director, Open Filesystem and Sharing Technologies
Sun Microsystems, Inc.
[EMAIL PROTECTED]
x81142/+1 650 352 9298








_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to