[gpfsug-discuss] Checking a file-system for errors

Wed Oct 11 12:55:18 BST 2017

Generally you should not run mmfsck unless you see MMFS_FSSTRUCT errors in 
your system logs.  To my knowledge online mmfsck only checks for a subset 
of problems, notably lost blocks, but that situation does not indicate any 
problems with the file system.

Fred
__________________________________________________
Fred Stock | IBM Pittsburgh Lab | 720-430-8821
stockf at us.ibm.com

From:   "Simon Thompson (IT Research Support)" <S.J.Thompson at bham.ac.uk>
To:     gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date:   10/11/2017 06:32 AM
Subject:        Re: [gpfsug-discuss] Checking a file-system for errors
Sent by:        gpfsug-discuss-bounces at spectrumscale.org

OK thanks,

So if I run mmfsck in online mode and it says:
"File system is clean.
Exit status 0:10:0."

Then I can assume there is no benefit to running in offline mode?

But it would also be prudent to run "mmrestripefs -c" to be sure my
filesystem is happy?

Thanks

Simon

On 11/10/2017, 11:19, "gpfsug-discuss-bounces at spectrumscale.org on behalf
of UWEFALKE at de.ibm.com" <gpfsug-discuss-bounces at spectrumscale.org on
behalf of UWEFALKE at de.ibm.com> wrote:

>Hm , mmfsck will  return not very reliable results in online mode,
>especially it will report many issues which are just due to the transient
>states in a files system in operation.
>It should however not find less issues than in off-line mode.
>
>mmrestripefs -c does not do any logical checks, it just checks for
>differences of multiple replicas of the same data/metadata.
>File system errors can be caused by such discrepancies (if an odd/corrupt
>replica is used by the GPFS), but can also be caused (probably more
>likely) by logical errors / bugs when metadata were modified in the file
>system. In those cases, all the replicas are identical nevertheless
>corrupt (cannot be found by mmrestripefs)
> 
>So, mmrestripefs -c is like scrubbing for silent data corruption (on its
>own, it cannot decide which is the correct replica!), while mmfsck checks
>the filesystem structure for logical consistency.
>If the contents of the replicas of a data block differ, mmfsck won't see
>any problem (as long as the fs metadata are consistent), but mmrestripefs
>-c will. 
>
> 
>Mit freundlichen GrÃ¼ÃŸen / Kind regards
>
> 
>Dr. Uwe Falke
> 
>IT Specialist
>High Performance Computing Services / Integrated Technology Services /
>Data Center Services
>--------------------------------------------------------------------------
>-----------------------------------------------------------------
>IBM Deutschland
>Rathausstr. 7
>09111 Chemnitz
>Phone: +49 371 6978 2165
>Mobile: +49 175 575 2877
>E-Mail: uwefalke at de.ibm.com
>--------------------------------------------------------------------------
>-----------------------------------------------------------------
>IBM Deutschland Business & Technology Services GmbH / GeschÃ¤ftsfÃ¼hrung:
>Thomas Wolter, Sven SchooÃŸ
>Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart,
>HRB 17122 
>
>
>
>
>From:   "Simon Thompson (IT Research Support)" <S.J.Thompson at bham.ac.uk>
>To:     "gpfsug-discuss at spectrumscale.org"
><gpfsug-discuss at spectrumscale.org>
>Date:   10/11/2017 10:47 AM
>Subject:        [gpfsug-discuss] Checking a file-system for errors
>Sent by:        gpfsug-discuss-bounces at spectrumscale.org
>
>
>
>I'm just wondering if anyone could share any views on checking a
>file-system for errors.
>
>For example, we could use mmfsck in online and offline mode. Does online
>mode detect errors (but not fix) things that would be found in offline
>mode?
>
>And then were does mmrestripefs -c fit into this?
>
>"-c
>                  Scans the file system and compares replicas of
>                  metadata and data for conflicts. When conflicts
>                  are found, the -c option attempts to fix
>                  the replicas.
>"
>
>Which sorta sounds like fix things in the file-system, so how does that
>intersect (if at all) with mmfsck?
>
>Thanks
>
>Simon
>
>_______________________________________________
>gpfsug-discuss mailing list
>gpfsug-discuss at spectrumscale.org
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=p_1XEUyoJ7-VJxF_w8h9gJh8_Wj0Pey73LCLLoxodpw&m=V8K9eELGXftg3ELG2jV1OYptzOZ-j9OdBkpgvJXV_IM&s=MdJhKZ9vW4uhTesz1LqKiEWo6gZAEXjtgw0RXnlJSgY&e=

>
>
>
>
>
>_______________________________________________
>gpfsug-discuss mailing list
>gpfsug-discuss at spectrumscale.org
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=p_1XEUyoJ7-VJxF_w8h9gJh8_Wj0Pey73LCLLoxodpw&m=V8K9eELGXftg3ELG2jV1OYptzOZ-j9OdBkpgvJXV_IM&s=MdJhKZ9vW4uhTesz1LqKiEWo6gZAEXjtgw0RXnlJSgY&e=

_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=p_1XEUyoJ7-VJxF_w8h9gJh8_Wj0Pey73LCLLoxodpw&m=V8K9eELGXftg3ELG2jV1OYptzOZ-j9OdBkpgvJXV_IM&s=MdJhKZ9vW4uhTesz1LqKiEWo6gZAEXjtgw0RXnlJSgY&e=

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20171011/d61db58a/attachment.htm>