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
|