xfs
[Top] [All Lists]

Re: Failure growing xfs with linux 3.10.5

To: Michael Maier <m1278468@xxxxxxxxxxx>
Subject: Re: Failure growing xfs with linux 3.10.5
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Thu, 15 Aug 2013 13:42:31 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <520D1F8A.3060707@xxxxxxxxxxx>
References: <52073905.8010608@xxxxxxxxxxx> <5207D9C4.7020102@xxxxxxxxxxx> <52090C6C.6060604@xxxxxxxxxxx> <20130813000453.GQ12779@dastard> <520A5132.6090608@xxxxxxxxxxx> <20130814062041.GB12779@dastard> <520BAE48.1020605@xxxxxxxxxxx> <520D0D5D.4000309@xxxxxxxxxxx> <520D162B.5060901@xxxxxxxxxxx> <520D1A82.1000709@xxxxxxxxxxx> <520D1F8A.3060707@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
On 8/15/13 1:35 PM, Michael Maier wrote:
>> but a check prior wouldn't have helped you, because repair didn't detect
>> > the problem that growfs choked on.
> The old xfs_repair! Your patched one would have detected the problem if
> I got it right.
> 
> But globally speaking: you're right - it's impossible to get 100%
> security. But couldn't xfs_repair -n find other problems which therefore
> could be repaired before growing the FS?

yep, sure.

extN keeps track of the last fsck instance, and sometimes enforces it
prior to resize.  XFS doesn't do that, but it's probably not bad
practice.

-Eric

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