xfs_growfs doesn't resize
Hello kind XFS folks,
I am having a strange issue with xfs_growfs, and before I attempt to do something potentially unsafe, I thought I would check in with the list for advice.
Our fileserver had an ~11TB xfs filesystem hosted under linux lvm. I recently added more disks to create a new 9TB container, and used the lvm tools to add the container to the existing volume group. When I went to xfs_growfs the filesystem, I had the first issue that this user had, where the metadata was reported, but there was no message about the new number of blocks:
http://oss.sgi.com/archives/xfs/2008-01/msg00085.html
Fortunately, I have not yet seen the other symptoms that the OP saw: I can still read from and write to the original filesystem. But the filesystem size hasn't changed, and I'm not experienced enough to interpret the xfs_info output properly.
I read through that thread (and others), but none seemed specific to my issue. Plus, since my filesystem still seems healthy, I'm hoping that there's a graceful way to resolve the issue and add the new disk space.
Here's some of the information I've seen asked for in the past. I apologize for it being fairly long.
/proc/partitions:
major minor #blocks name
8 0 244129792 sda 8 1 104391 sda1 8 2 8385930 sda2 8 3 21205800 sda3 8 4 1 sda4 8 5 30876898 sda5 8 6 51761398 sda6 8 7 20555136 sda7 8 8 8233281 sda8 8 9 20603331 sda9
8 16 11718684672 sdb
8 17 11718684638 sdb1
253 1 21484244992 dm-1
8 48 9765570560 sdd
8 49 9765568085 sdd1
sdb1 is the original member of the volume group. sdd1 is the new PV. I believe dm-1 is the LV where the volume group is hosted (and all the LVM tools report a 20TB logical volume).
# lvdisplay --- Logical volume --- LV Name /dev/saharaVG/saharaLV VG Name saharaVG LV UUID DjacPa-p9mk-mBmv-69c2-dmXF-LfxQ-wsRUOD LV Write Access read/write LV Status available # open 1 LV Size 20.01 TB Current LE 5245177 Segments 2 Allocation inherit Read ahead sectors 0 Block device 253:1
# uname -a Linux sahara.xxx 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
Yes, it's not a completely current kernel. This box is running CentOS 5 with some yum updates.
# xfs_growfs -V xfs_growfs version 2.9.4
This xfs_info is from after the xfs_growfs attempt. I regret that I don't have one from before; I was actually thinking of it, but the resize went so smoothly on my test machine (and went fine in the past as well on other platforms) that I didn't give it much thought till it was too late.
# xfs_info /export/
meta-data=/dev/mapper/saharaVG-saharaLV isize=256 agcount=32, agsize=91552192 blks
= sectsz=512 attr=0
data = bsize=4096 blocks=2929670144,
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=0I saw requests to run xfs_db, but I don't want to mess up the syntax, even if -r should be safe.
Thanks for any help you can provide!
--keith
Signature · 7 lines
[email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 5 lines · On 6/30/11 4:42 PM, [email protected] wrote:
# uname -a Linux sahara.xxx 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/LinuxYes, it's not a completely current kernel. This box is running CentOS 5 with some yum updates.
try
# rpm -qa | grep xfs
If you see anything with "kmod" you're running an exceptionally old xfs codebase.
2.6.18-138 and beyond should have a newer xfs backport built into the kernel rpm itself, as shipped from Red Hat. But the ancient xfs-kmod (or similar) provided xfs.ko will take precedence even if you update that kernel.
* Fri Apr 03 2009 Don Zickus <[email protected]> [2.6.18-138.el5]
...
- [fs] xfs: update to 2.6.28.6 codebase (Eric Sandeen ) [470845]
If at all possible I'd try an updated kernel, especially if your xfs.ko is provided by the very, very, very old centos xfs-kmod rpm.
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 9 lines · Eric Sandeen
Quoted 5 lines · On 6/30/11 4:42 PM, [email protected] wrote:
# uname -a Linux sahara.xxx 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/LinuxYes, it's not a completely current kernel. This box is running CentOS 5 with some yum updates.
try
Quoted 7 lines
# rpm -qa | grep xfsIf you see anything with "kmod" you're running an exceptionally old xfs codebase.
2.6.18-138 and beyond should have a newer xfs backport built into the kernel rpm itself, as shipped from Red Hat. But the ancient xfs-kmod (or similar) provided xfs.ko will take precedence even if you update that kernel.
... unless you uninstall the xfs-kmod package.
(i'm not sure how to set precedence of found kernel modules, I guess)
-Eric
Quoted 8 lines
* Fri Apr 03 2009 Don Zickus <[email protected]> [2.6.18-138.el5]
...
- [fs] xfs: update to 2.6.28.6 codebase (Eric Sandeen ) [470845]If at all possible I'd try an updated kernel, especially if your xfs.ko is provided by the very, very, very old centos xfs-kmod rpm.
-Eric
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 20 lines · Keith Keller
Quoted 4 lines · Eric Sandeen
Quoted 3 lines · On 6/30/11 4:42 PM, [email protected] wrote:
# uname -a Linux sahara.xxx 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:10:25 EDT 2009 x86_64 x86_64 x86_64 GNU/LinuxQuoted 8 lines
Quoted 2 lines
Yes, it's not a completely current kernel. This box is running CentOS 5 with some yum updates.
try
# rpm -qa | grep xfsIf you see anything with "kmod" you're running an exceptionally old xfs codebase.
Yes, I do have a kmod-xfs package, so clearly a kernel update is in order. So my goals are twofold: 1) verify the current filesystem's state--is it healthy, or does it need
xfs_dbvoodoo? 2) once it's determined healthy, again attempt to grow the filesystem. Here is my current plan for reaching these goals:
Quoted 3 lines
0) get a nearer-term backup, just in case :) The filesystem still seems perfectly normal, but without knowing what my first
xfs_growfsdid I don't know if or how long this state will last.
good idea.
Quoted 4 lines
1) umount the fs to run
xfs_db2) attempt a remount--is this safe, or is there risk of damaging the filesystem?
I'm not sure.
You probably hit this bug:
http://oss.sgi.com/archives/xfs/2007-01/msg00053.html
See also:
http://oss.sgi.com/archives/xfs/2009-07/msg00087.html
I can't remember how much damage the original bug did ...
Quoted 3 lines
3) If a remount succeeds, then update the kernel and xfsprogs. If a remount doesn't work, then revert to the near-term backup I took in 0) and attempt to fix the issue (with the help of the list, I hope).
One thing you might be able to do, though I don't remember for sure if this works, is to freeze the fs and create an xfs_metadump image of it. You can then point xfs_repair at that image, and see what it finds. But I'm not sure if metadump will work on a frozen fs... hm no. Only if it's mounted ro.
Otherwise -maybe- xfs_repair -n -d might work after a mount -o remount,ro.
(-n -d means operate in no-modify mode on an ro-mounted fs)
So you'd need to mount readonly before you could either do xfs_repair -nd or xfs_metadump followed by repair of that image. Either one would give you an idea of the health of the fs.
Quoted 2 lines
4) In either case, post my
xfs_dboutput to the list and get your opinions on the health of the fs.
repair probably will tell you more as an initial step.
Quoted 9 lines
5) If the fs seems correct, attempt
xfs_growfsagain.Do all these steps seem reasonable? I am most concerned about step 2-- I really do want to be able to remount as quickly as possible, but I do not know how to tell whether it's okay from xfs_db's output. So if a remount attempt is reasonably nondestructive (i.e., it won't make worse an already unhealthy XFS fs) then I can try it and hope for the best. (From the other threads I've seen it seems like it's not a good idea to run
xfs_repair.)
you can run it with -n to do no-modify. If it's clean, you're good; if it's a mess, you won't hurt anything, other than making you sad. :)
Quoted 2 lines
Would it make more sense to update the kernel and xfsprogs before attempting a remount? If a remount fails under the original kernel,
is it still mounted I guess?
A newer up to date kernel certainly won't make anything -worse-
You should uninstall that kmod rpm though so it doesn't get priority over the xfs.ko in the new kernel. If you need to revert to the old kernel, you could always reinstall it.
Quoted 2 lines
what do people think the odds are that a new kernel would be able to mount the original fs, or is that really unwise?
I don't think a newer kernel would do any further harm.
Quoted 1 line
Again, many thanks for all your help.
You're welcome but here's the obligatory plug in return - running RHEL5 proper would have gotten you up to date, fully supported xfs, and you wouldn't have run into this mess. Just sayin' ... ;)
-Eric
Quoted 3 lines
--keith
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs