Unsolved Question about fdisk
-
I have an old CentOS 7 system that I need to expand the disk for.
I resized the virtual disk in Hyper-V with no issue, but I'm confused/worried about using fdisk like normal to resize the partition because of this warning.
As you can see, the disk is aligned to sector 1. Can I safely use fdisk? I cannot recall ever dealing with this before.
-
That's a scary warning, but I've never had it be an issue in the past. But as always, fdisk is a bit scary.
-
@scottalanmiller said in Question about fdisk:
That's a scary warning, but I've never had it be an issue in the past. But as always, fdisk is a bit scary.
I've done the delete and recreate larger many, many times. I have no fear of failure with that process under normal conditions.
I've just never had fdisk tell me that before.
I did go through and delete then recreate. It put the partition starting boundary on 2048 as I would expect.
I quit without writing the changes though, in order to post this.
-
I do not know if this is sensible or not. Maybe you want to back that section before working on it. That way if anything goes bad you can recreate it again with the back up.
-
Does gdisk present the same warning?
-
@JaredBusch said in Question about fdisk:
I have an old CentOS 7 system that I need to expand the disk for.
I resized the virtual disk in Hyper-V with no issue, but I'm confused/worried about using fdisk like normal to resize the partition because of this warning.
As you can see, the disk is aligned to sector 1. Can I safely use fdisk? I cannot recall ever dealing with this before.
You're running a virtual disk under Hyper-V so physical sectors has no bearing at all. And especially not when you have thin partioning (dynamic size) in the hypervisor.
It used to be a thing because DOS had MBR in the first sector (sector 0) so that why GPT partitioning reserves it. And you wanted to align partitions with physical disk sectors on spinning rust to avoid write penalties.
Anyway, even on bare metal with SSD it doesn't matter because SSDs support both 512 and 4096 sector size and have internally a different block size altogether. And on spinners you have much larger cache on the drives and raid cache as well so it more or less doesn't really matter anymore.
But if you just create a new partition today it will align it automatically to 1MB (2048x512 byte) so you don't have to think about it.
-
@Pete-S said in Question about fdisk:
You're running a virtual disk under Hyper-V so physical sectors has no bearing at all.
Of course they matter, because the guest OS doesn't know or care that it is virtual.
-
@JaredBusch said in Question about fdisk:
Can I safely use fdisk? I
As expected, deleting and creating the partition again left the system dead.
Restoring backup. Will see if that does anything with the issue of booting the VM to a DVD or not (do not expect it to).
Then I will probably recreate the VM with a new disk and restore the files from the Veeam backup instead of restore the entire VM. Way more work than I want to do just to expand this old Nextcloud instance a little.
Problem: the LVM is full. I want to expand the LVM, but first, the partition needs to see the new space. pretty basic.
Once the disk is expanded, and the user's desktop nextcloud clients can get fully synchronized again, I'll be migrating the entire thing to a new VM. But I want full clean sync first.
Additionally, because this is on CentOS 7, I cannot (easily) continue to upgrade Nextcloud. I've been meaning to deal with this side of it for a while, but it has been a low priority. I'm stuck on 20.0.14 because of MariaDB version or something.
-
@JaredBusch said in Question about fdisk:
@Pete-S said in Question about fdisk:
You're running a virtual disk under Hyper-V so physical sectors has no bearing at all.
Of course they matter, because the guest OS doesn't know or care that it is virtual.
Oh, so you thought partition alignment is about the OS? It's not. The OS doesn't care (and never has) about partition alignment - regardless if it runs in a VM or on bare metal.
Partition alignment is only about optimizing the performance of the storage subsystem.
-
@Pete-S said in Question about fdisk:
@JaredBusch said in Question about fdisk:
@Pete-S said in Question about fdisk:
You're running a virtual disk under Hyper-V so physical sectors has no bearing at all.
Of course they matter, because the guest OS doesn't know or care that it is virtual.
Oh, so you thought partition alignment is about the OS?
Where did I say that? Are you implying I thought it mattered to the guest OS, because I used that term? This entire post is about
fdiskandfdiskruns inside the CentOS 7 operation system in this case. That version offdiskcomplains about the partition alignment as soon as you run it. It also refuses to allow you to specify sector 1 if you want to resize the partition. Thus within the OS that I am able to manage the partition from, I am unable to usefdiskas needed.Partition alignment is only about optimizing the performance of the storage subsystem.
I know what partition alignment is actually about.
I know you seem all hot and bothered to prove me wrong about something but give it up.
-
@JaredBusch said in Question about fdisk:
I know you seem all hot and bothered to prove me wrong about something but give it up.
No, not at all. I was just trying to add some context to why partition alignment makes no practical difference in this and many other cases and that warnings can be disregarded.
I would consider it a bug that
fdiskcouldn't resize your partition the way it was setup. -
So raw partitions with no LVM? Sad geek.
Is parted available in CentOS7? It's been so long I forget, but parted tends to act better if you are able to use it.
-
@travisdh1 said in Question about fdisk:
So raw partitions with no LVM? Sad geek.
Is parted available in CentOS7? It's been so long I forget, but parted tends to act better if you are able to use it.
If I remember correctly, it is.
-
@scottalanmiller said in Question about fdisk:
@travisdh1 said in Question about fdisk:
So raw partitions with no LVM? Sad geek.
Is parted available in CentOS7? It's been so long I forget, but parted tends to act better if you are able to use it.
If I remember correctly, it is.
Yes, by default. No idea how he went with that assumption.
The disk is bigger.
But it is not visible yet.
Normally, you simply use
fdiskto delete the partition and recreate it, then LVM and such see the space. But I cannot do that because of the above. -
@JaredBusch said in Question about fdisk:
@scottalanmiller said in Question about fdisk:
@travisdh1 said in Question about fdisk:
So raw partitions with no LVM? Sad geek.
Is parted available in CentOS7? It's been so long I forget, but parted tends to act better if you are able to use it.
If I remember correctly, it is.
Yes, by default. No idea how he went with that assumption.
The disk is bigger.
But it is not visible yet.
Normally, you simply use
fdiskto delete the partition and recreate it, then LVM and such see the space. But I cannot do that because of the above.That would not be normal at all when using LVM. fdisk/parted shouldn't need to be used.
pvresize /dev/pathtopv
lvextend -r -l +95%FREE /dev/pathtolv(pick you're preferred percentage, I like to leave room for temporary snapshots)The final step depends on the filesystem in use.
XFSxfs_growfs /mount/point
EXT4resize2fs /mount/pointThe deleting and recreating the partition bit is only needed when directly on the physical hardware. Since you resized the virtual partition, just skip that.
-
-
@JaredBusch said in Question about fdisk:
@travisdh1 said in Question about fdisk:
pvresize /dev/pathtopv
Looks like I was forgetting a few steps. Try https://samsig.dk/extending-gpt-lvm-disk-on-centos/ (It doesn't have you delete/create the partition).
-
@travisdh1 said in Question about fdisk:
(It doesn't have you delete/create the partition).
No, but it tells you to use tools to deal with the "physical" partition same as simply using
fdiskto delete and create. Speficiallypartedorgdisk, and those tools don't like what they see either. -
As an update to this, the issue is not resolved, but I purged a couple old nextcloud user accounts, that once deleted, and got enough space to get the needed users fully sync'd again.
I'll be spinning up a new Nextcloud instance and simply manually migrating users to it I think.
