Currently, Sakura's VPS is Sakura's VPS 100,000 breakthrough commemoration "Storage change option free Campaign is being held (until August 31, 2021). "Storage change option" that doubles the storage capacity by applying at the same time as scale-up. Normally, it costs extra, but this is a generous project that will be free for a limited time! So, when I checked all 4 Sakura VPSs that I had a contract with, there was one that had used up enough storage, so I applied this "storage change option" to it. Saw. The details at that time are described here as a memorandum.
Server information before applying the scale-up and storage change options.
| item name | value |
|---|---|
| Sakura's VPS version | v4 |
| plan | 512MB |
| storage | SSD 25GB |
This server is a VPN server used to connect to your home network from outside your home. Upon examination, it seems that the log files were very large & large, which was squeezing the storage. As I will explain later, I was surprised to see the remaining 135MB.
I stopped the server and scaled it up. The server information after scale-up is as follows.
| item name | value |
|---|---|
| Sakura's VPS version | v5 |
| plan | 1GB |
| storage | SSD 50GB→100GB |
The version has increased from v4 to v5. Also, the memory capacity is doubled. Storage has doubled, and the storage change option has doubled, for a total of four times.
Let's take a look at the server information after a little scale-up.
[root@vpn01 ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root@vpn01 ~]# free -h
total used free shared buff/cache available
Mem: 991M 220M 293M 6.7M 476M 604M
Swap: 4.0G 0B 4.0G
[root@vpn01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda4 16G 16G 135M 100% /
devtmpfs 486M 0 486M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.7M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/vda2 497M 271M 226M 55% /boot
tmpfs 100M 0 100M 0% /run/user/1000
The memory is properly recognized as about 1GB (991MB to be exact?). However, only about 16GB of storage is recognized. As mentioned earlier, I increased it to a maximum of 100GB ...
Expand disk capacity with Sakura's VPS (CentOS7) --Qiita @ mighty-n
sudo su - to elevate the authority before starting work.[root@vpn01 ~]# fdisk /dev/vda
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help): p
Disk /dev/vda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/vda1 1 41943039 20971519+ ee GPT
Command (m for help): q
[root@vpn01 ~]# yum -y install cloud-utils-growpart gdisk
(Omitted)
Installed:
cloud-utils-growpart.noarch 0:0.29-5.el7 gdisk.x86_64 0:0.8.10-3.el7
Complete!
[root@vpn01 ~]# growpart /dev/vda 4
CHANGED: partition=4 start=9416704 old: size=32526303 end=41943007 new: size=200298462 end=209715166
[root@vpn01 ~]# fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
Disk /dev/vda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 24E50A8F-EB81-4573-9F30-1084D97EBBC2
# Start End Size Type Name
1 2048 4095 1M BIOS boot BIOS boot partition
2 4096 1028095 500M Microsoft basic Microsoft basic data
3 1028096 9416703 4G Linux swap Linux swap
4 9416704 209715165 95.5G Microsoft basic Microsoft basic data
resize2fs?So it seemed that / dev/sda4 could be increased to 95.5GB, but it's not.
[root@vpn01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda4 16G 16G 135M 100% /
devtmpfs 486M 0 486M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.7M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/vda2 497M 271M 226M 55% /boot
tmpfs 100M 0 100M 0% /run/user/1000
It hasn't changed on the file system yet. So I will put in the continuation of the previous command.
[root@vpn01 ~]# resize2fs /dev/vda4
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/vda4
Couldn't find valid filesystem superblock.
Bad magic number …
Couldn't find valid filesystem superblock …
For this, Hana [^ 1] must also say "Mechok!" [^ 2].
[^ 1]: HUG! Hanano Nono, the main character of Pretty Cure [^ 2]: Abbreviation for "very shock". Hana herself explains in episode 4
xfs_growfs appearsSo I will borrow the wisdom of another ancestor.
What I was addicted to with LVM disk expansion on CentOS 7 (XFS) --Qiita @fetaro
[root@vpn01 ~]# xfs_growfs /dev/vda4
meta-data=/dev/vda4 isize=256 agcount=18, agsize=230015 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0 spinodes=0
data = bsize=4096 blocks=4065787, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
data blocks changed from 4065787 to 25037307
[root@vpn01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda4 96G 16G 81G 17% /
devtmpfs 486M 0 486M 0% /dev
tmpfs 496M 0 496M 0% /dev/shm
tmpfs 496M 6.7M 489M 2% /run
tmpfs 496M 0 496M 0% /sys/fs/cgroup
/dev/vda2 497M 271M 226M 55% /boot
tmpfs 100M 0 100M 0% /run/user/1000
This increased / dev/vda4 from 16GB to 81GB and reduced usage from 100% to 17%.
Hikaru [^ 3] will see this and will surely say "Kira Yaba ☆".
[^ 3]: Hikaru Sena, the main character of Star Twinkle PreCure
Recommended Posts