Note that repair of disks 2, 4 have resulted in lost+found folder on these disks. After disk3 repair it may also have some.

 

Since all top level folders on array or pools is automatically a user share named for the folder, you have a lost+found share.

 

We can take a look at how much after disk3 repair.

Ok, so it's running... I think. I clicked the button, the log started filling. then the entire screen broke the connection. now when I refresh it stops loading the page right before the logs would show up. Refresh, same result. Go back to main and click disk 3, same result. Do I just leave it alone for the night and check it again in the morning?

19 minutes ago, ericup said:

the entire screen broke the connection

Are you using a browser on another computer to access? Or a monitor connected to the server?

Other computer. the server is 100% headless. Webui still responds, it's just that screen that acts up.

I guess just leave it alone for a while.

1 hour ago, trurl said:

Note that repair of disks 2, 4 have resulted in lost+found folder on these disks

Reviewing the thread, I don't think we actually did repair on disk4. Must have been done previously.

So I checked on it remotely with my phone while at work and it's still doing it. just not showing anything under the "check filesystem" header. Should i try stopping and restarting the array, or rebooting?

Also. not sure if it is important but the device auto-spundown, Indicating whatever it was doing is done.

Hello and welcome back,

I have tried a few things, restarting the array, removing the device from the array and emulating it (shows disk missing fs still unmountable), SSH and try xfs_repair (gave issue about verifying superblock then spiraled to dots.)

when the drive is emulated I still have an issue, implying parity is corrupted. Correct?

I have no idea what "bad primary superblock - bad magic number!!" means then it fails to verify the secondary superblock candidates and just starts spitting dots at me.

Go to User Shares, click Compute... on the lost+found share. Post a screenshot and new diagnostics.

19 hours ago, trurl said:

Reviewing the thread, I don't think we actually did repair on disk4. Must have been done previously.

I see now that you said you did that disk in the first post.

Lost and found shows data on 2 and 4. 3 is still unmountable. I am begining to wonder if I need to drop it from the config and just 000 it as any critical data is backed up.

tower-diagnostics-20250117-1801.zip

2 minutes ago, ericup said:

Lost and found shows data on 2 and 4

I already knew that. I wanted to know how much.

 

16 minutes ago, trurl said:

Go to User Shares, click Compute... on the lost+found share. Post a screenshot

 

Do Compute... on the system share also. It seems to have some data on disk2 and not all on cache as it should.

So I have no clue what the next step should be. Advise?

Check filesystem on disk3 again without -n and post the output

7 hours ago, JorgeB said:

Check filesystem on disk3 again without -n and post the output

Everytime I try to see the output the webpage crashes. I think there is like a ram limit or something that is killing the page.

junking entry "jquery" in directory inode 1048474076
corrected i8 count in directory 1048474076, was 4, now 3
xfs_repair: rmap.c:701: mark_inode_rl: Assertion `!(!!((rmap->rm_owner) & (1ULL                                             << 63)))' failed.
Aborted

This was the last few lines of the output. I managed to get it by rebooting then running the command from ssh.

1 minute ago, ericup said:

running the command from ssh.

What command exactly?

 

If you can run the correct command from the command line you should be able to redirect its output to a file.

Sorry this was using "xfs_repair /dev/sdg1" How should I modify it to output to a file? then how do I access that file when in maintenance mode?

I am reaching the point of exhaustion with this problem. Since I have a good backup and it is likely mostly *arr data anyway will formating the drive make it functional again? even if blank.

46 minutes ago, ericup said:

using "xfs_repair /dev/sdg1

You must use the md device when working with a disk in the array or you will invalidate parity. But according to your most recent diagnostics, sdg was not assigned to the array.

 

So, disk3 is actually missing, but still emulated and unmountable.

 

Have you been trying to check filesystem on an unassigned disk, and not on the missing/emulated disk3?

 

 

I have been doing this on the emulated disk. This last attempt was on the physical disk using ssh because the webui kept failing.

Can I just format that emulated drive and it be functional again even if it's blank?

1 minute ago, ericup said:

Can I just format that emulated drive and it be functional again even if it's blank?

Do you want the physical disk back in the array? If you format the emulated disk, then reassign a disk3, it will do a complete rebuild of the empty disk onto the reassigned disk3.

Well other than corruption the drive and having 4 years of run time it is functional is it not? If I can fix the corruption the device will be fine. I am getting paranoid the longer this goes on as parity2 has been accumulating smart errors.