Disk expansion - CentOS
-
So it looks like the default installer doesn't default to LVM. I'm running another install now to see if advanced options allows me to do it.
-
So choosing advanced install, and choosing to use the entire disk, then uses LVM and chooses the following layout:
[root@localhost ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 40G 0 disk ├─sda1 8:1 0 500M 0 part /boot └─sda2 8:2 0 39.5G 0 part ├─VolGroup-lv_root (dm-0) 253:0 0 37.6G 0 lvm / └─VolGroup-lv_swap (dm-1) 253:1 0 2G 0 lvm [SWAP] sr0 11:0 1 1024M 0 rom
-
@fuznutz04 Much better.
-
@scottalanmiller said in Disk expansion - CentOS:
@fuznutz04 Much better.
That's crazy. I've even used a VPS provider that specializes in FPBX hosting, and their default partitioning scheme (which you cannot change, it is done automatically) is this:
lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom vda 252:0 0 60G 0 disk ├─vda1 252:1 0 59G 0 part / └─vda2 252:2 0 1G 0 part [SWAP]
-
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
@fuznutz04 Much better.
That's crazy. I've even used a VPS provider that specializes in FPBX hosting, and their default partitioning scheme (which you cannot change, it is done automatically) is this:
"Specialize" might be a strong term there.
-
So playing with the advanced options some more, I can customize this exactly how I need. Default on the advanced installer is setup like the following:
Are you suggesting to customize it further, removing the lv_swap?
-
Swap on LVM is fine. Ext4 is fine. FreePBX basically does nothing with storage, so fine tuning it is not very practical, beyond having LVM of course. That's not fine tuning, that's just basic good installation.
-
@scottalanmiller said in Disk expansion - CentOS:
Swap on LVM is fine. Ext4 is fine. FreePBX basically does nothing with storage, so fine tuning it is not very practical, beyond having LVM of course. That's not fine tuning, that's just basic good installation.
But what about other workloads? Would you still recommend the same if it was lets say, a wordpress box using Mariadb, or any other similar workload?
-
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
Swap on LVM is fine. Ext4 is fine. FreePBX basically does nothing with storage, so fine tuning it is not very practical, beyond having LVM of course. That's not fine tuning, that's just basic good installation.
But what about other workloads? Would you still recommend the same if it was lets say, a wordpress box using Mariadb, or any other similar workload?
No, partially because they are not static in the same way, they depend on disk performance. FreePBX does not. Also, your FreePBX is on a version about to be replaced with one that is vastly updated. So lots of tuning for things like the filesystem that are already addressed in the upcoming release doesn't seem fruitful.
-
@scottalanmiller said in Disk expansion - CentOS:
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
Swap on LVM is fine. Ext4 is fine. FreePBX basically does nothing with storage, so fine tuning it is not very practical, beyond having LVM of course. That's not fine tuning, that's just basic good installation.
But what about other workloads? Would you still recommend the same if it was lets say, a wordpress box using Mariadb, or any other similar workload?
No, partially because they are not static in the same way, they depend on disk performance. FreePBX does not. Also, your FreePBX is on a version about to be replaced with one that is vastly updated. So lots of tuning for things like the filesystem that are already addressed in the upcoming release doesn't seem fruitful.
Right. This next upgrade is HUGE!
-
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
Swap on LVM is fine. Ext4 is fine. FreePBX basically does nothing with storage, so fine tuning it is not very practical, beyond having LVM of course. That's not fine tuning, that's just basic good installation.
But what about other workloads? Would you still recommend the same if it was lets say, a wordpress box using Mariadb, or any other similar workload?
No, partially because they are not static in the same way, they depend on disk performance. FreePBX does not. Also, your FreePBX is on a version about to be replaced with one that is vastly updated. So lots of tuning for things like the filesystem that are already addressed in the upcoming release doesn't seem fruitful.
Right. This next upgrade is HUGE!
CentOS 7 base!
-
@scottalanmiller said in Disk expansion - CentOS:
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
@fuznutz04 said in Disk expansion - CentOS:
@scottalanmiller said in Disk expansion - CentOS:
Swap on LVM is fine. Ext4 is fine. FreePBX basically does nothing with storage, so fine tuning it is not very practical, beyond having LVM of course. That's not fine tuning, that's just basic good installation.
But what about other workloads? Would you still recommend the same if it was lets say, a wordpress box using Mariadb, or any other similar workload?
No, partially because they are not static in the same way, they depend on disk performance. FreePBX does not. Also, your FreePBX is on a version about to be replaced with one that is vastly updated. So lots of tuning for things like the filesystem that are already addressed in the upcoming release doesn't seem fruitful.
Right. This next upgrade is HUGE!
CentOS 7 base!
I know, plus new Freepbx version, new available asterisk version. BIG changes. I've been keeping tabs on the RC. They've had a ton of bugs so far because it is such a big change. I'm looking forward to getting my hands on it.
-
Can't wait to move to it in production.
-
@scottalanmiller said in Disk expansion - CentOS:
Can't wait to move to it in production.
I know. I didn't even bother installing it yet for testing. I'll wait for RC 2 for that.