Hello, I know, that you had this discussion a view days ago but I''m in the installation phase of our new production servers and I intend to migrate the data from UFS volumes to ZFS volumes in near future. For doing this it must be ABSOLUTELY sure that I can resize the SAN LUNs because during the last 4 years I had to double the LUN size every year. I tried to resize a test volume following some hints from this forum but didn''t succeed. My Environment and procedure of doing it: * Sunfire X4600 running Solaris 10 (11/06) accessing through MPXIO an Compaq EVA3000 SAN * Procedure of creation: > zpool create evatestpool c5t600508B4000104ED0001600001430000d0 > zfs create evatestpool/testvol1 > zfs set mountpoint=/testmnt/testvol1 evatestpool/testvol1 * Until here everything is fine, but than the resize had to follow: > zpool export evatestpool > than the resize of the LUN was performed within the SAN > format -e > Searching for disks...done > > > AVAILABLE DISK SELECTIONS: > 0. c1t0d0 <drive type unknown> > /pci at 0,0/pci108e,cb84 at 2/storage at 5/disk at 0,0 > 1. c3t0d0 <DEFAULT cyl 8872 alt 2 hd 255 sec 63> > /pci at 0,0/pci1022,7458 at 11/pci1000,3060 at 4/sd at 0,0 > 2. c5t600508B4000104ED0001600001430000d0 <COMPAQ-HSV110 (C)COMPAQ-3028-20.00GB> > /scsi_vhci/disk at g600508b4000104ed0001600001430000 > Specify disk (enter its number): 2 > selecting c5t600508B4000104ED0001600001430000d0 > [disk formatted] > > [...] > format> l > [0] SMI Label > [1] EFI Label > Specify Label type[1]: > Ready to label disk, continue? y > > format> q > zpool import evatestpool And the size is still the same. Did I miss something? Thanks for your answer, Gernot This message posted from opensolaris.org
I don''t believe LUN expansion is quite yet possible under Solaris 10 (11/06). I believe this might make it into the next update but I''m not sure on that. Someone from Sun would need to comment on when this will make it into the production release of Solaris. I know this because I was working with a person from Sun testing a utility which will detect the larger LUN and update the disk label. Then at that point if you export the pool and import it again the added space will show up. The utility was just for testing however. I''m waiting as well for the automatic LUN expansion stuff. David This message posted from opensolaris.org
Hey David might I need to track the evolution of that size-change utility to ZFS could I have a contact at Sun that would be able to give me more information on that ? Being able to resize LUNS dynamically Is a reality here, I currently do it with UFS after a EMC Clariion LUN Migration to a larger LUN That is our current show-stopper to using ZFS thanks Yannick This message posted from opensolaris.org
I''m planning on putting back the changes to ZFS into Opensolaris in upcoming weeks. This will still require a manual step as the changes required in the sd driver are still under development. The ultimate plan is to have the entire process totally automated. If you have more questions, feel free to drop me a line. Thanks, George Yan wrote:> Hey David > might I need to track the evolution of that size-change utility to ZFS > could I have a contact at Sun that would be able to give me more information on that ? > Being able to resize LUNS dynamically Is a reality here, I currently do it with UFS after a EMC Clariion LUN Migration to a larger LUN > > That is our current show-stopper to using ZFS > thanks > Yannick > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
I can understand lun expansion capability being an issue with more a traditional volume manager or even a single lun but with pooled storage and the ability to expand the pool, benefiting all filesystems in the pool it seems a shame to consider lun expansion a show stopper. Even so, having all the details automated and transparent to the administrator would be very cool. Regards, Vic On 8/7/07, George Wilson <George.Wilson at sun.com> wrote:> I''m planning on putting back the changes to ZFS into Opensolaris in > upcoming weeks. This will still require a manual step as the changes > required in the sd driver are still under development. > > The ultimate plan is to have the entire process totally automated. > > If you have more questions, feel free to drop me a line. > > Thanks, > George > > Yan wrote: > > Hey David > > might I need to track the evolution of that size-change utility to ZFS > > could I have a contact at Sun that would be able to give me more information on that ? > > Being able to resize LUNS dynamically Is a reality here, I currently do it with UFS after a EMC Clariion LUN Migration to a larger LUN > > > > That is our current show-stopper to using ZFS > > thanks > > Yannick > > > > > > This message posted from opensolaris.org > > _______________________________________________ > > zfs-discuss mailing list > > zfs-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >
Yannick, How do you grow the VTOC on UFS dynamically? - Bob>>> Yan <yanmercier at gmail.com> 8/6/2007 9:29 PM >>>Hey David might I need to track the evolution of that size-change utility to ZFS could I have a contact at Sun that would be able to give me more information on that ? Being able to resize LUNS dynamically Is a reality here, I currently do it with UFS after a EMC Clariion LUN Migration to a larger LUN That is our current show-stopper to using ZFS thanks Yannick This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss at opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070807/856b6c62/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: bg_bluefade_195x42.jpg Type: image/jpeg Size: 887 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070807/856b6c62/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_sun_small.gif Type: image/gif Size: 1042 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070807/856b6c62/attachment.gif>
Hi Yannick, Just to be sure I understand the restriction; with the clariion you are limited in host side volume management so that basically you use single luns with ufs filesystems on them and if you need additional space in the ufs filesystem the only option is to resize the lun on the clarion, rewrite the vtoc on the lun and then growfs? That seems like a significant limitation, especially in a very dynamic storage centric environment. Just curious, any idea how much performance suffers on the host if write coelesing is unusable? Regards, Vic On 8/7/07, Yannick Mercier <yanmercier at gmail.com> wrote:> From a storage administrator perspective, when doing capacity planning > on a EMC Clariion Unit, it becomes a pain to have more than one LUN > for the same volume. The Clariion with Navisphere agent gives the > storage administrator more visibility in the storage management > interface, showing mountpoints on the hosts for each Luns > The EMC CLariion Storage best practices recommends to use one LUN per volume > The write coelesing feature may be unusable if using more than one lun > per volume if striped in ZFS > > Yannick > > On 8/7/07, Victor Engle <victor.engle at gmail.com> wrote: > > I can understand lun expansion capability being an issue with more a > > traditional volume manager or even a single lun but with pooled > > storage and the ability to expand the pool, benefiting all filesystems > > in the pool it seems a shame to consider lun expansion a show stopper. > > > > Even so, having all the details automated and transparent to the > > administrator would be very cool. > > > > Regards, > > Vic > > > > > > On 8/7/07, George Wilson <George.Wilson at sun.com> wrote: > > > I''m planning on putting back the changes to ZFS into Opensolaris in > > > upcoming weeks. This will still require a manual step as the changes > > > required in the sd driver are still under development. > > > > > > The ultimate plan is to have the entire process totally automated. > > > > > > If you have more questions, feel free to drop me a line. > > > > > > Thanks, > > > George > > > > > > Yan wrote: > > > > Hey David > > > > might I need to track the evolution of that size-change utility to ZFS > > > > could I have a contact at Sun that would be able to give me more information on that ? > > > > Being able to resize LUNS dynamically Is a reality here, I currently do it with UFS after a EMC Clariion LUN Migration to a larger LUN > > > > > > > > That is our current show-stopper to using ZFS > > > > thanks > > > > Yannick > > > > > > > > > > > > This message posted from opensolaris.org > > > > _______________________________________________ > > > > zfs-discuss mailing list > > > > zfs-discuss at opensolaris.org > > > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > _______________________________________________ > > > zfs-discuss mailing list > > > zfs-discuss at opensolaris.org > > > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss > > > > > >
I found this discussion just today as I recently set up my first S10 machine with ZFS. We use a NetApp Filer via multipathed FC HBAs, and I wanted to know what my options were in regards to growing a ZFS filesystem. After looking at this thread, it looks like there is currently no way to grow an existing LUN on our NetApp and then tell ZFS to expand to fill the new space. This may be coming down the road at some point, but I would like to be able to do this now. At this point, I believe I have two options: 1. Add a second LUN and simply do a "zpool add" to add the new space to the existing pool. 2. Create a new LUN that is the size I would like my pool to be, then use "zpool replace oldLUNdev newLUNdev" to ask ZFS to resilver my data to the new LUN then detach the old one. The advantage of the first option is that it happens very quickly, but it could get kind of messy if you grow the ZFS pool on multiple occasions. I''ve read that some SANs are also limited as to how many LUNs can be created (some are limitations of the SAN itself whereas I believe that some others impose a limit as part of the SAN license). That would also make the first approach less attractive. The advantage of the second approach is that all of the space would be contained in a single LUN. The disadvantages are that this would involve copying all of the data from the old LUN to the new one and also this means that you need to have enough free space on your SAN to create this new, larger LUN. Is there a best practice regarding this? I''m leaning towards option #2 so as to keep the number of LUNs I have to manage at a minimum, but #1 seems like a reasonable alternative, too. Or perhaps there''s an option #3 that I haven''t thought of? Thanks, Bill This message posted from opensolaris.org
I like option #1 because it is simple and quick. It seems unlikely that this will lead to an excessive number of luns in the pool in most cases unless you start with a large number of very small luns. If you begin with 5 100GB luns and over time add 5 more it still seems like a reasonable and manageable pool with twice the original capacity. And considering the array can likely support hundreds and perhaps thousands of luns then it really isn''t an issue on the array side either. Regards, Vic On 9/12/07, Bill Korb <korb at qisc.com> wrote:> I found this discussion just today as I recently set up my first S10 machine with ZFS. We use a NetApp Filer via multipathed FC HBAs, and I wanted to know what my options were in regards to growing a ZFS filesystem. > > After looking at this thread, it looks like there is currently no way to grow an existing LUN on our NetApp and then tell ZFS to expand to fill the new space. This may be coming down the road at some point, but I would like to be able to do this now. > > At this point, I believe I have two options: > > 1. Add a second LUN and simply do a "zpool add" to add the new space to the existing pool. > > 2. Create a new LUN that is the size I would like my pool to be, then use "zpool replace oldLUNdev newLUNdev" to ask ZFS to resilver my data to the new LUN then detach the old one. > > The advantage of the first option is that it happens very quickly, but it could get kind of messy if you grow the ZFS pool on multiple occasions. I''ve read that some SANs are also limited as to how many LUNs can be created (some are limitations of the SAN itself whereas I believe that some others impose a limit as part of the SAN license). That would also make the first approach less attractive. > > The advantage of the second approach is that all of the space would be contained in a single LUN. The disadvantages are that this would involve copying all of the data from the old LUN to the new one and also this means that you need to have enough free space on your SAN to create this new, larger LUN. > > Is there a best practice regarding this? I''m leaning towards option #2 so as to keep the number of LUNs I have to manage at a minimum, but #1 seems like a reasonable alternative, too. Or perhaps there''s an option #3 that I haven''t thought of? > > Thanks, > Bill > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >