trurl

Not familiar with your WD NAS. Was that a single disk plus a mirror of that disk? As far as data loss, Unraid and RAID both have parity, but it's actually the case that Unraid is less likely to lose your data than RAID is. Your discussion of split level is getting sidetracked by a different misunderstanding, Allocation Method. The default Allocation is High-water, and it is default for a good reason. It allows a user share to use multiple disks "eventually" but without constantly switching between disks. It will fill the first disk until the "high-water" mark is reached, then it will move to the next. Actually, it is a little more complicated than that, but that is the basic idea. This sounds like you think maybe it makes copies of each file on all the disks. This is definitely not the case, but maybe I misunderstand you.

There is a dump at the end of your syslog, not sure what that's about, but wouldn't hurt to do memtest. You have 2 different sized disks in your cache pool, and I'm not sure there isn't something wrong with it. The btrfs-info doesn't look right to me. I will ask @johnnie.black to take a look, but it is very late where he is so it may be a few hours before he will see this. Shouldn't cause your symptoms, but you have appdata, domains, and system shares setup wrong. All of these are created cache-prefer by default, but you have changed some of them, and they all have files on the array. I just want to note this here now for later correction.

👍

I see you also have VMs enabled. Are you running any?

Instead of just changing things to see if they work, decide on how you want it to work and maybe we can help you change things in exactly the right way to make it work. I don't know anything about Roon, but I suspect if you change anything in the container path for the data its database references, you will have to start over since that database won't know where anything is anymore.

Since it was an unclean shutdown parity check, it should be nocorrect. Might be useful to see if it thinks you have parity errors, though I'm not sure what the best course of action would be if it did. Do you correct parity when you know you have a bad data disk? On the other hand, it is possible the unclean shutdown would result in parity errors, especially if anything was writing to the array at the time. If there are parity errors, and they are real and not caused by problems reading that bad data disk, then relying on the parity for the later rebuild could be problematic. Any idea why the UI became unresponsive? I know there are a lot of threads on the forum where this seems to happen, but it is not the usual way for Unraid to work, and of course nobody bothers to post when things are going well. Has the parity check found any errors so far? Post a new diagnostic.

I think you must have some sort of controller problem, or possibly power. Your diagnostics don't even give consistent information about whether your disks are mounted or not. df shows only cache, vars shows all mounted. And shares says none exist, as does df. Disabled parities of course should have no effect on your data whether on disks in the array or in the cache pool. Nothing obvious in syslog beyond possible corruption of libvirt and docker images. And some problems writing parity and reading cache. Reboot and post another diagnostic. Those don't make any sense.

If "music" doesn't contain any data you can delete it from the Unraid webUI, and rename "MUSIC" to "music" also from the Unraid webUI. No need for Krusader.

Updating parity requires reading the data before writing it. See here: https://forums.unraid.net/topic/50397-turbo-write/

Have you done memtest?

Sounds like a browser problem. Did you try clearing cache?

From the syslog in those first diagnostics you posted: Mar 3 19:30:16 AlienBlood kernel: mdcmd (40): check nocorrect Mar 3 19:30:16 AlienBlood kernel: md: recovery thread: check P Q ... ... Mar 4 03:41:00 AlienBlood kernel: md: recovery thread: Q incorrect, sector=9867046256 Mar 4 03:41:00 AlienBlood kernel: md: recovery thread: Q incorrect, sector=9867046264 Mar 4 03:41:00 AlienBlood kernel: md: recovery thread: Q incorrect, sector=9867046272 ... From the syslog in these latest diagnostics: Mar 6 21:30:34 AlienBlood kernel: mdcmd (40): check correct Mar 6 21:30:34 AlienBlood kernel: md: recovery thread: check P Q ... ... Mar 7 17:21:33 AlienBlood kernel: md: recovery thread: Q corrected, sector=9867046256 Mar 7 17:21:33 AlienBlood kernel: md: recovery thread: Q corrected, sector=9867046264 Mar 7 17:21:33 AlienBlood kernel: md: recovery thread: Q corrected, sector=9867046272 ... So, as you can see, that first parity check (nocorrect) found parity errors, but didn't correct them This latest parity check (correct) found those same uncorrected parity errors, but it is correcting them. When if finishes, run a non-correcting parity check and you should get zero parity errors.

Yes

If it can't read config/network.cfg on Flash it will give you default settings.

Cache is part of user shares. Depends on the settings of each user share how it uses cache, but any folder in cache is part of a user share.

I power down the eSATA enclosure, but I don't have to stop the array to get this "hot swap" to work.

Why not just remove that questionable disk and forget about it then, at least for now. You have plenty of free space on the other disk, and you said you had backups of the important things. You can preclear the disk as I mentioned before to see if overwriting the whole disk will get those pending sectors reallocated and if that works you can add it again.

/mnt/cache is part of /mnt/user. Ultimately, they are the same path, or can be. In this case, since the rest of the paths are different, you don't get the "User Share Copy Bug". But, the Linux command for move and the Linux command for rename are the same, mv. So, when you do it like that, it just renames the path on the same disk instead of actually moving it to another disk. Instead of moving, copy from source to destination, then delete from source.

See here:

What were the source and destination paths when you tried to move it in Krusader?

If you preclear the disk it will be even more impossible to recover anything from it since it will be completely overwritten with zeros. Let's try it this way: Stop array Unassign disk1 Start array with nothing assigned as disk1 Post a new screenshot of the array disks, and new diagnostics and we will see where to go from there. Disk1 will be emulated from the parity calculation by reading the rest of the array. Probably the emulated disk will still be unmountable, but we can try to repair the filesystem on the emulated disk then go from there. If we can repair the emulated disk, then we can try to rebuild the disk. Since the rebuild will write the entire disk maybe that will force the pending sectors to be reallocated.

Look again. You should be seeing a SMART warning (thumbs down) on disk1. And you should setup Notifications so you don't get into this situation again. I don't understand. The SSD is already assigned to cache. If you are talking about my other note about those shares that should be on cache, forget that for now. You can but you will lose everything on it. The disk has pending sectors. It might be possible to get them reallocated by preclearing it, but you can't do that with it in the array. If you don't care about anything on the disk you can remove it and set a New Config without it and rebuild parity. Then you can try preclearing it to see if you can get those pending secctors reallocated.

Why did you start a new thread? I have merged your threads.

In his sig, but viewing sigs is disabled by default unfortunately. Click on your user name at the top right of any forum page, select Account Settings. There you can enable sigs and set your own sig.

Does seem slow, but there is something about this that isn't making sense. According to your diagnostics, the share named Backup is cache-yes, so those writes would be going to cache, but you say you are writing to the array.