Have a box that is running SuSE11sp3. It runs are GroupWise 2012 system. One ext3 partition. It is a virtual VMWare server as well. Current size is 450GB. There is space in the datastore to double the size of the partition. I can go in the vsphere client and allocate the space to the disk, but not sure correct method for expanding the ext3 partition to see it as well without losing all the data on the disk. Looking for the best way of expanding the disk to see the new space.
On 25/06/2014 18:14, jlewter wrote:
[color=blue]
Have a box that is running SuSE11sp3. It runs are GroupWise 2012 system.
One ext3 partition. It is a virtual VMWare server as well. Current size
is 450GB. There is space in the datastore to double the size of the
partition. I can go in the vsphere client and allocate the space to the
disk, but not sure correct method for expanding the ext3 partition to
see it as well without losing all the data on the disk. Looking for the
best way of expanding the disk to see the new space.[/color]
HTH.
Simon
SUSE Knowledge Partner
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below. Thanks.
Hi jlewter,
first things first: Backup your data. Then… make sure your data is backed up. And verify you’ll be able to use that backup if things fail 
How familiar are you with system-level tools? Technically speaking, from your description you’ll be extending the (virtual) disk.
I’m assuming that your ext3 partition is the last (or only) partition on that disk - if you have a separate boot partition that comes after the data partition, things are more complicated or will take more time.
Variant 1: Reboot using some “gparted”-ready ISO, so that you can use such a repartitioning tool to either expand the existing partition to the new end of the disk or (in case it isn’t the last partition on the disk) to move the following partitions to the end of the disk and expand the data partition to use the then free space.
(There’s a “variant 2”, but the disclaimers were more text than the actual description - so I decided to drop that part of my reply 
)
Either way, you now have a larger partition which is partially used by the Ext3 file system - all you need to do now is to resize the FS using resize2fs. It can automatically detect the size of the underlying device (“partition” in this case) and will extend the FS accordingly.
Once this is done, reboot your server and enjoy the free space.
This all being said, I usually strongly recommend to sub-divide your single file system into different file systems. Especially application data should go into its own file system, so that when you want to (or are forced to) rebuild some system’s FS, your data FS will not be affected. Or if some logging (to /var/log/*) goes into overdrive and floods that FS, other more important FS (like “root”, application data, /var in general) aren’t influenced and your server remains manageable.
Another thing to consider is switching to LVM - instead of partitions, you’ll use “logical volumes” that don’t rely on contiguous disk space. All “physical” space is considered to be a pool, and as long as your pool has sufficient free space, you can add that at your will to your logical volumes. If you run out of free pool space, you can simply add more physical space - in your case, you’d not extend the original disk, but add an additional disk to the VM, then add it to the pool, and voila, you have free space again to add to your logical volumes. LVM makes dynamic management of file system sizes much more easier AND EXTENSION CAN BE DONE ONLINE!
Regards,
Jens
Oh boy - what they’re recommending in that VMware KB article was my variant 2. So much can go wrong with that and I believe that newer style machines have variants not covered by that truly short description in “step 3”, I would only recommend that to those sufficiently experienced.
As well, that article doesn’t properly cover the situation when you’re handling your only ext3 partition - which would be the live, mounted os root FS in the OP’s situation.
BTW, since when does “swapoff” remove the swap partition? To my knowledge, it only deactivates its usage, so that article is missing the steps to first remove that swap partition, as well as re-adding it afterward? “Step 6” gives steps to “recreate the swap partition”, but again, it relies on having the swap partition already defined in the partition table (and as such does not need an additional reboot, unlike indicated) and only names commands to “format” and activate that partition.
In addition, it seems to be an older article - with SLES11SP3, there’s no need for ext2online (is it even available nowadays?), resize2fs can be used to resize life file systems, too.
Regards,
Jens
First off, I saw the vmware knowledgebase article. Not sure if that pertains or not to what I need to do. Basically the server has two disks assigned to it. One disk holds the os, /boot, /swap and /. Second disk is partition as mount point /mail in ext3. Last night I allocated the extra space in the datastore to the disk and rebooted the box. Now, when I login to the box and use yast-partitioner, I can see the extra space, so my thought is that I can just unmount the /mail partition and just resize it there in partitioner? Believe me I understand backup, backup and more backups, but I can’t see why I can’t just do it that way? I have never done this before so first time for me and when I google it, there are tons of articles on different ways of doing it, so I guess looking for best, my advise way of doing it.
Hi jlewter,
Well - from your more detailed description, I’d say you can do it that way 
And yes, that’ll be the easiest way and quick, too. Since it’s a second drive, you’ll probably even get away without additional reboots, since the kernel will be notified by fdisk, to re-read the partition table. Since it’s the only partition on that disk, and that disk is currently unused (FS unmounted, nothing else mounted/used from that disk), the kernel will refresh the information and you’re set.
The only (forum) problem is that it isn’t easy to judge the knowledge of the people involved, some need detailed step by step descriptions (and will not notice when things are going in the wrong direction) and others only need a hint and have a “feeling” for the limits of an approach. Fiddling with the partition table in the way described in the article looks to work fine for your case, but as I pointed out in my response to smflood, already expects some background knowledge for even minor deviations. Changing the partition table in the wrong way will wreck data, thus I’m trying to be careful when giving advice in that direction
With regards,
Jens
I would recommend not to use YaST partitioner in this specific case - all you need is the “delete partition, create partition” functionality and I don’t trust “wrappers” to do just that, rather than trying to be more intelligent than the user Me personally, I’d stick to “fdisk”. OTOH, I’ve been using fdisk for decades, so maybe I’m simply to old-school
Regards,
Jens
Sorry, my bad I should have given more info up front. So your saying not to use yast-partitioner but use fdisk to expand the partition? I am not familiar with fdisk use so I will have to dig around to find the command syntax for it use in this situation.
Hi jlewter,
it’s simply that I’m not sure what else is happening behind the scenes when you do that operation with YaST - it is at least capable of creating a new file system etc and maybe you’ll have to watch out that it does not do that etc.
Using fdisk is fairly simple in this case: start it via “fdisk /dev/devicenameOfDisk”. “m” lists all available commands, “p” lists the current partition table, “v” does some checks of the current setup, “n” creates a new partition, “q” will quit and “w” will write the current config to disk.
So what would seem like a good sequence:
- “p” to see the current partition layout (you should only see a single partition there)
- “v” should tell you about plenty of unallocated sectors
- “d” would delete that single partition
- “n” (plus follow-up values, all default I guess) should create a new partition spanning (mostly) the whole disk
- “p” should show a single partition of the same type and starting point as from step 2, and a much higher end point/size
- “v” should report close to no unallocated sectors
7a. if unsure at this point, “q” to quit.
7b. If you feel safe, use “w” to write to disk. fdisk will quit and tell you that the kernel is reloading the partition table. - Re-run fdisk to use “p” verify everything is as you assume. If you received a message that the partition table could not be reloaded, you’ll have to reboot before the next step.
- “resize2fs /dev/yourPartition”
- mount & enjoy
Standard disclaimer applies: Use this at your own risk and always apply logic to my instructions (never trust me )
Regards,
Jens