All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.