"Unmountable: No file system" (SOLVED)

[Ruthalas]

I am having an issue where one disk in my array generates the error, "Unmountable: No file system".

It started after I set my array up to spin down, and discovered I couldn't get it to spin up again. I stopped the array, turned off automatic spin down, and when I started the array this disk would no longer mount. (I don't know if that is useful information, but it is the sequence of events that happened immediately prior to the issue with the disk.)

 

I have done the following to troubleshoot so far (following the wiki):

• Noted that the drive is XFS
• Started array in Maintenance Mode
• Ran the '-nv' command in the 'Check Filesystem Status' tab for the disk in question
  These are the results.

 

I am new to unRAID, and while I have perused some other threads regarding similar issues, I am a little unsure what exactly I should do next.

 

I see that there is a repair command (xfs_repair), and there is an option to rebuild this disk from the parity.

 

Which of those is most likely to preserve the data, or which should I attempt first?

(And do the results of the verbose test help guide that decision?)

 

Thank you for your help!

(I have attached the recommended diagnostics dump. Not sure if it's helpful for this, but the stickied post told me to.)

markus-pc-diagnostics-20180311-1348.zip

Edited March 29, 2018 by Ruthalas

[JorgeB]

10 minutes ago, Ruthalas said:

Ran the '-nv' command in the 'Check Filesystem Status' tab for the disk in question

Remove the n flag (no modify) and run it again, you might need to use -L but only if asked.

[Ruthalas]

5 minutes ago, johnnie.black said:

Remove the n flag (no modify) and run it again, you might need to use -L but only if asked.

 

When run without the 'n' flag, I receieve the following:

Phase 1 - find and verify superblock...
        - block cache size set to 223488 entries
Phase 2 - using internal log
        - zero log...
zero_log: head block 2114237 tail block 2112510
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

Should I now run it with the 'L' flag? (Like this: -v -L?)

Edited March 11, 2018 by Ruthalas
Removed incorrect syntactical highlighting from code block.

[JorgeB]

1 minute ago, Ruthalas said:

Should I now run it with the 'L' flag? (Like this: -v -L?)

Yes, you can also use -vL

[Ruthalas]

Thank you. I have started that, and will report back.

[Ruthalas]

That command has complete with these results.

 

Should I stop and restart the array (out of maintenance mode)?

[JorgeB]

Yes.

[Ruthalas]

Thank you! It looks like I am back up and running.

One question though-

Shouldn't I be able to access the data (via the parity disk), even if that drive is down?

[trurl]

4 minutes ago, Ruthalas said:

Thank you! It looks like I am back up and running.

One question though-

Shouldn't I be able to access the data (via the parity disk), even if that drive is down?

The drive wasn't down, it just had a corrupt filesystem. Even if you removed the disk and tried to access the emulated disk, it would still be a corrupt filesystem, and so unmountable.

 

So, that is the answer to your previous question about whether rebuilding from parity would be a possible fix. It wouldn't.

[Jimmy90]

On 3/11/2018 at 5:46 PM, johnnie.black said:

Yes.

Dear johnnie.black,

You're a Life Saver! This thread made my day!  I had honestly been pulling my hair for 2 whopping days here with this!

Thanks a Bunch!