Expanding the array

I added another drive to my array. This brings it to a total of 9x1TB disks in raid5. 8000GB of space in total. I came across this problem when I upgraded from 5 drives to 8 drives (Three $60 1TB drives came up on allclassifieds.com.au/ac and I could not resist). I have a dodgy 3-way molex power splitter that caused me some issues last time. It has been replaced.

The file system would not expand and xfs_growfs was not reporting any differences. After checking out google I found suggestions like rebooting, upgrading xfsprogs or backing up the data and just creating another file system.

The answer was a lot simpler and did not require any data loss. This is on centOS5.4.

Please don’t come back and tell me that you lost all your data as I don’t care. This method isn’t guaranteed to work and is just a suggestion.

Short answer:

[root@files ~]# umount /data
[root@files ~]# parted /dev/sdb
 (parted) print
 (parted) rm 1                                                             
 (parted) mkpart primary xfs 0 -0
 (parted) print   
 (parted) quit                                                         
[root@files ~]# mount /data
[root@files ~]# xfs_growfs -d /data

Long answer:

Just to show off the current space before anything has happened. 6.4TB total with 606GB free.

[root@files ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
 31G  6.7G   23G  23% /
/dev/sda1              97M   27M   66M  29% /boot
tmpfs                1006M     0 1006M   0% /dev/shm
/dev/sdb1             6.4T  5.8T  606G  91% /data

The xfs_growfs command is used with the -d option to attempt to grow to the maximum size. This comes out with an error because the file system thinks it is already at the maximum capacity.

[root@files ~]# xfs_growfs -d /data
meta-data=/dev/sdb1              isize=256    agcount=112, agsize=15258623 blks
 =                       sectsz=512   attr=1
data     =                       bsize=4096   blocks=1708964573, imaxpct=25
 =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=1
 =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
data size unchanged, skipping

Totally un-eventful un-mounting of data.

[root@files ~]# umount /data

Once you enter parted onto the device currently holding your file system. You will be asked to fix the GPT table. I chose to fix it, but it might not be required.

Print out the contents of the table just to make sure you’re removing the right partition and it starts at 0. Otherwise you will need to alter your commands to suit your situation.

Remove the partition and rebuild it with the maximum possible space.

Print out the contents again to make sure that it is what is intended.

[root@files ~]# parted /dev/sdb
GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(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/sdb appears to be used, you can
fix the GPT to use all of the space (an extra 1953103872 blocks) or continue
with the current setting?
Fix/Ignore? fix                                                           

Model: AMCC 9550SX-12 DISK (scsi)
Disk /dev/sdb: 8000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

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

(parted) rm 1                                                             
(parted) mkpart primary xfs 0 -0
(parted) print                                                            

Model: AMCC 9550SX-12 DISK (scsi)
Disk /dev/sdb: 8000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

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

(parted) quit

Mount the partition and grow the file system.

[root@files ~]# mount /data
[root@files ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
 31G  6.8G   23G  24% /
/dev/sda1              97M   27M   66M  29% /boot
tmpfs                1006M     0 1006M   0% /dev/shm
/dev/sdb1             6.4T  5.8T  605G  91% /data
[root@files ~]# xfs_growfs -d /data
meta-data=/dev/sdb1              isize=256    agcount=112, agsize=15258623 blks
 =                       sectsz=512   attr=1
data     =                       bsize=4096   blocks=1708964573, imaxpct=25
 =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal               bsize=4096   blocks=32768, version=1
 =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 1708964573 to 1953103863

Viola!

[root@files ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
 31G  6.8G   23G  24% /
/dev/sda1              97M   27M   66M  29% /boot
tmpfs                1006M     0 1006M   0% /dev/shm
/dev/sdb1             7.3T  5.8T  1.6T  80% /data
Tagged with: , , , , , , , ,
0 comments on “Expanding the array
1 Pings/Trackbacks for "Expanding the array"
  1. […] of googling later i finally found the solution on this blog: http://mdesbo.wordpress.com/2010/07/15/expanding-the-array basically, it boils down to having to delete the xfs partition and then recreate it with the […]

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.