> What's on a 'dataOnly' GPFS 3.5.x NSD besides data and the NSD disk > header, if anything?
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. > I'm trying to understand some file corruption, and one potential > explanation would be if a (non-GPFS) server wrote to a LUN used as a > GPFS dataOnly NSD. > > We are not seeing any 'I/O' or filesystem errors, mmfsck (online) doesn't > detect any errors, and all NSDs are usable. However, some files seem to > have changes in content, with no changes in metadata (modify timestamp, > ownership), including files with the GPFS "immutable" ACL set. This is all consistent with the content on a dataOnly disk being overwritten outside of GPFS. > If an NSD was changed outside of GPFS control, would mmfsck detect > filesystem errors, or would the GPFS filesystem be consistent, even > though the content of some of the data blocks was altered? No. mmfsck can detect metadata corruption, but has no way to tell whether a data block has correct content or garbage. > Is there any metadata or checksum information maintained by GPFS, or any > means of doing a consistency check of the contents of files that would > correlate with blocks stored on a particular NSD? 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. yuri
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
