I have a rhel 6.10 system, and I have a useless /dev/sdc disk, that I would like to add to /dev/sdb.
This system in virtual, running on vmware. There are 2 separate disks in the server config. I'd like to merge sdc into sdb.

fdisk -l:
Disk /dev/sdb: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000cd0a1

Device Boot Start End Blocks Id System
/dev/sdb1 1 6527 52428096 83 Linux

Disk /dev/sdc: 118.1 GB, 118111600640 bytes
255 heads, 63 sectors/track, 14359 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0004ea9e

Device Boot Start End Blocks Id System

I'm not sure the terminology that I should be using, so the answer is likely here, but I can't find it.

How would I go about doing this? Would it be best to delete sdc in vmware, then just add space to sdb?
Thanks! Let me know if you need more info, but I think I conveyed the basic gist, hopefully!

Most RHEL systems use LVM, so you would make /dev/sdc a PV, then add it to the volume group, then extend the logical volume onto the new space. See this thread:

https://www.linuxquestions.org/quest...ng-4175463294/

Presumably you're already using /dev/sdb1 as your root (/) filesystem mount and any files/subdirectories are part of that.

To expand that you'd have to do what you suggested, delete the underlying /dev/sdc then add its space to /dev/sdb then tell the OS to use see the resized sdb then expand sdb1 to use the new space sdb had.

Rather than go through all that you might consider using /dev/sdc (either with partitions or LVM) for separate filesystems then copy files from out of your existing subdirectories into those file systems. Me, I'd use LVM because of its flexibility.

Example:
That would add all of sdc to a new volume group named, vg01, then layout a new logical volume named, lvtmp, of 1024 extents on it using the new volume group.

You could then layout a filesystem on the new LV device, /dev/mapper/vg01-lvtmp, with mkfs. You could then mount that new device temporarily as /mnt, copy everything from /tmp into /mnt, mv /tmp to /tmp.old, mkdir /tmp to create empty mount point, unmount /mnt then mount /dev/mapper/vg01-lvtmp as /tmp. You would then remove tmp.old. You could do similar with other filesystems instead or in addition to /tmp. (e.g. /var, /home, /opt, /database). You would only have to create the VG before creating the first LV. Other LVs would be on the same VG.

Note that I used /tmp as an example. Often you can't remove it (or /tmp.old if you renamed it as noted above) because some process may be holding it or a file within it "open". However, on reboot it would know to use the new /tmp.

Ideally you would have used LVM on installation and put both disks into a single VG. The beauty of VGs is you can add/remove disks (PVs) and/or add/remove LVs without respect to other things that are already there. With partitioning you often end up having to resize earlier partitions to free up room for later ones. Since you are already apparently using a partition on sdb you'd have to blow that away to add it to the VG but there is no reason you can't have just a single disk like sdc in your VG.

Well, I think in this case, the admin for the software running on this server wants to keep it as physical volumes. Lucky me. So, how would I go about deleting the /dev/sdc, and then adding that space to /dev/sdb? I've done plently of VGs, but this is the first disk that is "physical", as much as a virtual server can be physical!

Ok, I figured it out. The drive in question was raw. I removed the mount point from fstab and rebooted.
I had previously increased the space of the drive and after the reboot, I deleted and recreated the partition and resized it.
Added the mount point back into fstab and another reboot, and things are good.

I was running into the issue of a umount -l deleting data.