Exadata Compute Node: Filesystem resize issue

Exadata documentation talks about how to resize an LVM Partitions in compute node for two different scenario -

Option 1: Extending the root LVM Partition on Systems Running Oracle Exadata Storage Server Software Release 11.2.3.2.1 or Later

Option 2: Extending the root LVM Partition on Systems Running Oracle Exadata Storage Server Software Earlier than Release 11.2.3.2.1

Obviously anyone will consider to resize the filesystem ONLINE using Option 1. But if the environment came (patched/upgraded) from an older image version (e.g. from <= 11.2.3.2.0, look for imagehistory output) but current running a newer image version, lets say 11.2.3.3.x, 12.1.2.1.x or even greater, though the image is newer but still it might not possible to do the filesystem resize online. This is mainly applicable for X2, X3 (early releases).

Since this environment comes from an older image version, you will see that the filesystem does not have resize_inode options thus it's not possible to resize the filesystem online though it's a new image version currently. In this case, the only possible option is to use the offline method which is a bit critical/complex in terms of the online method.

Below is a series of steps which can be performed to enable the resize_inode option in the filesystem and does not required to use the Option 2.

 -- Currently the filesystem does not have 'resize_inode' options 
 -- No output of the below commands, thus we won’t able to resize the filesystem online.  
 # tune2fs -l /dev/mapper/VGExaDb-LVDbSys1 | grep resize_inode  
 # tune2fs -l /dev/mapper/VGExaDb-LVDbSys2 | grep resize_inode  

 -- Look for the inactive root partitions  
 -- All Exadata compute node should have an inactive root partition which normally used for backup purpose during patching  
 -- In this example: Active root partition is: LVDbSys1  
 [root@dm01db01 ~]# df -h /  
 Filesystem      Size Used Avail Use% Mounted on  
 /dev/mapper/VGExaDb-LVDbSys1  
             30G  18G  11G 63% /  
 -- Inactive root partition is: LVDbSys2  
 [root@dm01db01 ~]# lvm lvscan  
  ACTIVE      '/dev/VGExaDb/LVDbSys1' [30.00 GiB] inherit       << ---- Active
  ACTIVE      '/dev/VGExaDb/LVDbSys2' [30.00 GiB] inherit       << ---- Inactive
  ACTIVE      '/dev/VGExaDb/LVDbSwap1' [24.00 GiB] inherit  
  ACTIVE      '/dev/VGExaDb/LVDbOra1' [150.00 GiB] inherit  
  ACTIVE      '/dev/VGExaDb/LVDbOra2' [450.00 GiB] inherit  

 Step 1. Remove the existing backup LVM partition  
 Note: The existing backup of the / (root) partition will be lost but we will take another backup shortly  
 # lvremove /dev/VGExaDb/VGExaDb-LVDbSys2  

 Step 2. Run (Take a backup of / (root) filesystem): /opt/oracle.SupportTools/dbserver_backup.sh

 Note: It will create a new VGExaDb-LVDbSys2, if not, then create one manually as below and re-run dbserver_backup.sh once again -  
 # lvcreate -L 30G -n /dev/VGExaDb/VGExaDb-LVDbSys2  
 # mkfs.ext3 /dev/VGExaDb/VGExaDb-LVDbSys2  
 -- But dont’t add any label.

 Step 3. Once the backup is completed, check the 'resize_inode' option.
 # tune2fs -l /dev/mapper/VGExaDb-LVDbSys2 | grep resize_inode  
 Filesystem features:   has_journal ext_attr resize_inode dir_index filetype sparse_super large_file  

 Step 4. Since the current image and backup image is same version, so it's not required to do anything in the /boot partition (e.g. change in grub.conf), but only -  
 -- Remove/Add the label  
 # e2label /dev/VGExaDb/LVDbSys1 ""  
 # e2label /dev/VGExaDb/LVDbSys2 DBSYS  
 OR  
 It's possible to use: dbnodeupdate.sh -r.  (Recommend: Rollback using DBNU is well within Oracle Supported Procedure)
 In this case, dbnodeupdate will rollback to the same image version using the LVDbSys2 partition  

 Step 5. Restart OS and it should be come up with LVDbSys2  

 Step 6. Remove & recreate the current backup LVM partition which is /dev/VGExaDb/VGExaDb-LVDbSys1. (Similar to Step 1 & 2 but different partition)  

 Step 7. Take another backup using dbserver_backup.sh (Similar to Step 1 & 2 but different partition)  

 Step 8. At this point, we should be able to resize the root LVM partition online using lvextend & resize2fs  

For /u01 mount point, it's easier to perform the offline method since it's not required to restart the server, only unmount of the filesystem required.