Description of problem: xfs_growfs doesn't allow filesystem to grow beyond current block size Version-Release number of selected component (if applicable): 2.9.7-1.fc9 How reproducible: always Steps to Reproduce: 1. xfs_growfs -d /media/compaq 2. also tried xfs_growfs -d /dev/c0d0p1 2. 3. Actual results: xfs_growfs -d /media/compaq meta-data=/dev/cciss/c0d0p1 isize=256 agcount=32, agsize=8310876 blks = sectsz=512 attr=0 data = bsize=4096 blocks=265948032, imaxpct=25 = sunit=0 swidth=0 blks 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 Expected results: partition to grow to max size available Additional info: fdisk -l returns Disk /dev/cciss/c0d0: 1633.9 GB, 1633991394304 bytes 255 heads, 63 sectors/track, 198654 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000eb921 Device Boot Start End Blocks Id System /dev/cciss/c0d0p1 * 1 132436 1063792138+ 83 Linux
can you please also include /proc/partitions and xfs_info output for the current mountpoint (/media/compaq) Thanks, -Eric
Actually, assuming fdisk is giving you 1024-block units and it matches the kernel view, you're already at the size of the partition (~1T). partition size: 1063792138*1024 1089323149312 fs size: 265948032*4096 1089323139072
You'll need to grow the partition first, then grow the filesystem on it. if that's not working, please reopen. -Eric
[root@mythtv ~]# xfs_info /media/compaq meta-data=/dev/cciss/c0d0p1 isize=256 agcount=32, agsize=8310876 blks = sectsz=512 attr=0 data = bsize=4096 blocks=265948032, imaxpct=25 = sunit=0 swidth=0 blks 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
major minor #blocks name 1 0 16384 ram0 1 1 16384 ram1 1 2 16384 ram2 1 3 16384 ram3 1 4 16384 ram4 1 5 16384 ram5 1 6 16384 ram6 1 7 16384 ram7 1 8 16384 ram8 1 9 16384 ram9 1 10 16384 ram10 1 11 16384 ram11 1 12 16384 ram12 1 13 16384 ram13 1 14 16384 ram14 1 15 16384 ram15 8 0 244198584 sda 8 1 104391 sda1 8 2 522112 sda2 8 3 243569497 sda3 104 0 1595694721 cciss/c0d0 104 1 1063792138 cciss/c0d0p1 8 16 2344266240 sdb 8 17 2097149166 sdb1 8 18 247111830 sdb2
If the partition you suggest I grow I am assuming it is /dev/cciss/c0d0 has already been expanded using the HP raid array tools If there is something else that needs to be performed, I am not finding it documented.
when I try to grow the p1 partition I get the follow error # xfs_growfs -d /dev/cciss/c0d0p1 meta-data=/dev/cciss/c0d0p1 isize=256 agcount=32, agsize=8310876 blks = sectsz=512 attr=0 data = bsize=4096 blocks=265948032, imaxpct=25 = sunit=0 swidth=0 blks 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 xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed Input/output error
No, you need to grow c0d0p1. c0d0 is the block device which contains the partition c0d0p1, it is the partition which contains the xfs filesystem you wish to grow. The partition is still only ~1T even though the disk containing it is now ~16T. (note also that dos partition tables cannot handle 16T partitions, if you are using a dos partition table...). In general you must first grow the block device on which the fs resides, then mount it, then grow it with xfs_growfs. -Eric
re: comment #7: xfs_growfs needs to be pointed at the mount point for a mounted partition, not its device.
(growing c0d0p1 is not something the xfs tools do; that's the job of, in your case, a partitioning tool I think. If it were an lvm device it'd be lvm tools, etc.)
Yes I tried that as well, same results [root@mythtv ~]# xfs_check /dev/cciss/c0d0p1 xfs_check: /dev/cciss/c0d0p1 contains a mounted and writable filesystem fatal error -- couldn't initialize XFS library [root@mythtv ~]# umount /dev/cciss/c0d0p1 [root@mythtv ~]# xfs_check /dev/cciss/c0d0p1 xfs_check: /dev/cciss/c0d0p1 is invalid (cannot read first 512 bytes) [root@mythtv ~]# xfs_check /dev/cciss/c0d0 xfs_check: /dev/cciss/c0d0 is invalid (cannot read first 512 bytes) [root@mythtv ~]# xfs_repair /dev/cciss/c0d0p1 Phase 1 - find and verify superblock... superblock read failed, offset 0, size 524288, ag 0, rval -1 fatal error -- Input/output error [root@mythtv ~]# however, now I can even mount the device [root@mythtv ~]# mount /dev/cciss/c0d0p1 /media/compaq -t xfs mount: /dev/cciss/c0d0p1: can't read superblock [root@mythtv ~]# [root@mythtv ~]# maybe a reboot will help.
OK, after a reboot all is well, I have 90 % of the data backed up so no worries I came across this earlier today, and it sounds like what you are telling me I need to do "Resizing XFS XFS has long included a partition-resizing tool, xfs_growfs. As the name implies, this program is designed for increasing a filesystem's size, not decreasing it. Unlike most partition-resizing tools, xfs_growfs is designed to work only on a mounted filesystem. The safest way to use it is to unmount the filesystem, delete the partition using fdisk, create a new partition in its place, mount the filesystem, and then call xfs_growfs: # xfs_growfs /mount/point As you might guess, /mount/point is the partition's mount point. You may also add the -D size option to specify the filesystem size in allocation blocks. Various other options are also available, as described in the xfs_growfs man page. Although GNU Parted's web page doesn't mention XFS support, the source code does include an XFS subdirectory. Parted refuses to work on XFS partitions, but this may change in the future."
yep, exactly :) FWIW, a terser version of the same information is in the xfs_growfs man page. -Eriic
thanks for the assistance, the method outlined above allowed me to expand the filesystem. Although this worked, when I try to have multiple processes performing i/o on the array, the filesystem goes offline. Not sure if it's a hdwr or software issue. Plan on dumping array at bios level and recreating using different filesystem. One rant in the man pages I have access to make no mention of the process to do so.
if the fs goes offline, I'd check dmesg. and if it looks xfs related, I'd file a new bug, or post it to the xfs list. -Eric