trurl

By default, there are 3 user shares used by Dockers and VMs. These are appdata, domains, and system; appdata is the working storage for your dockers. domains is where your VMs are stored, and system is where docker and libvirt images are stored. These shares are set as cache-prefer by default. So, they will be stored on cache if cache has space, and moved from array to cache when cache has space. You want these shares on cache so your Docker and VM performance will not be affected by the slower parity writes, and so your Dockers and VMs won't keep array disks spinning, since these files are typically in use. But, mover can't move open files. So, to get these moved to cache, you have to disable Docker (Settings - Docker) and VM (Settings - VM Manager) services, then run mover. After you get them all moved to cache you might consider setting all these shares to cache-only if you are sure you won't fill cache (Settings - Global Share Settings - Cache Settings - Min. free space). You can see how much of each disk each user share is using at Shares - User Shares and doing Compute... for a share, or the Compute All button.

Disk 3 has disconnected. You probably disturbed the connections when you replaced the disk. Are you sure there was really something wrong with that original disk5? Disabled disks have many causes and bad disks are often not the cause.

Since you didn't you will have to add it after parity build and

The OS installs itself into RAM from the archive on Flash each boot and runs in RAM. Think of it as firmware but easier to work with. You should use the SSD as cache.

Yes But, if you enable dockers or VMs before you install cache you will have a little work to do to get those moved to cache. Not a big deal just something to work through.

https://unraid.net/pricing

Since nobody has posted Diagnostics, here's how. Go to Tools-Diagnostics and attach the complete Diagnostics zip file to your NEXT post.

Are you having problems getting Diagnostics, or do you not know?

Do you have a backup of Flash?

I recommend not even sharing drives (including cache) over the network. If you want to copy or move files from one disk to another then you should do that on the server with the command line, the builtin mc (Midnight Commander), or Krusader docker. And you shouldn't make a copy of a user share file on multiple disks as you are suggesting here: Moving between disks is OK, or copying to a different share is OK. Copying to the same share on another disk is not OK, and moving or copying from a user share to a disk or a disk to a user share is not OK.

Never seen that before. You might ask on the Unassigned Devices plugin thread.

It sounds like you mean exactly what he said you shouldn't do in this part you quoted: Or as I explained just above your post:

If the disk is disabled you have to rebuild it, even though it is empty, since it isn't in sync with parity. Either that or rebuild parity. But first you have to fix whatever is causing it to get disabled. Syslog is only since reboot, and so isn't telling us what happened before. SMART for the disk looks OK. Check all connections for all disks, power and SATA, both ends, including any power splitters. You might also setup Syslog Server so you can get your syslog saved somewhere you can retrieve it after a reboot: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=781601

Now he has posted all the contents. I am going to delete all of those. It is way too much trouble for us to download all of them separately. You need to figure out how to get us the zip file. Help us help you. Apparently johnnie was able to get it before you edited your post, but we need the zip file, and you need to figure out how to get it and post it. I guarantee your Mac isn't downloading a folder. Downloading a folder isn't something you can do from a web page. It is downloading a zip file, and opening it for you. You need to find the zip file it's downloading.

Nothing downloads a folder. Your mac is probably configured to automatically open the zip file. Go to wherever your downloads go and you will find the zip file.

NO benefits, nothing but hassles.

Unraid assigns disks by their serial number, assuming the controller passes that. If you aren't using RAID controllers (not recommended) it should just work.

I guess New Config would have to be done then, but if you're rebuilding parity anyway might as well get the added disk as part of that parity build instead of waiting for it to clear. Since it's been a couple of days now probably something has already been done.

Sounds like a question for the plex forums

After your dramatic title, I was expecting something worse. This is a reasonable speed. I know you aren't complaining about this, but Mover is intended for idle time. You might find it better to run mover less often and not cache some of your user shares. Do you need cache speed for all writes? I cache very little, since most writes to my server are scheduled backups and queued downloads, so I am not waiting on them to complete anyway. Haven't looked at the diagnostics. Are you actually having any problems other than the expected slower parity writes?

Parity swap isn't exactly a shortcut for the standard way. It really is intended for the situation where you need to replace a data disk, but you don't want to be forced to buy a disk as small as parity. It allows you to copy parity to a larger disk, then replace the data disk with the old parity and rebuild it. So it lets you get a new larger parity disk instead of making you buy a disk as small as the original parity to replace the data disk. Since you aren't replacing any disks, it doesn't apply at all. And since you will be rebuilding parity anyway, might as well rebuild it with the added data (former parity) disk already in place. As noted by jonp.

https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=545988

For future reference, here are your disk assignments from that syslog you posted: Apr 2 21:28:36 Tower kernel: mdcmd (1): import 0 8,16 2930266532 TOSHIBA_DT01ACA300_Y32A1XJGS Apr 2 21:28:36 Tower kernel: md: import disk0: [8,16] (sdb) TOSHIBA_DT01ACA300_Y32A1XJGS size: 2930266532 Apr 2 21:28:36 Tower kernel: mdcmd (2): import 1 8,32 2930266532 TOSHIBA_DT01ACA300_23DEPTDGS Apr 2 21:28:36 Tower kernel: md: import disk1: [8,32] (sdc) TOSHIBA_DT01ACA300_23DEPTDGS size: 2930266532 Apr 2 21:28:36 Tower kernel: mdcmd (3): import 2 8,48 2930266532 TOSHIBA_DT01ACA300_23DEZDKGS Apr 2 21:28:36 Tower kernel: md: import disk2: [8,48] (sdd) TOSHIBA_DT01ACA300_23DEZDKGS size: 2930266532 disk0 is parity, then disk1, disk2 are the only data disks, and there is no cache disk. Is that correct? Refer to the upgrade wiki I linked earlier. Do the 64bit test described in the beginning to make sure you can upgrade. Report back.

Make careful note of your disk assignments, Most especially your parity disk(s). Go to Tools - New Config and assign your disks as they should be. Be very careful to not assign any data disk to any parity slot or it will be overwritten by parity. Before starting the array, check the box saying parity is already valid. Then do a non-correcting parity check just to make sure everything is good.

Is this affecting only your parity drive?