[linux-lvm] Failed xfs_growfs after lvextend
Randall A. Jones
rajones at svs.gsfc.nasa.gov
Mon Nov 7 15:56:23 UTC 2005
Nathan Scott wrote:
> On Sat, Nov 05, 2005 at 01:31:10PM -0500, Randall A. Jones wrote:
>
>>I extended an LV to 12.28TB and ran xfs_growfs on the mount point, lv0.
>>This appeared to work fine except that after this, the filesystem didn't
>>appear any larger.
>
>
> I looked into this problem awhile back now. I believe what you're
> seeing here is an inconsistency in the kernels block layer - at least,
> when I last looked at this, this was the problem - the size increase
> was indeed done inside the driver, and /sys/block/xxx/size confirmed
> that, but the interfaces which use /dev/xxx to get the device size do
> not see the increase (i.e. lseek(SEEK_END) or a BLKGETSIZE64 ioctl).
>
> I wrote the attached program to show the issue, and sent mail to LKML
> to let folks know of the issue, I guess noone has got around to trying
> to address the problem yet though. The core of the problem was that
> the /dev/xxx inode size (i_size) had not been updated to reflect the
> change in device size, IIRC.
Ok. I looked at the things you suggested. It seems that everything is
in order with the device mapper and it sees the 12.28TB device size.
Your getdevicesize.c code verified this with a BLKGETSIZE64 ioctl call.
root at mapdata<~>$ cat /sys/block/dm-0/size
26367492096
root at mapdata<~>$ ~rajones/getdevicesize /dev/mapper/vg0-lv0
26367492096 512 byte blocks (BLKGETSIZE64)
26367492096 512 byte blocks is approx. 12.28TB.
So, back to xfs. Is it possible xfs_growfs is not working properly?
The result after running xfs_growfs was that the primary superblock on
the LV filesystem was corrupt or missing.
Is there a workaround? A 12.28TB LV with xfs filesystem should work, yes?
One idea for a workaround is to relocate the data on the misbehaving
LV/filesystem and recreate the LV and filesystem from scratch to avoid
using xfs_growfs.
I have enough free PVs to create a temp space to move my existing data.
Are there any possibilities for fixing the problem "in place".
Thank you,
Randall
--
..:.::::
Randall Jones GST NASA Goddard Space Flight Center
HPC Visualization Support http://hpcvis.gsfc.nasa.gov
Scientific Visualization Studio http://svs.gsfc.nasa.gov
rajones at svs.gsfc.nasa.gov Code 610.3 301-286-2239
More information about the linux-lvm
mailing list