Have to say, these days I should be more careful when I dealt with any problem.
I have extended many partitions in the past, including the real environment or in my VMs. And I also know this is a very dangerous action, so for every step, need to know what I am doing and the possible result.
I know this, but this is not enough!
Today I wanted to enlarge a partition in an AWS EC2 instance. I could create a new partition but in that way I have to do more extra actions when I manage the data files in the future, so I prefer to extend the existing partition.
OK, did a check first:
- [root@oradump ~]# fdisk -l
- WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
- Disk /dev/xvda: 10.7 GB, 10737418240 bytes, 20971520 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
- # Start End Size Type Name
- 1 2048 4095 1M BIOS boot parti
- 2 4096 20971486 10G Microsoft basic
- Disk /dev/xvdf: 1073.7 GB, 1073741824000 bytes, 2097152000 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/xvdf1 1 1048575999 524287999+ ee GPT
I recalled parted could resize partition directly so I searched and found there should be 'resize' or 'resizepart' subcommands, but I could not find them in the system (RHEL7.3), so just one way left to me: deleting the current partition, and creating a new partition with the same start point. I read some webpages and knew I should use 'unit s' to get the actual sector for every partition, and did it as below:
- (parted) select /dev/xvdf
- Using /dev/xvdf
- (parted) print
- Error: The backup GPT table is not at the end of the disk, as it should be. This might mean that another operating system believes the disk is smaller. Fix, by moving the
- backup to the end (and removing the old backup)?
- Fix/Ignore/Cancel? Fix
- Warning: Not all of the space available to /dev/xvdf appears to be used, you can fix the GPT to use all of the space (an extra 1048576000 blocks) or continue with the current
- setting?
- Fix/Ignore? Fix
- Model: Xen Virtual Block Device (xvd)
- Disk /dev/xvdf: 1074GB
- Sector size (logical/physical): 512B/512B
- Partition Table: gpt
- Disk Flags:
- Number Start End Size File system Name Flags
- 1 1049kB 2097kB 1049kB bios_grub
- 2 2097kB 537GB 537GB xfs
- (parted) unit s
- (parted) p
- Model: Xen Virtual Block Device (xvd)
- Disk /dev/xvdf: 2097152000s
- Sector size (logical/physical): 512B/512B
- Partition Table: gpt
- Disk Flags:
- Number Start End Size File system Name Flags
- 1 2048s 4095s 2048s bios_grub
- 2 4096s 1048575966s 1048571871s xfs
- (parted) rm 2
- (parted) mkpart primary xfs 4096s 2097152000s
- Error: The location 2097152000s is outside of the device /dev/xvdf.
- (parted) mkpart primary xfs 4096s 2097151999s
- Warning: You requested a partition from 4096s to 2097151999s (sectors 4096..2097151999).
- The closest location we can manage is 4096s to 2097151966s (sectors 4096..2097151966).
- Is this still acceptable to you?
- Yes/No? Yes
- (parted) p
- Model: Xen Virtual Block Device (xvd)
- Disk /dev/xvdf: 2097152000s
- Sector size (logical/physical): 512B/512B
- Partition Table: gpt
- Disk Flags:
- Number Start End Size File system Name Flags
- 1 2048s 4095s 2048s bios_grub
- 2 4096s 2097151966s 2097147871s xfs primary
- (parted) quit
- Information: You may need to update /etc/fstab.
Tried to mount it:
- [root@oradump ~]# mount /dev/xvdf2 /oracle
- mount: wrong fs type, bad option, bad superblock on /dev/xvdf2,
- missing codepage or helper program, or other error
- In some cases useful info is found in syslog - try
- dmesg | tail or so.
- [root@oradump ~]# mount -t xfs /dev/xvdf2 /oracle
- mount: wrong fs type, bad option, bad superblock on /dev/xvdf2,
- missing codepage or helper program, or other error
- In some cases useful info is found in syslog - try
- dmesg | tail or so.
I guessed maybe something wrong. The partition name was /dev/xvdf1, but at that time it became /dev/xvdf2!
I run 'fdisk -l', and it did become /dev/xvdf2.
And I tried the following things in a short time:
- changed the partition type to 'Linux Filesystem'
- removed both partitions and created a new one large partition
- tried to adjust the start sector to 34
All of them failed to mount the filesystem, so I did lose my mind. I just did one thing right -- in such situation, never write any data on it.
I know I can change the partition many times as the partition information will not destroy the filesystem, which is stored at the beginning of the hard disk, and some in the end of the partition.
Why not checked the message file? Usually when I lose my mind, I will not do any change on the system, and just check the log files.
This time, the message file save me again!
- Apr 24 07:01:01 oradump systemd: Stopping user-0.slice.
- Apr 24 07:01:27 oradump kernel: xvdf: xvdf1 xvdf2
- Apr 24 07:02:15 oradump kernel: XFS (xvdf2): Filesystem has duplicate UUID 3ed41454-00c8-4803-bf61-2ee88aa54dbf - can't mount
- Apr 24 07:03:02 oradump kernel: XFS (xvdf2): Filesystem has duplicate UUID 3ed41454-00c8-4803-bf61-2ee88aa54dbf - can't mount
- Apr 24 07:04:43 oradump kernel: xvdf: xvdf1 xvdf2
- Apr 24 07:04:49 oradump kernel: xvdf: xvdf1 xvdf2
- Apr 24 07:04:54 oradump kernel: XFS (xvdf2): Filesystem has duplicate UUID 3ed41454-00c8-4803-bf61-2ee88aa54dbf - can't mount
- Apr 24 07:08:30 oradump kernel: xvdf: xvdf1 xvdf2
So it seems I could not mount it just because the UUID was duplicated, right? Google helped me many many times!
XFS Filesystem has duplicate UUID problem
My Putty kept long history so I restored the partitions to the initial layout, and tried the nouuid option:
- [root@oradump log]# mount -o nouuid -t xfs /dev/xvdf2 /oracle
- [root@oradump log]# df -h
- Filesystem Size Used Avail Use% Mounted on
- /dev/xvda2 10G 2.7G 7.4G 27% /
- devtmpfs 1.9G 0 1.9G 0% /dev
- tmpfs 1.8G 5.4M 1.8G 1% /dev/shm
- tmpfs 1.8G 73M 1.7G 5% /run
- tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup
- tmpfs 354M 0 354M 0% /run/user/1002
- /dev/xvdf2 500G 500G 140M 100% /oracle
- [root@oradump log]# ls /oracle
- 11gr2 base dmp_files install new_7z oraInventory source swapfile
So I got my files back finally!
- [root@oradump log]# umount /oracle
- [root@oradump log]# xfs_admin -U generate /dev/xvdf2
- Clearing log and setting UUID
- writing all SBs
- new UUID = 1a0a2a4c-7791-41f9-b3d9-3cb357ff05a9
- [root@oradump log]# mount -t xfs /dev/xvdf2 /oracle
- [root@oradump log]# xfs_growfs /oracle
- meta-data=/dev/xvdf2 isize=512 agcount=334, agsize=393216 blks
- = sectsz=512 attr=2, projid32bit=1
- = crc=1 finobt=0 spinodes=0
- data = bsize=4096 blocks=131071483, imaxpct=25
- = sunit=0 swidth=0 blks
- naming =version 2 bsize=4096 ascii-ci=0 ftype=1
- 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 131071483 to 262143483
- [root@oradump log]# df -h
- Filesystem Size Used Avail Use% Mounted on
- /dev/xvda2 10G 2.7G 7.4G 27% /
- devtmpfs 1.9G 0 1.9G 0% /dev
- tmpfs 1.8G 5.4M 1.8G 1% /dev/shm
- tmpfs 1.8G 73M 1.7G 5% /run
- tmpfs 1.8G 0 1.8G 0% /sys/fs/cgroup
- tmpfs 354M 0 354M 0% /run/user/1002
- /dev/xvdf2 1000G 500G 501G 50% /oracle
One issue left for me: how to quit parted without saving?
And more important, I should backup the partition table first!
