Wrong Disk Utilization in WebGUI

First thing is to check filesystem on that disk, assuming it' XFS, run it without -n.

Alright, that fixed it, thank you 🙂.

 

Follow up: What to do now? Can I just carry on since file system is not included in parity (don't know it that is the case) or can the parity be potentially affected? In that case should I trust parity or the data and rebuild?

Anything you do to the disk automatically updates parity to keep it in sync.

It sure does... but how about file system corruption? Or whatever might have happened to me.

File system corruption is most often caused by un unclean shutdown, it can also be caused by hardware issues,  e.g., bad RAM, if it keeps happening without an apparent reason you'll need to investigate.

Changed Status to Closed

Changed Priority to Other

On 9/1/2023 at 9:59 AM, JorgeB said:

File system corruption is most often caused by un unclean shutdown, it can also be caused by hardware issues,  e.g., bad RAM, if it keeps happening without an apparent reason you'll need to investigate.

 

Sure. But can I consider this case fixed by running the xfs file system repair? Or does it somehow affect parity?

2 hours ago, Lukáš Řádek said:

 

Sure. But can I consider this case fixed by running the xfs file system repair? Or does it somehow affect parity?

If you run a xfs file system repair via the GUI this will update parity as it is doing any repair.   

 

Having said that it is possible that a parity check may find a small number of errors that need correcting after an unclean shuitdown as some writes at the unclean shutdown stage did not make it to the parity drive as well.

On 9/3/2023 at 3:02 PM, itimpi said:

If you run a xfs file system repair via the GUI this will update parity as it is doing any repair.   

 

Having said that it is possible that a parity check may find a small number of errors that need correcting after an unclean shuitdown as some writes at the unclean shutdown stage did not make it to the parity drive as well.

 

Thanks. A situation that I feared with parity system is how to know if the parity error actually means that there is bad data on the parity drive (for example due to unclean shutdown) or on the data drive since that is the one that has been corrupted.

1 hour ago, Lukáš Řádek said:

Thanks. A situation that I feared with parity system is how to know if the parity error actually means that there is bad data on the parity drive (for example due to unclean shutdown) or on the data drive since that is the one that has been corrupted.

You cannot.   Parity is not that clever - it only knows that something has gone wrong somewhere.

 

The sequence of the way that the writes happen that as long as a drive has not failed a lost write to the parity drive is far more likely than the data drive so this is the assumption that is made.   The only way to make sure that a data drive does not have bad data is to either have checksums for the data or use BTRFS or ZFS as the file system type as they have built in check-summing.

 

This is one of the reasons we recommend that the scheduled parity check is set to be non-correcting so that you only run a correcting check when you think none of your data drives has a problem.

On 8/31/2023 at 2:06 PM, JorgeB said:

First thing is to check filesystem on that disk, assuming it' XFS, run it without -n.

After a moment of terror, i ran the filesystem check which corrected it for me, too 

Thanks for the easy solution!

Edited February 8 by Jabberwocky