xfs_growfs "autodetects" the block device size. You can force re-read of the block device to refresh this info but might not do anything at all. There are situations when block device size will not reflect reality - for example you can't (or at least couldn't) resize partition that is in use (mounted, mapped, used in LVM...) without serious hacks, and ioctls on this partition will return the old size until you reboot. The block device can also simply lie (like if you triggered a bug that made the rbd device visually larger). Device-mapper devices have their own issues. The only advice I can give is to never, ever shrink LUNs or block devices and to avoid partitions if you can. I usually set up a fairly large OS drive (with oversized partitions to be safe, assuming you have thin-provisioning it wastes no real space) and a separate data volume without any partitioning. This also works-around possible alignment issues.... Growing is always safe, shrinking destroys data. I am very surprised that "rbd resize" doesn't require something like "--i-really-really-know-what-i-am-doing --please-eatmydata" parameter to shrink the image (or does it ask for confirmation when shrinking at least? I can't try it now). Making a typo == instawipe? My bet would still be that the original image was larger and you shrunk it by mistake. The kernel client most probably never gets the capacity change notification and you end up creating filesystem that points outside the device. (not sure if mkfs.xfs actually tries seeking over the full sector range). This is the most plausible explanation I can think of, but anything is possible. I have other ideas if you want to investigate but I'd take it off-list... Jan P.S. Your image is not 2TB but rather 2000 GiB ;-)
|
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
