xfs_growfs doesn't resize

[Eric Sandeen]

On 7/3/11 11:34 PM, kkeller at sonic.net wrote:
> 
> 
> On Sun 03/07/11  3:14 PM , Eric Sandeen <sandeen at sandeen.net> wrote:
> 
> [some rearranging]
> 
>> 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' ... ;)
> 
> Yep, that's definitely a lesson learned.  Though I don't think I can
> blame CentOS either--from what I can tell the bug has been available
> from yum for some time now.  So it's pretty much entirely my own
> fault.  :(

well it's unfortunate that that kmod persists.  I'll admit to providing
it, years and years ago... Centos should find a way to deprecate it...

> I also am sorry for not preserving threading--for some reason, the
> SGI mailserver rejected mail from my normal host (which is odd, as
> it's not in any blacklists I know of), so I am using an unfamiliar
> mail client.

sgi email ... sucks ;)

>> You probably hit this bug: 
>> http://oss.sgi.com/archives/xfs/2007-01/msg00053.html [1]
>> 
>> See also: http://oss.sgi.com/archives/xfs/2009-07/msg00087.html
>> [2]
>> 
>> I can't remember how much damage the original bug did ...
> 
> If any?  I'm a bit amazed that, if there was damage, that the
> filesystem is still usable.  Perhaps if I were to fill it it would
> show signs of inconsistency?  Or remounting would read the
> now-incorrect values from the superblock 0?
> 
>> is it still mounted I guess?
> 
> Yes, it's still mounted, and as far as I can tell perfectly fine.
> But I won't really know till I can throw xfs_repair -n and/or xfs_db
> and/or remount it; I'm choosing to get as much data off as I can
> before I try these things, just in case.
> 
> How safe is running xfs_db with -r on my mounted filesystem?  I

it's safe.  At worst it might read inconsistent data, but it's
perfectly safe.

> understand that results might not be consistent, but on the off
> chance that they are I am hoping that it might be at least a little
> helpful.
> 
> I was re-reading some of the threads I posted in my original
> messages, in particular these posts:
> 
> http://oss.sgi.com/archives/xfs/2009-09/msg00210.html 
> http://oss.sgi.com/archives/xfs/2009-09/msg00211.html
> 
> If I am reading those, plus the xfs_db man page, correctly, it seems
> like what Russell suggested was to look at superblock 1 (or some
> other one?) and use those values to correct superblock 0.  At what

don't worry about correcting anything until you know there is a problem :)

> points (if any) are the other superblocks updated?  I was testing on
> another machine, on a filesystem that I had successfully grown using
> xfs_growfs, and of the two values Russell suggested the OP to change,
> dblocks is different between sb 0 and sb 1, but agcount is not.
> Could that just be that I did not grow the filesystem too much, so
> that agcount didn't need to change?  That seems a bit
> counterintuitive, but (as should be obvious) I don't know XFS all

if you grew it 9T, you would have almost certainly gotten more AGs.
If you did a smaller test then you might see that.  To be honest
I don't remember when the backup superblocks get updated.

> that well.  I am hoping to know because, in re-reading those
> messages, I got a better idea of what those particular xfs_db
> commands do, so that if I did run into problems remounting, I might
> be able to determine the appropriate new values myself and reduce my
> downtime.  But I want to understand more what I'm doing before I try
> that!

I think finding a way to do a dry-run xfs_repair would be the best
place to start ...

Get a recent xfsprogs too, if you haven't already, it scales better
than the really old versions.

-Eric
 
> --keith
>