public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: kkeller@sonic.net
To: xfs@oss.sgi.com
Cc: Eric Sandeen <sandeen@sandeen.net>
Subject: Re: xfs_growfs doesn't resize
Date: Sun, 03 Jul 2011 12:42:59 -0700	[thread overview]
Message-ID: <62289.1309722179@sonic.net> (raw)

On Sun, Jul 03, 2011 at 10:59:03AM -0500, Eric Sandeen wrote:
> On 6/30/11 4:42 PM, kkeller@sonic.net 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/Linux
> > 
> > Yes, 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.


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_db voodoo? 2) once it's
determined healthy, again attempt to grow the filesystem. Here is
my current plan for reaching these goals:

0) get a nearer-term backup, just in case :) The filesystem still seems
perfectly normal, but without knowing what my first xfs_growfs did I
don't know if or how long this state will last.

1) umount the fs to run xfs_db

2) attempt a remount--is this safe, or is there risk of damaging the filesystem?

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).

4) In either case, post my xfs_db output to the list and get your
opinions on the health of the fs.

5) If the fs seems correct, attempt xfs_growfs again.

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.)

Would it make more sense to update the kernel and xfsprogs before
attempting a remount? If a remount fails under the original kernel,
what do people think the odds are that a new kernel would be able to
mount the original fs, or is that really unwise?

Again, many thanks for all your help.

--keith

-- 
kkeller@sonic.net

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2011-07-03 19:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-03 19:42 kkeller [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-07-06 22:51 xfs_growfs doesn't resize kkeller
2011-07-07 18:25 ` Keith Keller
2011-07-07 19:34   ` Eric Sandeen
2011-07-07 22:23     ` Keith Keller
2011-07-07 22:30       ` Eric Sandeen
2011-07-04  4:34 kkeller
2011-07-04  4:41 ` Eric Sandeen
2011-07-01 16:44 kkeller
2011-06-30 23:30 kkeller
2011-07-01 10:46 ` Dave Chinner
2011-06-30 21:42 kkeller
2011-07-03 15:59 ` Eric Sandeen
2011-07-03 16:01   ` Eric Sandeen
     [not found]   ` <20110703193822.GA28632@wombat.san-francisco.ca.us>
2011-07-03 22:14     ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=62289.1309722179@sonic.net \
    --to=kkeller@sonic.net \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox