RE: Unable to mount and repair filesystems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



<snip>

> Hence if the superblock is showing 25 AGs and the new ags from 4-25 are not
> found on disk then either:
> 
> 	a) if the grow was very recent the storage is not obeying
> 	cache flushes and hence breaking fundamental IO ordering
> 	behaviour; or,
> 
> 	b) if the growfs happened long ago, the storage has lost the
> 	data that was written to stable media...


To answer both Dave and Eric in a single email:

The growfs happened about 1 month ago. The storage crash occurred yesterday so that would make me think enough time would have passed to commit that data to disk so it must be option b) above.

I think it's academic at this point but to answer the SAN questions that came up:

The NFS server is the SAN itself. The SAN software is Nexenta which provides various methods of accessing its data (NFS, SMB and iSCSI being the primary ones).  When the SAN crashed, there was no warning so the Hypervisors had their shared NFS storage disconnected and ultimately after a timeout, the VMs that were running from those NFS shares were shutoff.

Eric: agf 5, 6, 7 and beyond are also full of 0s. 1-4 don't appear to be.

Gerard

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




[Index of Archives]     [Linux XFS Devel]     [Linux Filesystem Development]     [Filesystem Testing]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux