subject:"\[zfs\-discuss\] Shrinking a zpool\?"

Bob wrote:

> Perhaps the problem is one of educating the customer
> so that they can 
> ammend their accounting practices.  Different
> business groups can 
> share the same pool if necessary.

Bob, while I don't mean to pick on you, that statement captures a major 
thinking flaw in IT when it comes to sales.

Yes, Brian should do everything possible to shape the customer's expectations; 
that's his job.

At the same time, let's face it.  If the customer thinks he needs X (whether or 
not he really does) and Brian can't get him to move away from it, Brian is 
sunk.  Here Brian sits with a potential multi-million dollar sale which is 
stuck on a missing feature, and probably other obstacles.  The truth is that 
the other obstacles are irrelevant as long as the customer can't get past 
feature X, valid or not.

So millions of dollars to Sun hang in the balance and these discussions revolve 
around whether or not the customer is planning optimally.  Imagine how much 
rapport Brian will gain when he tells this guy, "You know, if you guys just 
planned better, you wouldn't need feature X."  Brian would probably not get his 
phone calls returned after that.

You can rest assured that when the customer meets with IBM the next day, the 
IBM rep won't let the customer get away from feature X that JFS has.  The 
conversation might go like this.

Customer: You know, we are really looking at Sun and ZFS.

IBM: Of course you are, because that's a wise thing to do.  ZFS has a lot of 
exciting potential.

Customer: Huh?

IBM: ZFS has a solid base and Sun is adding features which will make it quite 
effective for your applications.

Customer: So you like ZFS?

IBM: Absolutely.  At some point it will have the features you need.  You 
mentioned you use feature X to provide the flexibility you have to continue to 
outperform your competition during this recession.  I understand Sun is working 
hard to integrate that feature, even as we speak.

Customer: Maybe we don't need feature X.

IBM: You would know more than I.  When did you last use feature X?

Customer: We used X last quarter when we scrambled to add FOO to our product 
mix so that we could beat our competition to market.

IBM: How would it have been different if feature X was unavailable?

Customer (mind racing): We would have found a way.

IBM: Of course, as innovative as your company is, you would have found a way.  
How much of a delay?

Customer (thinking through the scenarios): I don't know.

IBM: It wouldn't have impacted the rollout, would it?

Customer: I don't know.

IBM: Even if it did delay things, the delay wouldn't blow back on you, right?

Customer (sweating): I don't think so.

Imagine the land mine Brian now has to overcome when he tries to convince the 
customer that they don't need feature X, and even if they do, Sun will have it 
"real soon now."

Does anyone really think that Oracle made their money lecturing customers on 
how Table Partitions are stupid and if the customer would have planned their 
schema better, they wouldn't need them anyway?  Of course not.  People wanted 
partitions (valid or not) and Oracle delivered.

Marty
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Jordan Schwartz

>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.

Agreed, and shrink IS cool, I used it to migrate VxVM volumes from direct
attached storage to slightly smaller SAN  LUNS on a solaris sparc box.  It
sure is nice to add the new storage to the volume and mirror as opposed to
copying to a new filesystem.

It will be cool when SSDs are released for my fully loaded x4540s, if I can
migrate enough users off and shrink the pool perhaps I can drop a couple of
SATA disks and then add the SSDs, all on the fly.

Perhaps Steve Martin said it best, "Let's get real small!".

Thanks,

Jordan


On Wed, Aug 5, 2009 at 12:47 PM, Richard Elling 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.
>
> On Aug 5, 2009, at 9:17 AM, Martin wrote:
>
>> You are the 2nd customer I've ever heard of to use shrink.
>>>
>>
>> This attitude seems to be a common theme in ZFS discussions: "No
>> enterprise uses shrink, only grow."
>>
>> Maybe.  The enterprise I work for requires that every change be reversible
>> and repeatable.  Every change requires a backout plan and that plan better
>> be fast and nondisruptive.
>>
>
> 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 :-)
>
>  Who are these enterprise admins who can honestly state that they have no
>> requirement to reverse operations?
>>
>
> Backout plans are not always simple reversals.  A well managed site will
> have procedures for rolling upgrades.
>
>  Who runs a 24x7 storage system and will look you in the eye and state,
>> "The storage decisions (parity count, number of devices in a stripe, etc.)
>> that I make today will be valid until the end of time and will NEVER need
>> nondisruptive adjustment.  Every storage decision I made in 1993 when we
>> first installed RAID is still correct and has needed no changes despite
>> changes in our business models."
>>
>> My experience is that this attitude about enterprise storage borders on
>> insane.
>>
>> Something does not compute.
>>
>
> There is more than one way to skin a cat.
>  -- 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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Matthew Ahrens


Brian Kolaci wrote:
So Sun would see increased hardware revenue stream if they would just 
listen to the customer...  Without [pool shrink], they look for alternative 
hardware/software vendors.


Just to be clear, Sun and the ZFS team are listening to customers on this 
issue.  Pool shrink has been one of our top priorities for some time now.


It is unfortunately a very difficult problem, and will take some time to 
solve even with the application of all possible resources (including the 
majority of my time).  We are updating CR 4852783 at least once a month with 
progress reports.


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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Bob Friesenhahn


On Wed, 5 Aug 2009, Richard Elling wrote:


Thanks Cindy,
This is another way to skin the cat. It works for simple volumes, too.
But there are some restrictions, which could impact the operation when a
large change in vdev size is needed. Is this planned to be backported
to Solaris 10?

CR 6844090 has more details.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6844090


A potential partial solution is to have a pool creation option where 
the tail device labels are set to a point much smaller than the device 
size rather than being written to the end of the device.  As zfs 
requires more space, the tail device labels are moved to add 
sufficient free space that storage blocks can again be efficiently 
allocated.  Since no zfs data is written beyond the tail device 
labels, the storage LUN could be truncated down to the point where the 
tail device labels are still left intact.  This seems like minimal 
impact to ZFS and no user data would need to be migrated.


If the user's usage model tends to periodically fill the whole LUN 
rather than to gradually grow, then this approach won't work.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Shrinking a zpool?


cindy.swearin...@sun.com wrote:

Brian,

CR 4852783 was updated again this week so you might add yourself or
your customer to continue to be updated.


Will do.  I thought I was on it, but didn't see any updates...



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.


Yes, we're trying to push that through now (make a ZFS root).  But the case I 
was more concerned about was the back-end storage for LDom guests and 
zonepaths.  All the SAN storage coming in is already RAID on EMC or Hitachi, 
and they just move the storage around through the SAN group.

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

Re: [zfs-discuss] Shrinking a zpool?


On Aug 5, 2009, at 4:06 PM, cindy.swearin...@sun.com wrote:


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.


Thanks Cindy,
This is another way to skin the cat. It works for simple volumes, too.
But there are some restrictions, which could impact the operation when a
large change in vdev size is needed. Is this planned to be backported
to Solaris 10?

CR 6844090 has more details.
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6844090
 -- richard

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

Re: [zfs-discuss] Shrinking a zpool?


Bob Friesenhahn wrote:

On Wed, 5 Aug 2009, Brian Kolaci wrote:


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.


ZFS is a storage pool and not strictly a filesystem.  One may create 
filesystems or logical volumes out of this storage pool.  The logical 
volumes can be exported via iSCSI or FC (COMSTAR).  Filesystems may be 
exported via NFS or CIFS.  ZFS filesystems support quotas for both 
maximum consumption, and minimum space reservation.


Perhaps the problem is one of educating the customer so that they can 
ammend their accounting practices.  Different business groups can share 
the same pool if necessary.


They understand the technology very well.  Yes, ZFS is very flexible with many 
features, and most are not needed in an enterprise environment where they have 
high-end SAN storage that is shared between Sun, IBM, linux, VMWare ESX and 
Windows.  Local disk is only for the OS image.  There is no need to have an 
M9000 be a file server.  They have NAS for that.  They use SAN across the 
enterprise and it gives them the ability to fail-over to servers in other data 
centers very quickly.

Different business groups cannot share the same pool for many reasons.  Each 
business group pays for their own storage.  There are legal issues as well, and 
in fact cannot have different divisions on the same frame let alone shared 
storage.  But they're in a major virtualization push to the point that nobody 
will be allowed to be on their own physical box.  So the big push is to move to 
VMware, and we're trying to salvage as much as we can to move them to 
containers and LDoms.  That being the case, I've recommended that each virtual 
machine on either a container or LDom should be allocated their own zpool, and 
the zonepath or LDom disk image be on their own zpool.  This way when (not if) 
they need to migrate to another system, they have one pool to move over.  They 
use fixed sized LUNs, so the granularity is a 33GB LUN, which can be migrated.  
This is also the case for their clusters as well as SRDF to their COB machines.



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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Cindy . Swearingen


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

Re: [zfs-discuss] Shrinking a zpool?

Richard Elling wrote:

On Aug 5, 2009, at 2:58 PM, 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.

If you look at it from Sun's business perspective, ZFS is $$ free, so
Sun gains

no $$ millions by replacing VxFS. Indeed, if the customer purchases VxFS
from Sun, it makes little sense for Sun to eliminate a revenue source.
OTOH,

I'm sure if they are willing to give Sun $$ millions, it can help raise the
priority of CR 4852783.
http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

They're probably on the list already, but I'll check to make sure.
What I meant by the $$ millions is that currently all Sun hardware purchases are on hold. Deploying on
Solaris currently means not just the hardware, but the support, required certified third-party software
such as EMC powerpath, Veritas VxVM & VxFS, BMC monitoring, and more... Yes, I'm still working the
MPxIO to replace powerpath, but there's issues there too. They will not use UFS. Right now ZFS is OK
for limited deployment and no production use. Their case on ZFS is that its good for dealing with
JBOD, but it not yet "enterprise ready" for SAN use. Shrinking a volume is just one of a
list of requirements to move toward "enterprise ready", however many issues have been fixed.

So Sun would see increased hardware revenue stream if they would just listen to
the customer... Without it, they look for alternative hardware/software
vendors. While this is stalled, there have been several hundred systems that
have been flipped to competitors (and this is still going on). So lack of this
feature will cause $$ millions to be lost...

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.

I think you've identified the real business problem. A shrink feature in
ZFS will
do nothing to fix this. A business who's needs change faster than their
ability
to react has (as we say in business school) an unsustainable business
model.

-- richard

Yes, hence a federal bail-out. However a shrink feature will help them to be
able to spend more with Sun.

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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Bob Friesenhahn


On Wed, 5 Aug 2009, Brian Kolaci wrote:


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.


ZFS is a storage pool and not strictly a filesystem.  One may create 
filesystems or logical volumes out of this storage pool.  The logical 
volumes can be exported via iSCSI or FC (COMSTAR).  Filesystems may be 
exported via NFS or CIFS.  ZFS filesystems support quotas for both 
maximum consumption, and minimum space reservation.


Perhaps the problem is one of educating the customer so that they can 
ammend their accounting practices.  Different business groups can 
share the same pool if necessary.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Shrinking a zpool?


On Aug 5, 2009, at 2:58 PM, 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.


If you look at it from Sun's business perspective, ZFS is $$ free, so  
Sun gains

no $$ millions by replacing VxFS. Indeed, if the customer purchases VxFS
from Sun, it makes little sense for Sun to eliminate a revenue source.  
OTOH,
I'm sure if they are willing to give Sun $$ millions, it can help  
raise the

priority of CR 4852783.
http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

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.


I think you've identified the real business problem. A shrink feature  
in ZFS will
do nothing to fix this. A business who's needs change faster than  
their ability
to react has (as we say in business school) an unsustainable business  
model.

 -- richard

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

Re: [zfs-discuss] Shrinking a zpool?


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

Re: [zfs-discuss] Shrinking a zpool?


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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Jacob Ritorto

Interesting, this is the same procedure I invented (with the exception 
that the zfs send came from the net) and used to hack OpenSolaris 
2009.06 onto my home SunBlade 2000 since it couldn't do AI due to low 
OBP rev..


I'll have to rework it this way, then, which will unfortunately cause 
downtime for a multitude of dependent services, affect the entire 
universe here and make my department look inept.  As much as it stings, 
I accept that this is the price I pay for adopting a new technology. 
Acknowledge and move on.  Quite simply, if this happens too often, we 
know we've made the wrong decision on vendor/platform.


Anyway, looking forward to shrink.  Thanks for the tips.


Kyle McDonald wrote:

Kyle McDonald wrote:

Jacob Ritorto wrote:
Is this implemented in OpenSolaris 2008.11?  I'm moving move my 
filer's rpool to an ssd mirror to free up bigdisk slots currently 
used by the os and need to shrink rpool from 40GB to 15GB. (only 
using 2.7GB for the install).


  
Your best bet would be to install the new ssd drives, create a new 
pool, snapshot the exisitng pool and use ZFS send/recv to migrate the 
data to the new pool. There are docs around about how install grub and 
the boot blocks on the new devices also. After that remove (export!, 
don't destroy yet!)

the old drives, and reboot to see how it works.

If you have no problems, (and I don't think there's anything technical 
that would keep this from working,) then you're good. Otherwise put 
the old pool back in. :)


This thread dicusses basically this same thing - he had a problem along 
the way, but Cindy answered it.



Hi Nawir,

I haven't tested these steps myself, but the error message
means that you need to set this property:

# zpool set bootfs=rpool/ROOT/BE-name rpool

Cindy

On 08/05/09 03:14, nawir wrote:
Hi,

I have sol10u7 OS with 73GB HD in c1t0d0.
I want to clone it to 36GB HD

These steps below is what come in my mind
STEPS TAKEN
# zpool create -f altrpool c1t1d0s0
# zpool set listsnapshots=on rpool
# SNAPNAME=`date +%Y%m%d`
# zfs snapshot -r rpool/r...@$snapname
# zfs list -t snapshot
# zfs send -R rp...@$snapname | zfs recv -vFd altrpool
# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk 
/dev/rdsk/c1t1d0s0

for x86 do
# installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t1d0s0
# zpool export altrpool
# init 5
remove source disk (c1t0d0s0) and move target disk (c1t1d0s0) to slot0
-insert solaris10 dvd
ok boot cdrom -s
# zpool import altrpool rpool
# init 0
ok boot disk1

ERROR:
Rebooting with command: boot disk1
Boot device: /p...@1c,60/s...@2/d...@1,0  File and args:
no pool_props
Evaluating:
The file just loaded does not appear to be executable.
ok

QUESTIONS:
1. what's wrong what my steps
2. any better idea

thanks 

-Kyle




 -Kyle


thx
jake
  


___
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

Re: [zfs-discuss] Shrinking a zpool?

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.

> 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.

> 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.

> There is more than one way to skin a cat.

Which entirely misses the point.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Kyle McDonald


Kyle McDonald wrote:

Jacob Ritorto wrote:
Is this implemented in OpenSolaris 2008.11?  I'm moving move my 
filer's rpool to an ssd mirror to free up bigdisk slots currently 
used by the os and need to shrink rpool from 40GB to 15GB. (only 
using 2.7GB for the install).


  
Your best bet would be to install the new ssd drives, create a new 
pool, snapshot the exisitng pool and use ZFS send/recv to migrate the 
data to the new pool. There are docs around about how install grub and 
the boot blocks on the new devices also. After that remove (export!, 
don't destroy yet!)

the old drives, and reboot to see how it works.

If you have no problems, (and I don't think there's anything technical 
that would keep this from working,) then you're good. Otherwise put 
the old pool back in. :)


This thread dicusses basically this same thing - he had a problem along 
the way, but Cindy answered it.



Hi Nawir,

I haven't tested these steps myself, but the error message
means that you need to set this property:

# zpool set bootfs=rpool/ROOT/BE-name rpool

Cindy

On 08/05/09 03:14, nawir wrote:
Hi,

I have sol10u7 OS with 73GB HD in c1t0d0.
I want to clone it to 36GB HD

These steps below is what come in my mind
STEPS TAKEN
# zpool create -f altrpool c1t1d0s0
# zpool set listsnapshots=on rpool
# SNAPNAME=`date +%Y%m%d`
# zfs snapshot -r rpool/r...@$snapname
# zfs list -t snapshot
# zfs send -R rp...@$snapname | zfs recv -vFd altrpool
# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk 
/dev/rdsk/c1t1d0s0

for x86 do
# installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t1d0s0
# zpool export altrpool
# init 5
remove source disk (c1t0d0s0) and move target disk (c1t1d0s0) to slot0
-insert solaris10 dvd
ok boot cdrom -s
# zpool import altrpool rpool
# init 0
ok boot disk1

ERROR:
Rebooting with command: boot disk1
Boot device: /p...@1c,60/s...@2/d...@1,0  File and args:
no pool_props
Evaluating:
The file just loaded does not appear to be executable.
ok

QUESTIONS:
1. what's wrong what my steps
2. any better idea

thanks 

-Kyle




 -Kyle


thx
jake
  


___
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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Kyle McDonald


Jacob Ritorto wrote:

Is this implemented in OpenSolaris 2008.11?  I'm moving move my filer's rpool 
to an ssd mirror to free up bigdisk slots currently used by the os and need to 
shrink rpool from 40GB to 15GB. (only using 2.7GB for the install).

  
Your best bet would be to install the new ssd drives, create a new pool, 
snapshot the exisitng pool and use ZFS send/recv to migrate the data to 
the new pool. There are docs around about how install grub and the boot 
blocks on the new devices also. After that remove (export!, don't 
destroy yet!)

the old drives, and reboot to see how it works.

If you have no problems, (and I don't think there's anything technical 
that would keep this from working,) then you're good. Otherwise put the 
old pool back in. :)



 -Kyle


thx
jake
  


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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Kyle McDonald


Martin wrote:

C,

I appreciate the feedback and like you, do not wish to start a side rant, but 
rather understand this, because it is completely counter to my experience.

Allow me to respond based on my anecdotal experience.

  

What's wrong with make a new pool.. safely copy the data. verify data
and then delete the old pool..



You missed a few steps.  The actual process would be more like the following.
1. Write up the steps and get approval from all affected parties
-- In truth, the change would not make it past step 1.
  

Maybe, but maybe not see below...

2. Make a new pool
3. Quiesce the pool and cause a TOTAL outage during steps 4 through 9
  
That's not entirely true. You can use ZFS send/recv to do the major 
first pass of  #4  (and #5 against the snapshot) Live before the total 
outage.
Then after you quiesce everything, you could use an incremental 
send/recv copy the changes since then quickly, reducing down time.


I'd probably run a second full verify anyway, but in theory, I beleive 
the ZFS checksums are used in the send/recv process to ensure that there 
isn't any corruption, so after enough positive experience, I might start 
to skip the second verify.


This should greatly reduce the length of the down time.


Everyone.

  

and then one day [months or years later] wants to shrink it...



Business needs change.  Technology changes.  The project was a pilot and 
canceled.  The extended pool didn't meet verification requirements, e,g, 
performance and the change must be backed out.
In an Enterprise, a change for performance should have been tested on 
another identical non-production system before being implemented on the 
production one.


I'd have to concur there's more useful things out there. OTOH... 



That's probably true and I have not seen the priority list.  I was merely amazed at the 
number of "Enterprises don't need this functionality" posts.

  
All that said, as a personal home user, this is a feature I'm hoping for 
all the time. :)


 -Kyle


Thanks again,
Marty
  


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

Re: [zfs-discuss] Shrinking a zpool?

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.

On Aug 5, 2009, at 9:17 AM, Martin wrote:

You are the 2nd customer I've ever heard of to use shrink.


This attitude seems to be a common theme in ZFS discussions: "No  
enterprise uses shrink, only grow."


Maybe.  The enterprise I work for requires that every change be  
reversible and repeatable.  Every change requires a backout plan and  
that plan better be fast and nondisruptive.


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 :-)


Who are these enterprise admins who can honestly state that they  
have no requirement to reverse operations?


Backout plans are not always simple reversals.  A well managed site will
have procedures for rolling upgrades.

Who runs a 24x7 storage system and will look you in the eye and  
state, "The storage decisions (parity count, number of devices in a  
stripe, etc.) that I make today will be valid until the end of time  
and will NEVER need nondisruptive adjustment.  Every storage  
decision I made in 1993 when we first installed RAID is still  
correct and has needed no changes despite changes in our business  
models."


My experience is that this attitude about enterprise storage borders  
on insane.


Something does not compute.


There is more than one way to skin a cat.
 -- richard

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

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread Jacob Ritorto

+1

Thanks for putting this in a real world perspective, Martin.  I'm faced with 
this exact circumstance right now (see my post to the list from earlier today). 
 Our ZFS filers are highly utilised, highly trusted components at the core of 
our enterprise and serve out OS images, mail storage, customer facing NFS 
mounts, CIFS mounts, etc. for nearly all of our critical services.  Downtime 
is, essentially, a catastrophe and won't get approval without weeks of 
painstaking social engineering..

jake
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Shrinking a zpool?

C,

I appreciate the feedback and like you, do not wish to start a side rant, but 
rather understand this, because it is completely counter to my experience.

Allow me to respond based on my anecdotal experience.

> What's wrong with make a new pool.. safely copy the data. verify data
> and then delete the old pool..

You missed a few steps.  The actual process would be more like the following.
1. Write up the steps and get approval from all affected parties
-- In truth, the change would not make it past step 1.
2. Make a new pool
3. Quiesce the pool and cause a TOTAL outage during steps 4 through 9
4. Safely make a copy of the data
5. Verify the data
6. Export old pool
7. Import new pool
8. Restart server
9. Confirm all services are functioning correctly
10. Announce the outage has finished
11. Delete the old pool

Note step 3 and let me know which 24x7 operation would tolerate an extended 
outage (because it would last for hours or days) on a critical production 
server.

One solution is not to do this on a critical enterprise storage, and that's the 
point I am trying to make.

> Who in the enterprise just allocates a
> massive pool

Everyone.

> and then one day [months or years later] wants to shrink it...

Business needs change.  Technology changes.  The project was a pilot and 
canceled.  The extended pool didn't meet verification requirements, e,g, 
performance and the change must be backed out.  Business growth estimates are 
grossly too high and the pool needs migration to a cheaper frame in order to 
keep costs in line with revenue.  The pool was made of 40 of the largest disks 
at the time and now, 4 years later, only 10 disks are needed to accomplish the 
same thing while the 40 original disks are at EOL and no longer supported.

The list goes on and on.

> I'd have to concur there's more useful things out there. OTOH... 

That's probably true and I have not seen the priority list.  I was merely 
amazed at the number of "Enterprises don't need this functionality" posts.

Thanks again,
Marty
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Re: [zfs-discuss] Shrinking a zpool?

2009-08-05 Thread C. Bergström


Martin wrote:

You are the 2nd customer I've ever heard of to use shrink.



This attitude seems to be a common theme in ZFS discussions: "No enterprise uses 
shrink, only grow."

Maybe.  The enterprise I work for requires that every change be reversible and 
repeatable.  Every change requires a backout plan and that plan better be fast 
and nondisruptive.

Who are these enterprise admins who can honestly state that they have no requirement to 
reverse operations?  Who runs a 24x7 storage system and will look you in the eye and 
state, "The storage decisions (parity count, number of devices in a stripe, etc.) 
that I make today will be valid until the end of time and will NEVER need nondisruptive 
adjustment.  Every storage decision I made in 1993 when we first installed RAID is still 
correct and has needed no changes despite changes in our business models."

My experience is that this attitude about enterprise storage borders on insane.
  
What's wrong with make a new pool.. safely copy the data. verify data 
and then delete the old pool..   Who in the enterprise just allocates a 
massive pool and then one day wants to shrink it...  For home nas I 
could see this being useful.. I'm not aruging there isn't a use case, 
but in terms of where my vote for time/energy of the developers goes.. 
I'd have to concur there's more useful things out there.  OTOH... 
once/if the block reallocation code is dropped (webrev?) the shrinking 
of a pool should be a lot easier.  I don't mean to go off on a side 
rant, but afaik this code is written and should have been available.  If 
we all pressured Green-bytes with an open letter it would maybe 
help..  The legal issues around this are what's holding it all up.  
@Sun people can't comment I'm sure, but this is what I speculate.


./C

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

Re: [zfs-discuss] Shrinking a zpool?