public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Keith Keller <kkeller@sonic.net>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_growfs doesn't resize
Date: Thu, 07 Jul 2011 14:34:12 -0500	[thread overview]
Message-ID: <4E160A34.20902@sandeen.net> (raw)
In-Reply-To: <20110707182532.GA31319@sonic.net>

On 7/7/11 1:25 PM, Keith Keller wrote:
> Hi all,
> 
> First, I hope that this message fixes my mail client breaking threading.
> 
> I am sorry for following up my own post (again), but I realized this
> morning that there may be another possible risk I had not considered:
> 
> On Wed, Jul 06, 2011 at 03:51:32PM -0700, kkeller@sonic.net wrote:
>>
>> So, here is my xfs_db output.  This is still on a mounted filesystem.
> 
> How safe/risky is it to leave this filesystem mounted and in use?
> I'm not too concerned about new data, since it won't be a huge amount,
> but I am wondering if data that's already been written may be at risk.
> Or, it it a reasonable guess that the kernel is still working completely
> with the old filesystem geometry, and so won't write anything beyond the
> old limits while it's still mounted?  df certainly seems to use the old
> fs size, not the new one.

I don't remember all the implications of this very old bug...

It seems like you need an "exit strategy" - you probably cannot leave
your fs mounted -forever- ...

If it were me, if possible, I'd make backups of the fs as it's mounted
now, then umount it and make an xfs_metadump of it, restore that metadump
to a new sparse file, and point xfs_repair at that metadata image file,
to see what repair might do with it.

If repair eats it alive, then we can look into more xfs_db type surgery
to fix things up more nicely...

-Eric

> Thanks again,
> 
> 
> --keith
> 
> 

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

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

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2011-07-07 22:23     ` Keith Keller
2011-07-07 22:30       ` Eric Sandeen
2011-07-20 19:08         ` xfs_growfs doesn't resize (update) Keith Keller
2011-07-25 18:28           ` Keith Keller
2011-08-01  4:46             ` xfs_growfs doesn't resize (partial resolution) Keith Keller
  -- strict thread matches above, loose matches on Subject: below --
2011-07-04  4:34 xfs_growfs doesn't resize kkeller
2011-07-04  4:41 ` Eric Sandeen
2011-07-03 19:42 kkeller
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=4E160A34.20902@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=kkeller@sonic.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