daniel.boone

Thanks, I actually have done the parity swap in the past. If I recall for at least prior versions the system was unavailable for a portion of the process. My first priority here was uptime so I wasn't ready to commit to that approach. I have some experience with the product. I think my first version of unRaid was 4. Even so I still ask here when things are not clear to me, especially on new functionality. What threw me here was the xfs v4 upgrade. As mentioned that was super easy, fast and I experienced no down time. My parity drive 2 upgrade completed yesterday. Over the weekend I'll pull the oldest drive, rebuild and with that all changes will be done. Drives are now on the latest xfs version. I'll have completed 3 drive swaps at that point. I have enough free space that I can wait for sale prices on a drive purchase. Thanks all for the guidance.

Started Parity 2 upgrade/rebuild is underway. Its taken a bit of time to juggle data around but its done. Once this completes I'll have dual parity of the same size. I had a mismatch previously which kept me from going beyond a certain size. @trurl, Its exactly why I had to upgrade the 2nd parity disk. Parity build takes a long time so I anticipate the last of the current disk upgrades to happen next week. I've done so many disks swaps at this point that process doesn't worry me. Quick recap.. Problem was dual parity drives of different sizes. Latest upgrade identified 2 xfs v4 disks. I was planning to fix my parity but the xfs disk support issue added a wrinkle I had not previously dealt with. I wasn't sure which approach was best for uptime while minimizing the disk wear. I anticipated multiple parity builds during this. I could have not been more wrong. My solution.. I started by upgrading an array disk, non v4, to make room. Moved data off one of the v4 disk, reformatted, repeated process for for the 2nd xfs v4 disk. I was pleasantly surprised that formatting was quick and did not impact the parity. Once dust settled I proceeded to upgrade my smaller parity disk. That leaves one disk to upgrade after parity is recreated. Process took time but my array has been running the entire time minus the reboots/shutdowns I had to do during the disk upgrade process. Wish you all well. Thanks for reading. Consider this one done..

I think it's important to share findings with the community. I did figure out a way forward. Yesterday I proceeded to reformat the smaller of the two v4 xfs disks. Disk had already all content removed. It was quick, parity was not touched. Completed without issue. It took seconds. Last night I started to move data off the 2nd disk. It will be done by the time I get home later today. I'll reformat following wiki instructions. Same process I did for the smaller disk. That fixes the v4 issue. I'm still on the fence on selecting the parity upgrade or parity swap. I need to chew on that a bit. I'm learning toward upgrading parity. I suspect that will allow for the most uptime. I'll just disable mover until it's done. I can upgrade the smaller data disk once parity build completes. Whatever I decide it's happening tonight.

I’m running on v7.2.4 pro with dual parity drives and no slots left. I have a couple of items I wish to address. Looking for best approach guidance. I’m comfortable replacing disks. I’ve read the xfs v4 upgrade process. Recent upgrade identified 2 v4 xfs disks. I’ve started to move data off those with the intention of reformatting them. I have a parity disk I wish to upgrade and one of those xfs disk will get swapped for larger disk. I also keep cold spares handy. I do not need to reuse what I plan to upgrade. Space is limited but I’m sure I can juggle. I have multiple backups of data I can’t lose so not worried there. Minimizing downtime is my primary concern. I would typically run mover to satisfaction, shut down, pull disk, add new disk, start array, rebuild disk and repeat as needed. Just the xfs issue has me questioning the approach . I’m thinking best approach is move data off xfs disks, change format of both xfs disks, let that process complete and then replace parity, then replace the small old xfs disks. What do the good people here suggest? All advice is appreciated, thank you for reading.

It appears there is a new rate limit imposed on api calls. Now seeing 'Received oauth token was invalid.' when configuring an import list. https://forums.trakt.tv/t/has-the-trakt-api-rate-limit-changed/40054

Appreciate the help, figured out webgui could be started with this command '/etc/rc.d/rc.nginx reload'. It came back with 'Nginx is not running' so I ran '/etc/rc.d/rc.nginx start'. Daemon started without issue. With that I got the webgui back and was able to correct the configuration. Rebuild is running once again. Thanks again, post marked solved.

I was pretty sure I have the tuning disabled for rebuilds. Diags posted Thanks

Appreciate any guidance here. Situation went sideways a bit. Don't want to do anything rash. I'm long time user. I've done a number of disk rebuilds in past. Never faced this behavior. notice I had a failed disk so snapped a quick pick of the drives. Stopped Docker Shut down replaced the disk booted system assigned the replacement disk on the old failed disk slot it did show the disk was to be rebuilt so I started the array/rebuild process This is where it got weird. I was expecting a warning about the format but upon the screen refresh I got a refused to connect, this site can’t be reached. I am using its ip. I can ssh to the server. I can see my apps are running. Server appears to be functioning to some degree. From the log I can see Oct 29 10:42:41 Tower Parity Check Tuning: Parity Sync/Data Rebuild detected .... Oct 29 10:51:21 Tower emhttpd: spinning down /dev/sde Oct 29 11:30:07 Tower kernel: mdcmd (38): nocheck PAUSE Oct 29 11:30:07 Tower kernel: Oct 29 11:30:07 Tower kernel: md: recovery thread: exit status: -4 Oct 29 11:30:12 Tower Parity Check Tuning: Paused: Parity Sync/Data Rebuild (4.5% completed) My questions are how long before I see the rebuild percentage increase. It seems to be sitting at 4.5%. Should I have seen a popup confirming the drive was to be reformatted? I selected start array and the screen went blank. I'm not seeing any rebuild entries after the "4.5% completed". Is there a way I can confirm rebuild is actually happening without the gui? I have 20+ drives so rebuild would take 24 hours or so. I'm running 6.11.4.

Seems like a big hurdle at first but its not too bad. Motherboard was on the table so flashing there was easy solution for me. Now I'm not in the middle of upgrade. I just received my 3rd HBA yesterday, another PERC. I have all the time in the world. I'll put the time into flashing using EFI boot. Eventually this is all we will have.

Flashing HBA card with the my new MB, ASRock Z690 Pro RS didn't go well. I found it impossible to boot into FreeDOS. Contacted ASRock and they told me to enable CSM but I'm using the igpu so the option was grayed. Took forever to get them to understand. Multiple contacts over a 2 weeks. They always got stuck on 'don't need DOS to flash the MB' so I moved on. I used my old MB to flash my h310, predominately followed Fohdeesha's guide. You wont have trouble finding that. Did lots of reading reading including sanderh.dev UEFI flash method. My advice is to boot into the necessary sessions. Get comfortable switching boot methods. Learn to list your card(s), get your SAS address and backup the old firmware before you even consider flashing. I used FreeDOS since UEFI commands didn't respond as expected. You do not want to get into the middle of flashing to find commands not working. Flashing is a bit scary but super easy. Your card should be even easier if its a LSI branded card. I'd follow the vendor flashing recommendations.

I'm running that combo (i7) with IT mode flashed IBM and Dell HBAs. Zero issues so far but its only been a month. The month included dual parity upgrades along with a disk rebuild and installation of the H310. It was fine with the IBM and Supermicro HBA as well. Both from my old system. Swapped out the Supermicro because of the Marvell chip.

Just for a test I added handbrake and re-encoded a couple of uhd vids to see the impact. With a direct stream of a high quality 1080p mkv on plex, the re-encode got memory up to 40% of the 32GB I have. 16GB works but during ripping ram consumption would be toward the high end. I tried a couple of different settings, no real change from that perspective. CPU on the other hand got up to 90ish%. No impact to the video playing but I'm on a 12th gen i7. Please post what your experience is like. It would help others considering a similar combo as yours. Originally I was considering a nuc for plex and leaving my old system in place.

Ok your not transcoding, your ripping media. That processor is fine. Its the first version with HEVC support. I'd bet limited but x264 is well developed. That's a great place to start if your not hot on 4K. Would more cores be faster, sure but nothing wrong with the processor there. I'd be happy with that processor Ram may needs a bit of a bump but that should not stop you from using what you have. This goes without saying but don't put your job at risk. I hope my suggestion on the ram wasn't taken any other way. I don't run makemkv or handbrake on my server so can't speak to ram reqs there but should be easy to find online. Both of those apps have docker versions in community applications. I've started on a 1st gen HP media vault and a laptop. I probably ran a pair of 300GB drives at that time. Many upgrades later my system looks nothing like any of its predecessors. There is always a better system around the corner. Run with what you got, If your happy then your done. Save funds for disks.. That's where most of the money goes. If you dead set on spending on ram I'd look for a deal on ebay for a 7th gen or better processor with the ram you want. You want to move up not backwards. You already have a 6th gen processor so no point in getting the same if your not happy.

From Plex site "1080p (10Mbps, H.264) file: 2000 PassMark score" so it might be rough for the number of transcodes your shooting for. I'd say that 6700 is a great place to start. Average CPU mark listed as 8083. CPU is plenty for unRaid. If I were you, assuming the office is feeling charitable, find some ram in the pile to add to your system, just to get you to 16GB. Try the system as is for Plex otherwise. I would not invest money into that system if it doesn't make you happy at that point. You can always pull the video card for testing later. I'm using the igpu for transcoding without issue but I'm running a new processor. I also have 32GB of ram just consumption is at 30% regularly. I can't recall it ever going over 35%. I run about 10 containers but 0 vms just to give you an idea. For me the biggest change was the use of nvme for Plex. The Plex display was sluggish before that. Good luck with the build.

Wondering how the community is approaching this? I've been looking at reverse proxies but it seems those are intended to make microservices resolvable publicly. While purchasing a domain might make it easier I'm not looking to share these publicly. My goal is to make a series of docker services more accessible to family members. I found this recently, no association to me, https://github.com/cristianoliveira/ergo. Wanted to see how others have approached this problem.