Growing an XFS partition with parted

[MakOwner]

This is a lack of familiarity on my part and I couldn't find this clearly documented anywhere. So, hopefully this will help the next person googling in the middle of the night like me.
Moderators if this is in the wrong place, please move this!


I have a software RAID5 with XFS as the filesystem and have just added two more disks to the array and done all the mdadm functions to add them to the array - google that, it's pretty easy to find.

XFS has the xfs_growfs that you can grow the file system, but you have to resize the underlying partition first, else the output of xfs_growfs simply prints the size information about the partition as it exists.
No hints whatsoever as to why the filesystem hasn't grown.

parted has the ability to grow a partition - google that and you will quickly find parted doesn't support XFS. You can't resize an XFS partition.

What you can do is simply delete the existing partition and create a new one. This is the bit of information that is a bit hard to come by.

example:

parted /dev/md0
print
Model: Unknown (unknown)
Disk /dev/md0: 6001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 17.4kB 3001GB 3001GB xfs primary

rm 1

mkpart 1 0 6001GB

print
Model: Unknown (unknown)
Disk /dev/md0: 6001GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number Start End Size File system Name Flags
1 17.4kB 6001GB 6001GB xfs primary


mount the partition - xfs_growfs works on mounted partitions.

mount /dev/md0p1 /media/md0p1

xfs_growfs /media/md0p1



Once you have the steps, it's amazingly fast - I just spent a long time looking for the confirmation that deleting and redefining the partition wouldn't lose data.

[Banderon]

god bless you. i have been struggling with this SAME EXACT SITUATION for a good day now. it's as if you felt my pain and decided to post this just when you did.

[srs5694]

A couple of caveats:

First, be very very careful when creating that new partition. If it doesn't begin on exactly the same sector as the original partition, there are likely to be problems with using the filesystem, much less growing it. GNU Parted defaults to displaying partition boundaries in non-sector units (KB in the OP's example), which can mask small changes, particularly once the start sector moves into the MB or GB territory. If using GNU Parted, I recommend typing "unit s" to change the display units to sectors. That will at least let you see what's going on with better precision. GNU Parted also makes its changes immediately, which could be dangerous. Better to use fdisk (for MBR) or my GPT fdisk (for GPT), which enable you to abort changes. GParted also permits aborting operations, if you prefer a GUI tool.

Second, deleting and re-creating a GPT partition changes its GUID. (Note that this is different from the UUID of the filesystem it contains.) AFAIK, no Linux tool uses this value, so changing the GUID shouldn't make any difference, but I could be wrong, and some other OS might use this value. I don't know of any way of preserving this value in any libparted-based tool. It can be changed in GPT fdisk, but you'd need to copy the original value to the clipboard or to a file, then issue the command to change the partition's GUID and paste it back. Note that none of this is an issue with MBR disks, since they don't have any sort of unique ID code for individual partitions.

[Banderon]

I definitely second the 'unit s' comment. Also, if your partition had a name before, the name will be gone. You'll have to also call 'name [NAME]' to restore it.

Other than that, though, this guide is perfect. Worked perfectly for me, at least.

[arriflex]

This just gives me the willies! There has got to be a better way, deleting a partition and re-aligning a new one to the sector scares me.

However, I can't find a better way; so I would just say to the community that if XFS is going to continue to be installed as the biggest partition in a standard Mythbuntu install, we need to come up with an easier way for users to upgrade their hard disks.

I just replaced a 1Tb with a 2Tb and hoped to be able to grow that large XFS partition after cloning the drive over. Now I'm considering just running another partition as a separate storage group because it is so much easier to do!

arri

[MakOwner]

A couple of caveats:

First, be very very careful when creating that new partition. If it doesn't begin on exactly the same sector as the original partition, there are likely to be problems with using the filesystem, much less growing it. GNU Parted defaults to displaying partition boundaries in non-sector units (KB in the OP's example), which can mask small changes, particularly once the start sector moves into the MB or GB territory. If using GNU Parted, I recommend typing "unit s" to change the display units to sectors. That will at least let you see what's going on with better precision. GNU Parted also makes its changes immediately, which could be dangerous. Better to use fdisk (for MBR) or my GPT fdisk (for GPT), which enable you to abort changes. GParted also permits aborting operations, if you prefer a GUI tool.

Second, deleting and re-creating a GPT partition changes its GUID. (Note that this is different from the UUID of the filesystem it contains.) AFAIK, no Linux tool uses this value, so changing the GUID shouldn't make any difference, but I could be wrong, and some other OS might use this value. I don't know of any way of preserving this value in any libparted-based tool. It can be changed in GPT fdisk, but you'd need to copy the original value to the clipboard or to a file, then issue the command to change the partition's GUID and paste it back. Note that none of this is an issue with MBR disks, since they don't have any sort of unique ID code for individual partitions.

Could you give us an example of using the sector count for manipulating the partition? I'm about to do this again, and would rather be right and safe than just lucky
Is there a package in the respository for your GPT fdisk?

In my case there is no GUI available, the box runs headless without X at all.

[srs5694]

Could you give us an example of using the sector count for manipulating the partition? I'm about to do this again, and would rather be right and safe than just lucky

Details vary depending on whether you're using GNU Parted, GParted, fdisk, gdisk, or some other tool. Here's an example with fdisk (done on a USB flash drive):

fdisk /dev/sdc

The number of cylinders for this disk is set to 15418.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): u
Changing display/entry units to sectors

Command (m for help): p

Disk /dev/sdc: 16.2 GB, 16166944768 bytes
64 heads, 32 sectors/track, 15418 cylinders, total 31576064 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x2872a8cf

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              32    14745599     7372784   83  Linux

Command (m for help): d
Selected partition 1

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (32-31576063, default 32): 32
Last sector, +sectors or +size{K,M,G} (32-31576063, default 31576063): 
Using default value 31576063

Command (m for help): p

Disk /dev/sdc: 16.2 GB, 16166944768 bytes
64 heads, 32 sectors/track, 15418 cylinders, total 31576064 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x2872a8cf

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1              32    31576063    15788016   83  Linux

Command (m for help): w

Things to note:

• I used the 'u' command to change the units to sectors. Linux fdisk defaults to cylinders, which are imprecise enough that they could be misleading under some circumstances.
• Before deleting the original partition, I checked its start point and size via the 'p' command.
• I was careful to enter the same start sector for the new partition as was used for the original partition.
• I verified the new partition's start sector (via the 'p' command and a comparison to the original 'p' command's output) before saving changes (via the 'w' command). The end was, of course, later on the new partition than on the original.
• There's currently a move underway to shift from cylinder alignment to 1MB (2048-sector) alignment, since the latter produces improved performance on some RAID configurations and with some new hard disks. If your current partitions aren't aligned in the way that's natural for the utility you use, you might have to jump through some hoops to change the tool's alignment rules. You could use 'c' in fdisk or 'l' on the gdisk experts' menu to do this, for instance.

Is there a package in the respository for your GPT fdisk?

Yes, but I'm not sure for which versions it's valid, and the last I checked it was a bit elderly (version 0.5.1, IIRC; the current version is 0.6.6). It's the gdisk package. You can also download Debian packages for x86, x86-64, and PowerPC from the project's Sourceforge page.

[MakOwner]

Sorry to keep bugging you, I'm trying to teach myself basic math on the fly, I think ...

In my case, I'm extending an xfs filesystem on a software raid 5 -

root@shuttle:/home/dale# mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90
  Creation Time : Fri Mar  5 11:49:29 2010
     Raid Level : raid5
     Array Size : 10255951552 (9780.84 GiB 10502.09 GB)
  Used Dev Size : 1465135936 (1397.26 GiB 1500.30 GB)
   Raid Devices : 8
  Total Devices : 8
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Fri Apr 23 16:46:05 2010
          State : clean
 Active Devices : 8
Working Devices : 8
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : e8db6c04:5af33c7b:0f8e6487:c68eb25a (local to host shuttle)
         Events : 0.81218

    Number   Major   Minor   RaidDevice State
       0       8       65        0      active sync   /dev/sde1
       1       8       33        1      active sync   /dev/sdc1
       2       8       49        2      active sync   /dev/sdd1
       3       8       81        3      active sync   /dev/sdf1
       4       8       17        4      active sync   /dev/sdb1
       5       8      113        5      active sync   /dev/sdh1
       6       8       97        6      active sync   /dev/sdg1
       7       8      129        7      active sync   /dev/sdi1

A single partition this large is problematic for fdisk isn't it?
That's why I had used parted with the gpt labels to begin with.

I have already resized the array and am now at the point where I need to extend the file system.
As you can see parted has figured out there are issues with the partition.

 parted /dev/md0 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? i                                                      
Warning: Not all of the space available to /dev/md0 appears to be used, you can fix the GPT to use all of the space (an extra 8790815616 blocks) or continue with the current setting? 
Fix/Ignore? i                                                             
Model: Unknown (unknown)
Disk /dev/md0: 10.5TB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      17.4kB  6001GB  6001GB  xfs          primary

so, if using parted, i would start parted

root@shuttle:/home/dale# parted /dev/md0
GNU Parted 1.8.8.1.159-1e0e
Using /dev/md0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) u                                                                
Unit?  [compact]? s                                                       
(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? i                                                      
Warning: Not all of the space available to /dev/md0 appears to be used, you can fix the GPT to use all of the space (an extra 8790815616 blocks) or continue with the current setting? 
Fix/Ignore? i                                                             
Model: Unknown (unknown)
Disk /dev/md0: 20511903104s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End           Size          File system  Name     Flags
 1      34s    11721087454s  11721087421s  xfs          primary

and then delete the partition and recreate it starting at sector 34 and ending at the max sector.
Once parted is in "sector" display mode all of the commands will use that unit. Is that pretty close?

[srs5694]

The parted "backup GPT table is not at the end of the disk" message indicates that parted has noted the change in the "disk" (RAID array) size. Selecting the "fix" options should fix this, but I've not tested parted's behavior in this respect. With GPT fdisk (gdisk), you'd select the 'e' option on the experts' menu to do the same.

if using parted, i would start parted and then delete the partition and recreate it starting at sector 34 and ending at the max sector.
Once parted is in "sector" display mode all of the commands will use that unit. Is that pretty close?

Yes, but be sure that parted doesn't change the sector numbers. In fact, I'd recommend using gdisk rather than parted for this, since parted makes its changes immediately, whereas gdisk keeps your changes in memory and commits them to disk only when you tell it to do so. If parted shifts the partition start point in an unexpected way, you may have a hard time recovering it with parted. Also, if you want to preserve the partition's GUID number, you can do so with gdisk (albeit in an awkward way) by cutting-and-pasting the GUID number. (Use 'i' on the main menu to get the data (the "partition unique GUID" value) and then use 'c' on the experts' menu after you've made your changes to paste the original value back in.) I don't know of a way to do this with parted. AFAIK, nothing in Linux relies on GPT partitions' GUID numbers, but I might be unaware of something that does use them.

[damorgue]

Is there really no better way of doing this? I am in a similar situation as well, a grown array with a partition and filesysem that I thought was easily expandable. Has anything changed in the matter lately?