Help!!! I need to grow an existing LUN on RedHat 4. It appears we are not using LVM,
 

Help!!! I need to grow an existing LUN on RedHat 4. It appears we are not using LVM, but not sure.

The filesystem appears like so:

/dev/mapper/bin_01 20G 3.1G 16G 17% /oracle/orabin

it is EXT3

The storage is on NetApp and is SAN connected. I will be growing the NetApp volume by 1TB, but I can not figure out how to safely resize the filesystem from an O/S perspective.

I have the option to stop oracle and reboot the server, if need be!

What are the steps???

God bless.

kevin

Possible.
1. Grow the LUN on the NetApp.
2. Reboot or otherwise get Linux to see the new size (rescan the scsi bus? what does /dev/mapper imply? Is that a software RAID device? I don't have any direct experience with NetApps).
3. run: ext2online /dev/mapper/bin_01

As always, have a backup, and if desired, test with a different unused LUN first.

i forgot to mention it is an ext3 volume and not ext3. does that matter?

thanks,

kevin

Grow existing LUN RH4.
 

Help!!! I need to grow an existing LUN on RedHat 4. It appears we are not using LVM, but not sure.

The filesystem appears like so:

/dev/mapper/bin_01 20G 3.1G 16G 17% /oracle/orabin

It is an ext3 filesystem

The storage is on NetApp and is SAN connected. I will be growing the NetApp volume by 1TB, but I can not figure out how to safely resize the filesystem from an O/S perspective.

I have the option to stop oracle and reboot the server, if need be!

What are the steps???

God bless.

kevin

You wrote "ext3" twice. But ext2online runs on both ext2 and ext3.

Step 1. Backup
Step 2. Backup
Step 3. Verify Backups

OK, now that that's out of the way, I would first confirm that it is indeed not under LVM or clarify why it is listed under dev-mapper's control.
Since it is ext3, the resize should be relatively simple once the underlying storage capacity has been increased and is visible to the OS, but the steps will vary depending on whether it is a traditional partition, an LVM, or why it is listed under dev-mapper if not using LVM. Once the partition is extended, or the LV extended, or whatever may need to be done depending on how it is controlled by dev-mapper if not using LVM, the resize2fs or ext2online command can be used to grow the filesystem to the newly available contiguous unallocated capacity.

A man after my own heart (@rayfordj) .... ;)

I'd be guessing that is an Oracle raw filesystem - better not try an online (active) resize. Especially on an old version of e2fsprogs.

Still confused....
 

arrrgh.

1) how can i tell if it is under LVM or not? Is there a command I can use to find out for sure?

2) When you say perform a backup, what kind of backup are you referring to? A backup of the linux Host O/S? I have netbackup. Do I just perform a backup of the root filesystem?

Thanks all.

God bless.

kevin

1) you are welcome to post the output of the above in CODE tags here for review.

2) have a backup of any and all data that you might need to restore should something unexpected or unplanned occur and you needed to recover. This may be nothing, this may be everything, it may be just the data on the filesystem mounted /oracle/orabin, or it may only be a few select files. As only you can make the determination of what is important or not on your system the responsibility falls upon you. While backups of any critical and/or production data should be taken (and verified) regularly, it is doubly important to have a contingency plan when manipulating filesystems. Just because one may say that they have never had a single problem when extending an LV and then extended the filesystem does not mean that someone else may not have experienced catastrophe after catastrophe when attempting the same. Yes, the tools are much better; Yes, things are much more resilient; Yes, stuff still happens that could leave you in a bad situation if you do not have a recovery plan.

[root@tkprddb03 ~]# pvs
[root@tkprddb03 ~]# vgs
No volume groups found
[root@tkprddb03 ~]# lvs
No volume groups found

[root@tkprddb03 ~]# dmsetup table
bin_01: 0 41943040 multipath 1 queue_if_no_path 0 2 1 round-robin 0 1 1 8:96 128 round-robin 0 1 1 8:48 128
rec_01: 0 1048735744 multipath 1 queue_if_no_path 0 2 1 round-robin 0 1 1 8:112 128 round-robin 0 1 1 8:64 128
data_01: 0 5452595200 multipath 1 queue_if_no_path 0 2 1 round-robin 0 1 1 8:80 128 round-robin 0 1 1 8:32 128

[root@tkprddb03 ~]# dmsetup ls --tree
bin_01 (253:1)
├─ (8:48)
└─ (8:96)
rec_01 (253:2)
├─ (8:64)
└─ (8:112)
data_01 (253:0)
├─ (8:32)
└─ (8:80)

Ah, so it is using dm-multipath... that explains why it is listed under dev-mapper. If I were to guess, I'd say sdd and sdg are the two sd-devices that multi-pathed and accessed as /dev/mapper/bin_01. Running multipath -v2 -ll should give more useful information regarding the mpath configuration.

As to HOW to go about it in your configuration I am not certain, but as to WHAT needs to be done:

• backup data, as necessary, and perform expansion during scheduled maintenance outage in case you need to take the service(s), filesystem, and/or server offline.
• unmount the filesystem (umount /oracle/orabin) and run a filesystem check (fsck -f /dev/mapper/bin_01) on it to ensure the filesystem is clean/healthy. (This is not absolutely necessary, but worth doing if you can before proceeding because if there are problems with the filesystem you want to fix them first.)
• extend the LUN on the NetApp/SAN. (I am not familiar with this so you are on your own here.)
• run partprobe and confirm that the SD-device(s) report the increased capacity. (If the SD-devices do not reflect the new capacity and rescanning does not pick it up, you may need to reboot.)
• (There might be something here that needs to be done with multipath/multipathd if no reboot was needed in the previous step or you may need to reboot.)
• run resize2fs or ext2online on /dev/mapper/bin_01
• upon successful exit of filesystem extension, confirm available space on mounted filesystem.

If the multipath device (bin_01) reflects the additional 1TB added (going from 20G to 1044G) the dmsetup table output should change from bin_01: 0 41943040 multipath to something similar to bin_01: 0 2189426688 multipath. Until you get to the point that the mpath device (bin_01) reflects the increased capacity the filesystem will not be eligible for extension.

wow. this is awesome. Thanks so much. I will let you know how it goes!!! Will be performing this work in the next few days. Let me know if you ever need help with Solaris or NetApp NAS stuff, which is my specialty.

God bless.

kevin

Please post your thread in only one forum. Posting a single thread in the most relevant forum will make it easier for members to help you and will keep the discussion in one place. This thread is being closed because it is a duplicate.