Difference between revisions of "Increasing Thumper filesystems for DPM"
| (One intermediate revision by the same user not shown) | |||
| Line 45: | Line 45: | ||
The following was taken from http://www.linux.sgi.com/archives/xfs/2006-11/msg00001.html : | The following was taken from http://www.linux.sgi.com/archives/xfs/2006-11/msg00001.html : | ||
| − | + | ||
| + | ---- | ||
| + | |||
There's a 32 bit overflow in the growfs code (and transaction code | There's a 32 bit overflow in the growfs code (and transaction code | ||
on 32 bit systems) so you can't grow by more than 2TB at a time. | on 32 bit systems) so you can't grow by more than 2TB at a time. | ||
| Line 55: | Line 57: | ||
FSB = filesystem block size, and the current size is also in FSB. | FSB = filesystem block size, and the current size is also in FSB. | ||
| − | You can get both the current size and the FSB from xfs_growfs -n <mtpt> | + | You can get both the current size and the FSB from xfs_growfs -n <mtpt> |
| + | |||
| + | ---- | ||
If an attempt is made to increase a file system too much, the xfs_growfs command will not report a line like: | If an attempt is made to increase a file system too much, the xfs_growfs command will not report a line like: | ||
data blocks changed from 536870912 to 1073741824 | data blocks changed from 536870912 to 1073741824 | ||
| − | Note: the exact maximum was not determined on our CentOS 4.6 systems. However, increasing in steps of 2 TB was fine, whereas going from 2 to 12 in one | + | Note: the exact maximum was not determined on our CentOS 4.6 systems. However, increasing in steps of 2 TB was fine, whereas going from 2 to 12 in one step was not. |
Latest revision as of 17:44, 26 May 2008
The XFS file systems (on top of LVM) on Thumper disk servers can be grown on demand. Here follows the recipe to increase the file systems.
If the XFS file system should grow by more than 2 TB, see section Increasing file systems by more than 2 TB below for more details.
Increase the logical volume (/dev/data/atlasprd) on the Thumper. In this example, increase it to 4.4 TB (SI):
[root@hooi-ei-01 ~]# lvresize -L 4T /dev/data/atlasprd Extending logical volume atlasprd to 4.00 TB Logical volume atlasprd successfully resized
Increase the size of the XFS file system:
[root@hooi-ei-01 ~]# xfs_growfs /export/data/lv0
meta-data=/dev/data/atlasprd isize=256 agcount=32, agsize=16777216 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=536870912, 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 536870912 to 1073741824
The system should now see the modified size of the file system:
[root@hooi-ei-01 ~]# df -hH | grep -A 1 atlasprd
/dev/mapper/data-atlasprd
4.4T 1.6T 2.9T 37% /export/data/lv0
The DPM server has to be restarted to make it aware of this extra disk space:
[root@tbn18 ~]# service dpm restart Stopping dpm: [ OK ] Starting dpm:
Done!
Increasing XFS file systems by more than 2 TB
There seems to be an integer overflow in the xfs_grow command, which limits the increase of the file system to 2 TB. To grow a file system from 2 TB to 12 TB, repeatedly increase it by 2 TB: 2 -> 4 -> 6 ... -> 12.
The following was taken from http://www.linux.sgi.com/archives/xfs/2006-11/msg00001.html :
There's a 32 bit overflow in the growfs code (and transaction code on 32 bit systems) so you can't grow by more than 2TB at a time. I've got a fix under test for this at the moment.
Can you see if you can grow using:
- xfs_growfs -D <current size + (2TB / FSB) - 1> </path/to/mntpt>
FSB = filesystem block size, and the current size is also in FSB. You can get both the current size and the FSB from xfs_growfs -n <mtpt>
If an attempt is made to increase a file system too much, the xfs_growfs command will not report a line like:
data blocks changed from 536870912 to 1073741824
Note: the exact maximum was not determined on our CentOS 4.6 systems. However, increasing in steps of 2 TB was fine, whereas going from 2 to 12 in one step was not.
