Hi Eric, Yes, that could be the problem. I have another host that have access to the same LUN. On the other host, I had a problem doing a live extend of an ext3 filesystem in the same LVM Volume Group. Maybe this corrupted the XFS filesystem. Anyway, we decided this morning to delete the partition and recreate the filesystem. We will be able to regenerate the data that was on it. Thanks, Stéphane -----Message d'origine----- De : xfs-bounces@xxxxxxxxxxx [mailto:xfs-bounces@xxxxxxxxxxx] De la part de Eric Sandeen Envoyé : 21 avril 2016 14:34 À : xfs@xxxxxxxxxxx Objet : Re: xfs_repair couldn't verify primary superblock On 4/21/16 10:42 AM, Stéphane Larose wrote: > 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, Any chance that some other host is accessing the same LUN on the SAN? This really looks like something external corrupted the filesystem by writing over it... -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
