Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
increasing size of a zfs filesystem in SC 3.2
75 views
Skip to first unread message
Dariusz Dolecki
Oct 25, 2012, 2:41:21 PM10/25/12
to
Here's what I'm thinking:
1)have storage team assign new lun
2)do devfsadm on all cluster nodes
3)on the cluster node where the zpool is currently imported do a zpool add <zpool name> <lun>
Do I need to worry about formatting the lun - in the past I have not had to......
1)have storage team assign new lun
2)do devfsadm on all cluster nodes
3)on the cluster node where the zpool is currently imported do a zpool add <zpool name> <lun>
Do I need to worry about formatting the lun - in the past I have not had to......
cindy swearingen
Oct 25, 2012, 3:29:39 PM10/25/12
to
On Oct 25, 12:41 pm, Dariusz Dolecki <dariusz.dole...@gmail.com>
wrote:
Which Solaris release is this?
It could be that you just need to have the storage team expand the LUN
and then you can set the
autoexpand property on the pool. This feature is available in Solaris
11 and you need to patch for
Solaris 10.
Also, adding a new LUN to an existing pool just adds another non-
redundant LUN. Is this
what you want?
Thanks, Cindy
wrote:
It could be that you just need to have the storage team expand the LUN
and then you can set the
autoexpand property on the pool. This feature is available in Solaris
11 and you need to patch for
Solaris 10.
Also, adding a new LUN to an existing pool just adds another non-
redundant LUN. Is this
what you want?
Thanks, Cindy
Dariusz Dolecki
Oct 25, 2012, 3:50:26 PM10/25/12
to
cat /etc/release
Solaris 10 8/07 s10s_u4wos_12b SPARC
Copyright 2007 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 August 2007
Yes, I think redundancy is not something we are currently thinking about.
cindy swearingen
Oct 25, 2012, 4:25:46 PM10/25/12
to
its old enough
that I can't remember whether when you can export/import the pool (or
reboot) to see the
expanded pool space. This might not be a good solution anyway in a
cluster environment,
so yes, you can either add another non-redundant LUN or outright
replace the smaller lun
with larger LUN by using zpool replace.
Thanks, Cindy
ITguy
Oct 25, 2012, 6:11:14 PM10/25/12
to
For Solaris cluster, I'd run "scdidadm -r" too.
Is the LUN itself fault tolerant? If so, it might make sense to simply add the new LUN to the existing pool as you've planned. This may increase throughput to the pool as the new LUN will have it's own IO queue through the storage driver.
Suggested reading:
http://docs.oracle.com/cd/E19787-01/820-4685/scdidadm-1m/index.html
http://solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Device_I.2FO_Queue_Size_.28I.2FO_Concurrency.29
Is the LUN itself fault tolerant? If so, it might make sense to simply add the new LUN to the existing pool as you've planned. This may increase throughput to the pool as the new LUN will have it's own IO queue through the storage driver.
Suggested reading:
http://docs.oracle.com/cd/E19787-01/820-4685/scdidadm-1m/index.html
http://solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Device_I.2FO_Queue_Size_.28I.2FO_Concurrency.29
Sami Ketola
Oct 26, 2012, 2:13:14 AM10/26/12
to
Dariusz Dolecki <dariusz...@gmail.com> wrote:
> Here's what I'm thinking:
> 1)have storage team assign new lun
> 2)do devfsadm on all cluster nodes
> 3)on the cluster node where the zpool is currently imported do a zpool add <zpool name> <lun>
You also need to generate Cluster DID device for the new lun before adding it to pool.
> Here's what I'm thinking:
> 1)have storage team assign new lun
> 2)do devfsadm on all cluster nodes
> 3)on the cluster node where the zpool is currently imported do a zpool add <zpool name> <lun>
scdidadm is your friend here. Assuming you have HA service you also need to do this on
all nodes where the HA service is possible to fail to.
Sami
0 new messages