Hi Eric, Nothing more interesting. From the log: 2016-04-04T14:48:48.735738-04:00 manitou kernel: [271211.548878] XFS (dm-24): Mounting V4 Filesystem 2016-04-04T14:48:48.882738-04:00 manitou kernel: [271211.694242] XFS (dm-24): Ending clean mount Then no more logs about dm-24. Also no errors from the underlying storage (verified in SANtricity) which is an IS5000. The filesystem was new, the first mount was on 2016-04-04. manitou:~ # blkid /dev/dm-24 /dev/dm-24: UUID="1da22ae2-a572-4db7-b177-b90021a20863" TYPE="xfs" Thank you for your help, Stéphane -----Message d'origine----- De : Eric Sandeen [mailto:sandeen@xxxxxxxxxxx] Envoyé : 20 avril 2016 16:14 À : Stéphane Larose <Stephane.Larose@xxxxxxxxxxxxxx> Objet : Re: xfs_repair couldn't verify primary superblock On 4/20/16 1:50 PM, Stéphane Larose wrote: > Hello, > > > > When I try to mount a cleany unmounted XFS filesystem, I get those errors in the log : > > > [1650856.121229] XFS (dm-24): Mounting V4 Filesystem [1650856.135455] > XFS (dm-24): Log inconsistent or not a log (last==0, first!=1) > [1650856.135461] XFS (dm-24): empty log check failed [1650856.135463] > XFS (dm-24): log mount/recovery failed: error 22 [1650856.135495] XFS > (dm-24): log mount failed You could maybe use xfs_logdump to see what's there, but... > I have tried xfs_repair but… > > manitou:~ # xfs_repair /dev/dm-24 > > Phase 1 - find and verify superblock... > couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!! > > attempting to find secondary superblock... > ........................................ > After a lot of dots, xfs_repair can’t find secondary superblocks. > > This is where my knowledge of XFS filesystem stops. Looking at the superblock information, I have a feeling that the primary superblock is fine but not the secondary superblocks (strange blocksize and dblocks numbers). Is there any way to copy the primary superblock to the secondary superblocks? Maybe this is not a good idea? > > Thank you for any help! > ... the stated locations of the backup supers certainly don't contain good data: > xfs_db> sb 1 > xfs_db> p > magicnum = 0xf6b89fbf > blocksize = 1483932129 > dblocks = 15694009933101722137 > rblocks = 11068626756016902811 > rextents = 1593063622148300128 ... > xfs_db> sb 2 > xfs_db> p > magicnum = 0x41474341 > blocksize = 1195590471 > dblocks = 4847921951085253716 > rblocks = 4846789398308864835 > rextents = 4702132125296707412 ... which is why it couldn't find any valid/matching backups. The stated AG size does look correct, though, for the overall size of the filesystem as stated in SB 0. Is there more to this story? Did something "interesting" happen with the underlying storage? Or with the filesystem prior to this problem? does "blkid /dev/dm-24" say anything other than "xfs filesystem?" -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
