xfs_growfs doesn't resize
On Sun 03/07/11 3:14 PM , Eric Sandeen <[email protected]> wrote:
[some rearranging]
Quoted 3 lines
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. :(
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.
Quoted 7 lines
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?
Quoted 1 line
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 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 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 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!
--keith
Signature · 6 lines
[email protected] _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 6 lines · On 7/3/11 11:34 PM, [email protected] wrote:
On Sun 03/07/11 3:14 PM , Eric Sandeen <[email protected]> wrote:
[some rearranging]
Quoted 8 lines
Quoted 3 lines
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...
Quoted 4 lines
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 ;)
Quoted 13 lines
Quoted 7 lines
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?
Quoted 8 lines
Quoted 1 line
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/orxfs_dband/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_dbwith -r on my mounted filesystem? I
it's safe. At worst it might read inconsistent data, but it's perfectly safe.
Quoted 7 lines
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:
Quoted 6 lines
http://oss.sgi.com/archives/xfs/2009-09/msg00210.html
http://oss.sgi.com/archives/xfs/2009-09/msg00211.htmlIf I am reading those, plus the
xfs_dbman 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 :)
Quoted 7 lines
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.
Quoted 6 lines
that well. I am hoping to know because, in re-reading those messages, I got a better idea of what those particular
xfs_dbcommands 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
Quoted 2 lines
--keith
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs