resizing LUN (not file system) while the file system (ext3) is online

DISCUSSION Andrey Dmitriev 3 participants 4 messages May 25, 2006 SCSI

Share & tools

Andrey Dmitriev

author

2006-05-25 05:17 UTC #0 lore raw

Dear List,

Both EMC and NetApp claim that the file system needs to be unmounted while the LUN is being resized (migrated and resized in our case).

I understand that ext3 doesn't support online expansion (not in RedHat ES/AS at least), however, does it really matter what you're doing to the actual LUN in the background (as long as you're not reducing the LUN size)? The operating system won't know the partitioning changed until you tell it to reread the partition table.

Not following EMC/NetApp 'overcautious' instructions could save a tremendous amount of time during a LUN migration (instead of waiting for a LUN to migrate while the file system is online, the only wait you really sustain is how fast you type and re-partition)

I have just tried this with ext3 file system online, and it worked like I expected it to work.

EMC specifically states in the emc122304 (from their knowledge base):
" Step 3: Increase the size of the LUN using the backend array tools. In some cases, like with CLARiiON MetaLUN, this can actually be performed "online" in order to decrease the time that the file system is unavailable. However, just because the disk array can be done online that does not mean the application layer can handle online expansion (some file systems can handle online expansion, currently ext3 cannot)."

Yeah, file system can't expand.. but I am resizing the file system offline, why can't I resize the LUN online?

Am I missing something?

Below are my results.. I tried doing IO while migrating (and resizing) the LUN, but I think IO seized before migration was complete. Also, the majority of LUNs that usually need resizing are near capacity, mine obviously wasn't

B4 migration/growth

[root@ad-nfs1 kerberos]# df -k
/dev/emcpowerc1 20642412 5030932 14562908 26% /emc1

--after growth while the system was online

fdisk /dev/emcpowerc
Disk /dev/emcpowerc: 21.4 GB, 21474836480 bytes
64 heads, 32 sectors/track, 20480 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux

Command (m for help): q

[root@ad-nfs1 kerberos]# sfdisk -R /dev/emcpowerc
[root@ad-nfs1 kerberos]# fdisk /dev/emcpowerc

The number of cylinders for this disk is set to 30720. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux

[root@ad-nfs1 kerberos]# fdisk /dev/emcpowerc

Command (m for help): p

Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux

Command (m for help): d
Selected partition 1

Command (m for help): p

Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System

Command (m for help): n
Command action
e extended
p primary partition (1-4)
1
Invalid partition number for type `1'
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-30720, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-30720, default 30720):
Using default value 30720

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
[root@ad-nfs1 kerberos]# fdisk -l /dev/emcpowerc

Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       30720    31457264   83  Linux

-- notice, w/o fsck it'll not resize.. w/o -f option

[root@ad-nfs1 kerberos]# time fsck -f /dev/emcpowerc1
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/emcpowerc1: 254481/2621440 files (0.8% non-contiguous), 1410133/5242876 blocks

real    1m4.984s
user    0m1.348s
sys     0m1.617s

[root@ad-nfs1 kerberos]# resize2fs /dev/emcpowerc1 resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/emcpowerc1 to 7864316 (4k) blocks. The filesystem on /dev/emcpowerc1 is now 7864316 blocks long.

[root@ad-nfs1 kerberos]# mount /dev/emcpowerc1 /emc1/ [root@ad-nfs1 kerberos]# df -k|grep emc
/dev/emcpowerc1 30963692 5311440 24393964 18% /emc1

Limin Wang

2006-05-25 05:40 UTC #1 lore raw

Try with LVM, resize can be done online, without disrupting user service.

Regards,
Limin

Quoted 165 lines · Andrey Dmitriev

Dear List,
Both EMC and NetApp claim that the file system needs to be unmounted while the LUN is being resized (migrated and resized in our case).
I understand that ext3 doesn't support online expansion (not in RedHat ES/AS at least), however, does it really matter what you're doing to the actual LUN in the background (as long as you're not reducing the LUN size)? The operating system won't know the partitioning changed until you tell it to reread the partition table.
Not following EMC/NetApp 'overcautious' instructions could save a tremendous amount of time during a LUN migration (instead of waiting for a LUN to migrate while the file system is online, the only wait you really sustain is how fast you type and re-partition)
I have just tried this with ext3 file system online, and it worked like I expected it to work.
EMC specifically states in the emc122304 (from their knowledge base):
" Step 3: Increase the size of the LUN using the backend array tools. In some cases, like with CLARiiON MetaLUN, this can actually be performed "online" in order to decrease the time that the file system is unavailable. However, just because the disk array can be done online that does not mean the application layer can handle online expansion (some file systems can handle online expansion, currently ext3 cannot)."
Yeah, file system can't expand.. but I am resizing the file system offline, why can't I resize the LUN online?
Am I missing something?
Below are my results.. I tried doing IO while migrating (and resizing) the LUN, but I think IO seized before migration was complete. Also, the majority of LUNs that usually need resizing are near capacity, mine obviously wasn't
B4 migration/growth
[root@ad-nfs1 kerberos]# df -k
/dev/emcpowerc1 20642412 5030932 14562908 26% /emc1
--after growth while the system was online
fdisk /dev/emcpowerc
Disk /dev/emcpowerc: 21.4 GB, 21474836480 bytes
64 heads, 32 sectors/track, 20480 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux
Command (m for help): q
[root@ad-nfs1 kerberos]# sfdisk -R /dev/emcpowerc
[root@ad-nfs1 kerberos]# fdisk /dev/emcpowerc
The number of cylinders for this disk is set to 30720. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux
[root@ad-nfs1 kerberos]# fdisk /dev/emcpowerc
The number of cylinders for this disk is set to 30720. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux
Command (m for help): d
Selected partition 1
Command (m for help): p
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
Command (m for help): n
Command action
e extended
p primary partition (1-4)
1
Invalid partition number for type `1'
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-30720, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-30720, default 30720):
Using default value 30720
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@ad-nfs1 kerberos]# fdisk -l /dev/emcpowerc
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       30720    31457264   83  Linux
-- notice, w/o fsck it'll not resize.. w/o -f option
[root@ad-nfs1 kerberos]# time fsck -f /dev/emcpowerc1
fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/emcpowerc1: 254481/2621440 files (0.8% non-contiguous), 1410133/5242876 blocks
real    1m4.984s
user    0m1.348s
sys     0m1.617s
[root@ad-nfs1 kerberos]# resize2fs /dev/emcpowerc1 resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/emcpowerc1 to 7864316 (4k) blocks. The filesystem on /dev/emcpowerc1 is now 7864316 blocks long.
[root@ad-nfs1 kerberos]# mount /dev/emcpowerc1 /emc1/ [root@ad-nfs1 kerberos]# df -k|grep emc
/dev/emcpowerc1 30963692 5311440 24393964 18% /emc1
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Andrey Dmitriev

author

2006-05-25 17:27 UTC #2 lore raw

A production (database) system needs it's LUNs resized. It doesn't run LVM, nor am I not sure if we want to add another layer.

We could've probably used reiserfs or vxfs if we thought about resizing in advance.

Anyway, my point was more about why does EMC and NetApp (and even Veritas) ask to unmount the file system prior to resizing the LUN (or volume in Veritas case). From my point of view, it doesn't make sense.. and I seem to have succeeded in doing what I wanted to do (resizing the LUN while file system is mounted, followed by quickly unmounting, fsck'ing, resizing, mounting). Am I missing something?

Thanks,
Andrey

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Limin Wang
Sent: Thursday, May 25, 2006 1:40 AM
To: [email protected]
Subject: Re: resizing LUN (not file system) while the file system (ext3) is online

Try with LVM, resize can be done online, without disrupting user service.

Regards,
Limin

Quoted 6 lines · Andrey Dmitriev

Dear List,
Both EMC and NetApp claim that the file system needs to be unmounted while the LUN is being resized (migrated and resized in our case).
I understand that ext3 doesn't support online expansion (not in RedHat

ES/AS

Quoted 6 lines

at least), however, does it really matter what you're doing to the actual LUN in the background (as long as you're not reducing the LUN size)? The operating system won't know the partitioning changed until you tell it to reread the partition table.
Not following EMC/NetApp 'overcautious' instructions could save a

tremendous

Quoted 2 lines

amount of time during a LUN migration (instead of waiting for a LUN to migrate while the file system is online, the only wait you really sustain

Quoted 9 lines

how fast you type and re-partition)
I have just tried this with ext3 file system online, and it worked like I expected it to work.
EMC specifically states in the emc122304 (from their knowledge base):
" Step 3: Increase the size of the LUN using the backend array tools. In some cases, like with CLARiiON MetaLUN, this can actually be performed "online" in order to decrease the time that the file system is

unavailable.

Quoted 5 lines

However, just because the disk array can be done online that does not mean the application layer can handle online expansion (some file systems can handle online expansion, currently ext3 cannot)."
Yeah, file system can't expand.. but I am resizing the file system

offline,

Quoted 6 lines

why can't I resize the LUN online?
Am I missing something?
Below are my results.. I tried doing IO while migrating (and resizing) the LUN, but I think IO seized before migration was complete. Also, the

majority

Quoted 1 line

of LUNs that usually need resizing are near capacity, mine obviously

wasn't

Quoted 100 lines

B4 migration/growth
[root@ad-nfs1 kerberos]# df -k
/dev/emcpowerc1 20642412 5030932 14562908 26% /emc1
--after growth while the system was online
fdisk /dev/emcpowerc
Disk /dev/emcpowerc: 21.4 GB, 21474836480 bytes
64 heads, 32 sectors/track, 20480 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux
Command (m for help): q
[root@ad-nfs1 kerberos]# sfdisk -R /dev/emcpowerc
[root@ad-nfs1 kerberos]# fdisk /dev/emcpowerc
The number of cylinders for this disk is set to 30720. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux
[root@ad-nfs1 kerberos]# fdisk /dev/emcpowerc
The number of cylinders for this disk is set to 30720. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help): p
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       20480    20971504   83  Linux
Command (m for help): d
Selected partition 1
Command (m for help): p
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
Device Boot Start End Blocks Id System
Command (m for help): n
Command action
e extended
p primary partition (1-4)
1
Invalid partition number for type `1'
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-30720, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-30720, default 30720):
Using default value 30720
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@ad-nfs1 kerberos]# fdisk -l /dev/emcpowerc
Disk /dev/emcpowerc: 32.2 GB, 32212254720 bytes
64 heads, 32 sectors/track, 30720 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes
         Device Boot      Start         End      Blocks   Id  System
/dev/emcpowerc1               1       30720    31457264   83  Linux
-- notice, w/o fsck it'll not resize.. w/o -f option

Quoted 9 lines

[root@ad-nfs1 kerberos]# time fsck -f /dev/emcpowerc1 fsck 1.35 (28-Feb-2004)
e2fsck 1.35 (28-Feb-2004)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information /dev/emcpowerc1: 254481/2621440 files (0.8% non-contiguous),

1410133/5242876

Quoted 21 lines

blocks
real    1m4.984s
user    0m1.348s
sys     0m1.617s
[root@ad-nfs1 kerberos]# resize2fs /dev/emcpowerc1 resize2fs 1.35 (28-Feb-2004)
Resizing the filesystem on /dev/emcpowerc1 to 7864316 (4k) blocks. The filesystem on /dev/emcpowerc1 is now 7864316 blocks long.
[root@ad-nfs1 kerberos]# mount /dev/emcpowerc1 /emc1/ [root@ad-nfs1 kerberos]# df -k|grep emc
/dev/emcpowerc1 30963692 5311440 24393964 18% /emc1
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Stephen C. Tweedie

2006-05-25 11:45 UTC #3 lore raw

In reply to Andrey Dmitriev

Hi,

Quoted 2 lines · Andrey Dmitriev

I understand that ext3 doesn't support online expansion (not in RedHat ES/AS at least)

Yes it does, and it should work fine in RHEL-4, or FC-3 or later. Ted just integrated the online resize user-space tools into upstream e2fsprogs a couple of months ago, and only this week he turned on the resize inode feature in mke2fs by default.

Quoted 3 lines

However, just because the disk array can be done online that does not mean the application layer can handle online expansion (some file systems can handle online expansion, currently ext3 cannot)."

Out-of-date information. :-)

Cheers,
Stephen