Can we increase size of SAN LUN already having data on Solaris SPARC system

[TechiS]

Dear Team,

We have  Volume of 60 GB inside it LUN of 50GB , this is mapped to Solaris SPARC system and created mount point of /data of size 50GB

now we need to extend this mount point size already having data from 50 GB to  70GB,

so we will fist increase size of volume from 60GB to 80 GB and LUN from 50GB  to 70GB.

so on Solaris OS is this change supported, do we need to do anything special on OS level?

In short, can we extend the size of SAN mount point on Solaris OS which is already having the data?

Thanks

[Ontapforrum]

Which ONTAP version FILER running (kb is referenced below) ?
Kb states: Starting from ONTAP 9.6, newly created LUNs with the OS type solaris have zero-sized prefix and suffix streams, and lun resize command works as expected.

LUN resize function not implemented for Solaris LUN:
https://kb.netapp.com/onprem/ontap/da/SAN/LUN_resize_function_not_implemented_for_Solaris_LUN

If you are running 9.6 (Means the LUNs were created in 9.6 onwards), then you can re-size it (Before making any changes to the LUN, always have a snapshot so that you can go back to the data point before the resize), if it were created prior to 9.6 then I doubt you could do anything. As per the KB, you could use the workaround to create a LUN with suffix-zero but not the existing one.

Standard steps would be:

From storage side:
1) Grow the volume (resize)
2) Grow the lun (resize)

From Solaris side: (speak to your solaris/unix team, don't take my words)
Here is the doc on how to identify solaris file-system
https://docs.oracle.com/cd/E23824_01/html/821-1459/fsoverview-28729.html

Note: As long as you have a taken a snapshot of the good working filesystem, you can always restore the snapshot and get your system back.

[TechiS]

So from 9.6 ONTAP version, LUN resize on Solaris is supported correct? (Yes, No)

Answer:

I guess we need to just make sure that while creating LUN in Solaris, prefix-size ,suffix-size should be zero, so that we can resize the size of LUN assigned to Solaris, correct? Yes/No

Answer:

Thanks

[Ontapforrum · Accepted solution]

So from 9.6 ONTAP version, LUN resize on Solaris is supported correct? (Yes, No)

Answer:  Yes but LUN resize is supported on prior to 9.6 as well, provided it has been created with the workaround (prefix-size 0 -suffix-size 0). From 9.6 onwards, 'create lun' will automatically have zero-sized prefix and suffix streams added for the OS type solaris, hence lun resize will work as expected.

I guess we need to just make sure that while creating LUN in Solaris, prefix-size ,suffix-size should be zero, so that we can resize the size of LUN assigned to Solaris, correct? Yes/No Answer: Yes, Prior to 9.6 (9.0 to 9.5), you need to use this workaround as mentioned in kb. This is b'cos LUN resize requires zero suffix stream. If you are already on 9.6 or later, then you don't have to explicitly add it during lun creation.

[Ontapforrum]

To confirm: (9.6 onwards)
1) Just create a LUN without using prefix/suffix-size
2) To confirm prefix/suffix-size value, run this command:
::> set diag
Warning: These diagnostic commands are for use by NetApp personnel only.
Do you want to continue? {y|n}: y
::*> lun show -ostype solaris -fields prefix-size,suffix-size

It should return zero.

[TechiS]

10/10 for reply!

Thanks for giving answer to my queries.

Last query: LUN already having data, can also be resize in Solaris with out any data loss or corruption, correct if we have prefix ans uffix size as zero. ? ( Yes/No)

Answer:

Just need to know one thing, suppose my management team asks me whether I have NetApp OEM confirmation that LUN already having data assigned to Solaris OS can be resized or not, then can I share this post response as proof or do i need to  open case with NetApp and get same confirmation.

Just need to understand this.

Thanks.

[Ontapforrum]

You're welcome. Sorry but I neither represent NetApp nor I represent NetApp support, and more so it is not advisable to take 'forum threads' as authority or any sort of guarantee. It's just a place to help each other with queries & troubleshooting of NetApp products. You are more than welcome to open a support case to get more clarification around this.

Coming to your query regarding the confirmation, I just want to say that, LUN is a BLOCK device and once it is mapped to HOST, it is up to HOST to layer/partition it and manage it. NetApp owns only the 'LUN' (BLOCK FILE) and it provides WAFL snapshot to ensure the data integrity within the FILER is guaranteed and can be restored back to its previous point-in-time snapshot. Even more cool is the feature called 'flexclone', I am sure you have used this before. This will allow you to not only test-resizing but give you all the confidence to perform same steps on the production file-system.

However, that does not mean that NetApp does not provide any help in regards to OS interoperability with NetApp ONTAP. Each supported OS is well tested with features and it further provides Best Practices (Recommended settings to be used with Host OS & ONTAP) and Host side Utilities that you can download for free and manage the LUN more efficiently.

Solaris Host Utilities with NetApp ONTAP:
https://docs.netapp.com/us-en/ontap-sanhost/hu_solaris_114.html#installing-the-solaris-host-utilities

Assuming that the Solaris is using some kind of volume manager on the host side (I am saying this purely based on my experience with redhat/centos LVM, talk to your Solaris team).

High-level steps will be:
1) Resize Vol/LUN in FILER
2) Get the host OS to see the new LUN size
3) Get the 'whatever volume manager' you are using to increase the available space in diskgroup/pv
4) Get the new diskgroup/pv to increase the size of the volume
5) Grow the filesystem on the volume to use the increased space.

On the side note: I have worked with Oracle DB/Unix team in the past, and every time there was an update to be patched on the 'Production server', application services were stopped, file-system was cleanly unmounted, and ONTAP snapshot was taken. At times, update were successful, and at times update failed, and when it failed, we were asked to 'revert' to last point-in-time snapshot, and it worked all the time. Therefore, as as long as you have taken a snapshot of the Volume (hosting the LUN) prior to re-sizing the LUN, you can always revert it back in case anything goes wrong.

If you want to be 100% sure if it will work, follow these steps:
1) Ensure flexclone is licensed.
2) volume clone the production vol/lun that is hosting the Solaris LUN
3) Map the cloned_solaris_LUN to a Solaris test box and mount it.
4) check if the file-system is read/writable and existing-data can be read/write fine.
5) unmount the file-system
6) resized the cloned_volume
7) resized the cloned_lun
😎 Do the steps mentioned in the high-level steps from the host side to grow the space.
9) If it works, that means you can go ahead with the plans on the Production server

[TechiS]

Thanks for your details in reply.

Ok I got, I will open ticket with NetApp and get it confirmed by them, however we have already successfully extended LUN on Solaris which is having data without any issue with prefix and suffix as zero.

However regarding points  below ,

"

3) Map the cloned_solaris_LUN to a Solaris test box and mount it.
4) check if the file-system is read/writable and existing-data can be read/write fine.

"

above steps I am still not able to test it, NetApp says, steps to mount clone LUN is host side stuff, NetApp does not support on this.

Till now , I am just able to map NAS volume clone  successfully and test it, not SAN LUN.

Thanks