Replaced Drive Unmountable: Unsupported or no file system

[ToXIc]

Hi there, so had a power failure and when the server came backup. disk2 stated Unmountable: Unsupported or no file system. I had another HD just sitting on the systems as a cold spare i precleared previously (sitting in unassigned devices) so i decided to just swap them. So i stopped the array swapped the disks and started it back. 
the array started the rebuild process and started doing a bunch of writes to the disk. However the disk still showed Unmountable: Unsupported or no file system. So i decided to let it do its thing maybe it will be fine after, because it already stated that previous data will be lost if i start the array. But there was that format message at the bottom where you start and stop the disk. 

im unsure what to do as im afraid of data loss. 

[itimpi]

Rebuilding a disk does not clear an unmountable status (instead a rebuild clears a 'disabled' status).    Handling of unmountable status is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.

[ToXIc]

2 hours ago, itimpi said:

Rebuilding a disk does not clear an unmountable status (instead a rebuild clears a 'disabled' status).    Handling of unmountable status is covered here in the online documentation accessible via the Manual link at the bottom of the Unraid GUI.  In addition every forum page has a DOCS link at the top and a Documentation link at the bottom.

where i dont know to start with all this is because i foolishly changed the drives instead of trying to repair the filesystem. 

[JorgeB]

Check filesystem for that disk, run it without -n.

[ToXIc]

1 minute ago, JorgeB said:

Check filesystem for that disk, run it without -n.

for the one i placed into disk 2 correct? not the original? 

[JorgeB]

Correct, but keep the original untouched for now.

[ToXIc]

10 minutes ago, JorgeB said:

Correct, but keep the original untouched for now.

ok will do thanks. i had it in maintenance mode but some some reason this morning its running a parity check. so may have to wait. 

[itimpi]

54 minutes ago, ToXIc said:

for the one i placed into disk 2 correct? not the original? 

When you do a rebuild the process should just make the physical drive match the emulated one (which is why the process does not fix the 'unmountable' status) so at this point both drives should (at least in theory) be identical.

[ToXIc]

On 6/19/2024 at 11:16 AM, JorgeB said:

Check filesystem for that disk, run it without -n.

got this result 
 

Quote

Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... 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 run it again with the -L option or do something else? 

 

Edited June 21 by ToXIc

[JorgeB]

6 hours ago, ToXIc said:

Should i run it again with the -L

Yep

[ToXIc]

ran with -L got the following 

Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... ALERT: The filesystem has valuable metadata changes in a log which is being destroyed because the -L option was used. - scan filesystem freespace and inode maps... clearing needsrepair flag and regenerating metadata sb_fdblocks 167881827, counted 174696743 - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 3 - agno = 2 - agno = 1 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:49084) is ahead of log (1:2). Format log to cycle 4. done

stopped and started the array and its showing data! soo happy! thanks for helping.. was so terrified worrying about losing data 

[itimpi]

You should check to see if you have a lost+found folder with numeric folder/file names as that is where the repair process puts any files/folders for which the directory entry could not be found to give it the correct name.   If not then that is a good sign.

[ToXIc]

36 minutes ago, itimpi said:

You should check to see if you have a lost+found folder with numeric folder/file names as that is where the repair process puts any files/folders for which the directory entry could not be found to give it the correct name.   If not then that is a good sign.

turned on the smb share for the disc and no lost+found folder 

 

[JorgeB]

That's a good sign, everything should be fine.

[ToXIc]

thanks guys!!