Re: Got "Internal error XFS_WANT_CORRUPTED_GOTO". Filesystem needs reformatting to correct issue.

[Brian Foster <bfoster@redhat.com>]

On Sat, Jul 12, 2014 at 03:45:07AM +0200, Carlos E. R. wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> On Saturday, 2014-07-12 at 03:30 +0200, Carlos E. R. wrote:
> 
> >So, please wait till I verify things again. Tomorrow, it is 3 AM here.
> >Sorry :-(
> >
> >Unless "xfs_info tgtfile" gives the information about the device where
> >"tgtfile" is stored (/dev/sdf2), not on the image file itself :-?
> >
> >I'm very confused.
> 
> False alarm. See:
> 
> 
> Telcontar:/data/storage_c/tmp_borrar # xfs_info tgtfile
> meta-data=/dev/sde18             isize=256    agcount=4, agsize=35770496 blks
>          =                       sectsz=512   attr=2, projid32bit=0
>          =                       crc=0
> data     =                       bsize=4096   blocks=143081984, imaxpct=25
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
> log      =internal               bsize=4096   blocks=69864, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> Telcontar:/data/storage_c/tmp_borrar #
> 
> Telcontar:/data/storage_d/old_backup # xfs_info tgtfile
> meta-data=/dev/sdf2              isize=256    agcount=4, agsize=122341568 blks
>          =                       sectsz=512   attr=2, projid32bit=0
>          =                       crc=0
> data     =                       bsize=4096   blocks=489366272, imaxpct=5
>          =                       sunit=0      swidth=0 blks
> naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
> log      =internal               bsize=4096   blocks=238948, version=2
>          =                       sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none                   extsz=4096   blocks=0, rtextents=0
> Telcontar:/data/storage_d/old_backup #
> 
> Telcontar:/data/storage_d/old_backup # file tgtfile
> tgtfile: XFS filesystem metadump image
> Telcontar:/data/storage_d/old_backup #
> 
> 
> It appears that the command "xfs_info" analyzes the current, underlying,
> filesystem, not the one given on the command line. Or something in that
> line, I'm too sleepy. I hope you can understand my meaning better than my
> words...
> 

xfs_info reports on the mounted fs. If you check out 'man xfs_info,'
you'll see it specifies the mountpoint as a parameter but it can query
the fs info from the actual mountpoint or any file therein. E.g., so it
doesn't know anything about a metadump file and pointing it at one will
just report on the fs that contains the file.

If you wanted to test an actual metadump image, restore the metadump to
an fs image, mount and test that:

xfs_mdrestore ./metadump ./mynewfsimage
mount ./mynewfsimage /mnt -o loop
xfs_info /mnt/

Brian

> 
> So the uploaded file is the correct one.
> 
> 
> - -- Cheers,
>        Carlos E. R.
>        (from 13.1 x86_64 "Bottle" at Telcontar)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> 
> iEYEARECAAYFAlPAkyMACgkQtTMYHG2NR9U2uACfTdPx8DGCkBzLGiSVGn3XCcSV
> 7ukAnAvR1CjR9Jx3rPosLYNceBtQjJjf
> =/odv
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

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