Defuse

I have an SSD cache with spindle drives behind it. Network connection is 10g. What I am observing is that if I copy movie.mkv to unraid to a folder that already has movie.mkv over SMB and choose to replace the existing file the transfer will write the file to the share disk as opposed to the cache drive if the file did not exist already. I see the performance drop very quickly during the copy in this manner. From 500/MBs on cache to 70-100/MBs on share disk. This has been happening all along and I am just now getting around to asking about it. Usually what I have been doing is removing the old files first so that I can take advantage of the 10g network and SSD write performance. Being able to just say, yeah replace the existing would be even better.

Turns out it was a bad SFP. Thanks for the help JorgeB

Ahh good catch. The link is only running at 1 GB. Now I need to figure out how to fix that..

I recently upgraded my server to a ROG STRIX X299-E Gaming and i9-7900X. The NIC I use is an Intel 82599ES 10Gig. I also upgraded the cache disks from a 500GiB setup to a 1 TiB setup. Still SATA based SSD's though. Samsung 870s to be specific. On my previous setup I was able to copy data from my workstation that also uses 10g network at 800-900 MBps without issue. Now after my server hardware changes I am only able to achieve 100 MBps throughput. I am having a hard time identifying what could be causing this.

Yep that was it. Thanks for the help!

On a few of my shares when I use the "Compute" option it shows that the share has 0KB of data on some disks. In the attached photo I am expecting this result but I am curious as to why it's showing 0KB on some disks but not all. Looking at other shares I see similar results. Is this a problem? Is there a way to clean it up so that if there is no data for a share on a disk it does not show that disk?

Ah bummer. I figured it was a tall ask but thought it might be worth a shot. We do this kind of stuff at work with Isilon and Unity SAN's and wanted to have something similar at home. Thanks for the info though I appreciate it.

Should I pose this question in a different forum?

I primarily use Unraid with Plex and Jellyfin docker containers to host my media collection. My primary media share that stores the Movies and TV shows is limited to only spindle disks as the capacity is around 40TB. Jellyfin can utilize NFO files for metadata which I am wanting to leverage for my collection. However, it does not have the ability to store the NFO based metadata in a location other than where the media file is. Since the application cannot support my desired configuration I am looking for a solution at the host (Unraid) level. Essentially I want to be able to present the Media share to Jellyfin so that it can read and assume that all of the media and metadata files are in the same place but on the backend host have the media files be on spindle drives and the metadata files on an SSD share. I "think" this is something that can be achieved with some kind of symbolic link but I have never actually worked with them before so I don't know what their benefits / limitations are. As a bonus if I am able to setup this configuration I would like to be able to set the media share that stores the actual content as read-only but allow the metadata share to be read/write which would allow Jellyfin to create new NFO based metadata as content is added. My current share / folder structure looks like this. Media Movies movie.mkv movie.nfo movieart.png I "think" what I will need to do to satisfy my configuration is something like this. Media <- Share that is hosted on SSD and is allowed as Read/Write Movies <- Linked share that is a read only reference to a spindle drive share Movie.mkv <- Hosted on linked share that is read only movie.nfo <- Hosted on Movies SSD share movieart.png <-Hosted on Movies SSH share

Ah that is a good idea as I do plan to put the current 18TB parity drive back in to the mix as a data drive. Thank you for the tip!

I am getting ready to make some hardware changes to my disk configuration and I am looking to for some tips. I currently have a 10 disk array with a single 18TB parity drive. My end state will be a 10 disk array with two 20TB parity drives. Two disks in my array are 4TB drives that I plan to also upgrade with 20TB drives. Essentially the goal here is to get all 4 20TB drives in place without losing any data. I "think" the appropriate plan of attack is to add a single 20TB drive and assign it in the secondary parity slot. Let the array do whatever it needs to do then replace the 18TB parity drive with a 20TB parity drive, then let the array do what it needs to do to be back to a normal state. For the two data drives I presume it's safer to replace one at a time but I "think" I could replace both at this point since I now have two parity disks correct? Also, for the actual hardware connections. I am also presuming that it is a good idea to separate the parity disks across controllers for redundancy. Is there a compelling reason not do this?

It shows up in Settings > Scheduler. Interestingly. I started checking this out because I had an upcoming parity check scheduled and wanted to make sure that the settings were correct as this was the first time I was using your scheduling plugin. When I originally set it up I did not see any warnings. The parity check started, there was an update to the parity check scheduler plugin which I performed while the parity check was paused because of the schedule enforcement that I had set. After the update this warning presented itself. The parity check finished later that day but I never received a notification of that until I updated the plugin again earlier today. I thought that timing was a bit odd so I thought I would share. I have also attached a screenshot of the message as I see it.

Hello. After the latest update I am getting a similar Warning as I was before. The location is a bit different but wanted to share what I am getting. Warning: session_start(): Cannot start session when headers already sent in /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.helpers.php on line 115 This is on version 6.9.2

Yep, looks good now. Thank you for the quick fix!

Thanks for the response. If it helps I am running 6.9.2.