6

Here is the disk, it is thin provisioned vmware disk, and has been grown from 300 to 800 GB

  *-disk:1
       description: SCSI Disk
       physical id: 0.1.0
       bus info: scsi@2:0.1.0
       logical name: /dev/sdb
       size: 800GiB (858GB)
       capabilities: partitioned partitioned:dos
       configuration: sectorsize=512 signature=4268053f

here is the

df -h
output

/dev/sdb1                             300G   27G  273G   9% /data

and it stays unchanged when I do this

[evn-mrs-slave]~> xfs_growfs -d /data
meta-data=/dev/sdb1              isize=256    agcount=4, agsize=19660736 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=78642944, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=38399, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data size unchanged, skipping
4
  • 2
    You must grow the partition before you can grow the filesystem. The filesystem is within the partition, and the partition is still 300GiB large, even though the disk is now 800GiB large.
    – Deltik
    Nov 13 '15 at 12:07
  • I think this qualifies as an answer rather than a comment.
    – Xavierjazz
    Nov 13 '15 at 16:29
  • can you show how to do that? Nov 15 '15 at 18:59
  • 2
    @Xavierjazz: I elaborated a little bit.
    – Deltik
    Nov 16 '15 at 21:21
7

You must grow the partition before you can grow the filesystem. The filesystem is within the partition, and the partition is still 300GiB large, even though the disk is now 800GiB large.

Resizing a Partition

Partitions can't be resized, but they can be deleted and then recreated. When a partition is deleted, the underlying data is still in tact. It's not too difficult to delete and recreate a partition, but the calculation must be done exactly right, or the filesystem inside the partition will be corrupted by misalignment or undersizing.

I don't normally prefer using GUIs, but resizing partitions using the command line is prone to human error, factoring in the partition table (usually msdos or gpt), the beginning of the partition, the end of the partition, and the right size.

WARNING: Before proceeding, take a backup of your XFS filesystem using this procedure (where /dev/sdg1 is your XFS filesystem and /path/to/backup.xfs is where you want to store your XFS dump):

mount /dev/sdg1 /mnt
xfsdump -f /path/to/backup.xfs -L MySession -M MyMedia /mnt

If something goes wrong, you can restore to a new XFS partition:

mount /dev/sdg1 /mnt # … where /dev/sdg1 is a new XFS partition
xfsrestore -f /path/to/backup.xfs /mnt

Easy Way

GParted does all the calculations for you:

Screenshot of GParted's partition resize feature

It's very self-explanatory, and it even expands the XFS filesystem to fit.
This is generally a safe procedure.

fdisk Way

Use fdisk to delete and recreate the partition. Full example:

root@node53 [~]# fdisk /dev/sdg

Welcome to fdisk (util-linux 2.25.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/sdg: 991.5 MiB, 1039663104 bytes, 2030592 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
Disklabel type: gpt
Disk identifier: FAFC7A8C-52CB-4FF2-9746-391D50BF729C

Device     Start     End Sectors  Size Type
/dev/sdg1   2048 1050623 1048576  512M Linux filesystem

Note the "Start" position (the 2048th sector in this example). You will need to type this in as the first sector when you recreate the partition.

Command (m for help): d
Selected partition 1
Partition 1 has been deleted.

Command (m for help): n
Partition number (1-128, default 1): 1
First sector (34-2030558, default 2048): 2048
Last sector, +sectors or +size{K,M,G,T,P} (2048-2030558, default 2030558): 2030558

fdisk will default to using the largest contiguous free space. (In this example, it's the 2030558th sector.)

Created a new partition 1 of type 'Linux filesystem' and of size 990.5 MiB.

Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

Now you have a larger partition which contains a smaller XFS filesystem. These commands would expand the XFS filesystem:

root@node53 [~]# mount -v /dev/sdg1 /mnt
mount: /dev/sdg1 mounted on /mnt.

root@node53 [~]# xfs_growfs /mnt
meta-data=/dev/sdg1              isize=256    agcount=4, agsize=32768 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=131072, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 131072 to 253563

Boom, you've got an expanded XFS partition:

root@node53 [~]# df -hT /mnt
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdg1      xfs   988M   26M  962M   3% /mnt

xfsdump Way (only way to shrink XFS)

Did you take a backup when I told you to? Yes? Good! I prefer to use xfsrestore to restore xfsdumps onto new partitions. The advantage is that you can actually shrink XFS filesystems using this method, but the downside is that all the data need to be rewritten, which is slower.

You can actually use the fdisk method above to recreate the partition. After exiting fdisk, do this instead:

root@node53 [~]# mkfs.xfs -f /dev/sdg1
meta-data=/dev/sdg1              isize=256    agcount=4, agsize=63391 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=253563, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=853, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
root@node53 [~]# mount -v /dev/sdg1 /mnt
mount: /dev/sdg1 mounted on /mnt.
root@node53 [~]# xfsrestore -f /path/to/backup.xfs /mnt
xfsrestore: using file dump (drive_simple) strategy
xfsrestore: version 3.1.4 (dump format 3.0) - type ^C for status and control
xfsrestore: searching media for dump
xfsrestore: examining media file 0
xfsrestore: dump description: 
xfsrestore: hostname: andie
xfsrestore: mount point: /mnt
xfsrestore: volume: /dev/sdg1
xfsrestore: session time: Mon Nov 16 14:44:20 2015
xfsrestore: level: 0
xfsrestore: session label: "MySession"
xfsrestore: media label: "MyMedia"
xfsrestore: file system id: c5981472-9b75-4fad-9bd8-d1bd04086f8d
xfsrestore: session id: 092b0cf3-120d-43c1-b8ce-23300abf558e
xfsrestore: media id: 3cc0f4db-665f-40fd-ac54-493625f712f5
xfsrestore: using online session inventory
xfsrestore: searching media for directory dump
xfsrestore: reading directories
xfsrestore: 1 directories and 0 entries processed
xfsrestore: directory post-processing
xfsrestore: restore complete: 0 seconds elapsed
xfsrestore: Restore Summary:
xfsrestore:   stream 0 /path/to/backup.xfs OK (success)
xfsrestore: Restore Status: SUCCESS

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.