public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Gerard Beekmans <GBeekmans@tsag.net>,
	"xfs@oss.sgi.com" <xfs@oss.sgi.com>
Subject: Re: Unable to mount and repair filesystems
Date: Thu, 29 Jan 2015 16:15:54 -0600	[thread overview]
Message-ID: <54CAB11A.7040509@sandeen.net> (raw)
In-Reply-To: <D90435AEFF34654AA1122988C66C8678023F0279AB@exchange.tsag.local>

On 1/29/15 3:59 PM, Gerard Beekmans wrote:
...

> That gives me this:
> 
> xfs_db> agf 5
> xfs_db> daddr
> current daddr is 5120001
> xfs_db> print
> magicnum = 0
> versionnum = 0

...

so it is completely zeroed out.

>  
>>> xfs_db: cannot init perag data (117). Continuing anyway.
>>> xfs_db> sb 0
>>> xfs_db> p
>>> magicnum = 0x58465342
>>
>> this must not be the one that repair failed on like:
>>
>>> couldn't verify primary superblock - bad magic number !!!
>>
>> because that magicnum is valid.  Did this one also fail to repair?
> 
> How do I know/check/test if "this one" fails to refer? I'm not sure what you're referring to (or what to do with it).

I'm sorry, I meant did this filesystem fail to repair based on a bad
primary superblock?

>>> agcount = 25
>>
>> 25 ags, presumably the fs was grown in the past, but ok...
> 
> Yes, it was. Ran out of space so I increased the size of the logical
> volume then used xfs_grow to increase the filesystem itself. That was
> the whole reason behind using LVM so this growth can be done on a
> live system without requiring repartitioning and such.

> I did read today that growing an XFS is not necessarily something we
> should be doing? Some posts even suggest that LVM and XFS shouldn't
> be mixed together. Not sure how to separate truth from fiction.

It's fine; the downside is for people who think they can start with 1G
and grow to 10T; that's pretty suboptimal.  XFS over LVM is fine.

I'm sure it's not related to this issue (unless it was very recently grown?
Was it grown shortly before the failures?)

Hm, it would have started at 4 AGs by default, and it's the 5th one that
looks bad; maybe that's a clue.  Are agf 6, 7, 8 etc also full of 0s?
  
>> The only thing I can say is that xfs is going to depend on the storage telling
>> the truth about completed IOs...  If the storage told XFS an IO was persistent,
>> but it wasn't, and the storage went poof, bad things can happen.  I don't
>> know the details of your setup, or TBH much about vmware over nfs ... you
>> weren't mounted with -o nobarrier were you?
> 
> No I wasn't mounted with nobarrier unless it is done by default. I
> never specified the option on command line or in /etc/fstab at any
> rate for what that is worth.

ok.  I'm not sure what to tell you at this point; you have at least one
swath of your storage which looks totally zeroed out.  That's not a
failure mode we usually see, and makes me think it's more storage related,
although the "how long ago did you grow this fs?" question might be
related, because the first visible corruption is in the first "new"
post-growth AG...

-Eric

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

  reply	other threads:[~2015-01-29 22:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-29 17:36 Unable to mount and repair filesystems Gerard Beekmans
2015-01-29 20:18 ` Eric Sandeen
2015-01-29 21:27   ` Gerard Beekmans
2015-01-29 21:49     ` Eric Sandeen
2015-01-29 21:59       ` Gerard Beekmans
2015-01-29 22:15         ` Eric Sandeen [this message]
2015-01-29 23:12           ` Dave Chinner
2015-01-30  0:04             ` Gerard Beekmans
2015-01-29 22:57     ` Dave Chinner

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=54CAB11A.7040509@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=GBeekmans@tsag.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