[Top] [All Lists]

Re: xfs_growfs doesn't resize

To: Keith Keller <kkeller@xxxxxxxxx>
Subject: Re: xfs_growfs doesn't resize
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 07 Jul 2011 14:34:12 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20110707182532.GA31319@xxxxxxxxx>
References: <20110707182532.GA31319@xxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
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@xxxxxxxxx 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...


> Thanks again,
> --keith

<Prev in Thread] Current Thread [Next in Thread>