Brian,
CR 4852783 was updated again this week so you might add yourself or
your customer to continue to be updated.
In the meantime, a reminder is that a mirrored ZFS configuration
is flexible in that devices can be detached (as long as the redundancy
is not compromised) or replaced as long as the replacement disk is an
equivalent size or larger. So, you can move storage around if you need
to in a mirrored ZFS config and until 4852783 integrates.
cs
On 08/05/09 15:58, Brian Kolaci wrote:
I'm chiming in late, but have a mission critical need of this as well
and posted as a non-member before. My customer was wondering when this
would make it into Solaris 10. Their complete adoption depends on it.
I have a customer that is trying to move from VxVM/VxFS to ZFS, however
they have this same need. They want to save money and move to ZFS.
They are charged by a separate group for their SAN storage needs. The
business group storage needs grow and shrink over time, as it has done
for years. They've been on E25K's and other high power boxes with
VxVM/VxFS as their encapsulated root disk for over a decade. They
are/were a big Veritas shop. They rarely ever use UFS, especially in
production.
They absolutely require the shrink functionality to completely move off
VxVM/VxFS to ZFS, and we're talking $$millions. I think your statements
below are from a technology standpoint, not a business standpoint. You
say its poor planning, which is way off the mark. Business needs change
daily. It takes several weeks to provision SAN with all the approvals,
etc. and it it takes massive planning. That goes for increasing as well
as decreasing their storage needs.
Richard Elling wrote:
On Aug 5, 2009, at 1:06 PM, Martin wrote:
richard wrote:
Preface: yes, shrink will be cool. But we've been
running highly
available,
mission critical datacenters for more than 50 years
without shrink being
widely available.
I would debate that. I remember batch windows and downtime delaying
one's career movement. Today we are 24x7 where an outage can kill an
entire business
Agree.
Do it exactly the same way you do it for UFS. You've
been using UFS
for years without shrink, right? Surely you have
procedures in
place :-)
While I haven't taken a formal survey, everywhere I look I see JFS on
AIX and VxFS on Solaris. I haven't been in a production UFS shop
this decade.
Then why are you talking on Solaris forum? All versions of
Solaris prior to Solaris 10 10/08 only support UFS for boot.
Backout plans are not always simple reversals. A
well managed site will
have procedures for rolling upgrades.
I agree with everything you wrote. Today other technologies allow
live changes to the pool, so companies use those technologies instead
of ZFS.
... and can continue to do so. If you are looking to replace a
for-fee product with for-free, then you need to consider all
ramifications. For example, a shrink causes previously written
data to be re-written, thus exposing the system to additional
failure modes. OTOH, a model of place once and never disrupt
can provide a more reliable service. You will see the latter
"pattern" repeated often for high assurance systems.
There is more than one way to skin a cat.
Which entirely misses the point.
Many cases where people needed to shrink were due to the
inability to plan for future growth. This is compounded by the
rather simplistic interface between a logical volume and traditional
file system. ZFS allows you to dynamically grow the pool, so you
can implement a process of only adding storage as needs dictate.
Bottom line: shrink will be cool, but it is not the perfect solution for
managing changing data needs in a mission critical environment.
-- richard
_______________________________________________
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
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
