<html><body><p><tt>> What's on a 'dataOnly' GPFS 3.5.x NSD besides data and the NSD disk<br>> header, if anything?<br></tt><br><tt>That's it. In some cases there may also be a copy of the file system descriptor, but that doesn't really matter in your case.</tt><br><br><tt>> I'm trying to understand some file corruption, and one potential<br>> explanation would be if a (non-GPFS) server wrote to a LUN used as a<br>> GPFS dataOnly NSD.<br>> <br>> We are not seeing any 'I/O' or filesystem errors, mmfsck (online) doesn't<br>> detect any errors, and all NSDs are usable. However, some files seem to<br>> have changes in content, with no changes in metadata (modify timestamp,<br>> ownership), including files with the GPFS "immutable" ACL set.<br></tt><br><tt>This is all consistent with the content on a dataOnly disk being overwritten outside of GPFS.</tt><br><br><tt>> If an NSD was changed outside of GPFS control, would mmfsck detect<br>> filesystem errors, or would the GPFS filesystem be consistent, even<br>> though the content of some of the data blocks was altered?<br></tt><br><tt>No. mmfsck can detect metadata corruption, but has no way to tell whether a data block has correct content or garbage.</tt><br><br><tt>> Is there any metadata or checksum information maintained by GPFS, or any<br>> means of doing a consistency check of the contents of files that would<br>> correlate with blocks stored on a particular NSD?<br></tt><br><tt>GPFS on top of traditional disks/RAID LUNs doesn't checksum data blocks, and thus can't tell whether a data block is good or bad. GPFS Native RAID has very strong on-disk data checksumming, OTOH.</tt><br><br><tt>yuri</tt><BR>
</body></html>