On Mon, Nov 07, 2005 at 10:56:23AM -0500, Randall A. Jones wrote: > > 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. Ah, excellent, sounds like that issue I had seen has been resolved. > So, back to xfs. Is it possible xfs_growfs is not working properly? Anythings possible, its unlikely though as we run it through regression tests every day - the core functionality is sound, its usually the interaction with drivers that gets fun. > The result after running xfs_growfs was that the primary superblock on > the LV filesystem was corrupt or missing. Do you know for sure that it wasn't corrupt/missing before running xfs_growfs (iow, did you run repair vefore and after the extend)? > Is there a workaround? Hard to say, without knowing what the problem is. > A 12.28TB LV with xfs filesystem should work, yes? Oh, definately. > 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. It's not clear that growfs did anything wrong yet. That approach will also avoid use of lvextend, fwiw, and I'd expect recreate-from-scratch will work as thats a commonly used scenario... so I guess thats your best approach, unless you want to diagnose the problem more closely (please do, for those who come after you...) cheers. -- Nathan _______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
