"This is a bug."

[Brian Foster]

On Thu, Sep 10, 2015 at 04:05:30PM +0300, Tapani Tarvainen wrote:
> On 10 Sep 09:01, Brian Foster (bfoster at redhat.com) wrote:
> 
> > > It is 2.5GB so not really nice to mail...
> 
> > Can you compress it?
> 
> Ah. Of course, should've done it in the first place.
> Still 250MB though:
> 
> https://huom.it.jyu.fi/tmp/data1.metadump.gz
> 

First off, I see ~60MB of corruption output before I even get to the
reported repair failure, so this appears to be an extremely severe
corruption and I wouldn't be surprised if ultimately beyond repair (not
that it matters for you, since you are restoring from backups).

The failure itself is an assert failure against an error return value
that appears to have a fallback path, so I'm not really sure why it's
there. I tried just removing it to see what happens. It ran to
completion, but there was a ton of output, write verifier errors, etc.,
so I'm not totally sure how coherent the result is yet. I'll run another
repair pass and do some directory traversals and whatnot and see if it
explodes...

I suspect what's more interesting at this point is what happened to
cause this level of corruption? What kind of event lead to this? Was it
a pure filesystem crash or some kind of hardware/raid failure?

Also, do you happen to know the geometry (xfs_info) of the original fs?
Repair was showing agno's up in the 20k's and now that I've mounted the
repaired image, xfs_info shows the following:

meta-data=/dev/loop0             isize=256    agcount=24576, agsize=65536 blks
         =                       sectsz=4096  attr=2, projid32bit=0
         =                       crc=0        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=1610612736, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal               bsize=4096   blocks=2560, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

So that's a 6TB fs with over 24000 allocation groups of size 256MB, as
opposed to the mkfs default of 6 allocation groups of 1TB each. Is that
intentional?

Brian

> -- 
> Tapani Tarvainen
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs