SSD

Some motherboards look for a drive to slap an HPA onto. You might have ongoing issues. Suggest disabling. But if ever the battery goes or you reset the settings, the old default setting comes back, and you can have troubles again. I believe gigabyte changed the default to be disabled.

@bombz - You will need to do a new config to remove the old drives and add the new one. Don't delete the data from the 2 500G drives, and you'll have a backup just in case you have any issues with the external. I do recommend a preclear to test out any new drive, but technically you would not need to preclear it. When you did a new config, parity is rebuilt. What you could do is this. It's what I would do. You don't need the external. Preclear the new 4T drive and second parity disk (if you have). (Recommended but not mandatory) Shutdown server. Remove one of your 2 500G drives from the server, and add your 4T drive. Boot server. Do a new config but keep configuration. Add the 4T add as a data drive and omit the 2 500G drives from the array configuration. (I'd also omit parity, but that's up to you. Without parity you'll be able to copy faster). Change filesystem to xfs on the new 4T drive before starting array. Start the array. (Let parity build if you added parity.) Format the 4T drive. Use unassigned devices and mount the 500G drive. Copy all the data from the 500G drive to the 4T. After the copy, shutdown the server. Swap the 500G with the other one. Boot the server, start a array, use UD to mount the other 500G, and copy other 500G drive to the 4T. Shutdown the server again. Remove the second 500G. I think you said you wanted to add second parity drive. This would be the time. Otherwise just leave slot empty. Boot the server. Before starting the array, add your parity disk to the config (if didn't do before), and your second parity if you are adding it now. Start the array and parity(ies) will build if you added.

@bombz - So it sounds like you are completely full in terms of drive slots. So you want to copy data from 2 500G drives to an external drives, and then add a 4T disk that you'll format as xfs. This sounds like a reasonable approach. It will require rebuilding parity to remove the 500G disks and incorporate the new 4T disk containing data. Swapping add-on controllers is seamless. UnRaid recognizes drives by serial number. So if you remove the old, attach the drives to the new, and boot, all the drives will be assigned to their proper slots as though nothing had changed. (Obviously connecting everything securely and not disturbing the drive cabling of other drives is critical to not causing drives to drop offline). Related to ports to avoid I am confused. The SuperMicro add on controllers that use the Marvell chipset are problematic, but motherboard ports that are provided from the Intel chipset or non-Marvell chipsets are fine to use. Your post made it sound like you were trying to avoid using regular motherboard ports but maybe I misunderstood. I do suggest planning for an empty slot as it is useful in some recovery scenarios. And comes in handy for preclears as well. It is also needed to convert from rfs to xfs.

The "U" is tilted and gives me impression of lack of precision. I draws the eye, but maybe in the wrong way. But I do like the linked U and N looking like a chain. The stacked drives on the "I" don't really come across as anything disk oriented. The D looks funky. THe "un" sort of gets lost. Heavy use of stripes - when unRAID does not stripe data. Maybe not a good fit. I do like tagging with Virtualization. With VM pulling as much or more attention than NAS function, a tagline that pulls it all together might be helpful. "The Ultimate NAS/VM/Docker Platform."

The expander can be mounted anywhere, inside or even outside the case. Just needs power and SAS feeds from HBA - and to not short out. It does not need to plug into a slot, although that is a convenient place as it supplies power and avoids need to mount it somehow.

Thanks @dmacias!! I didn't remember I had loaded Python through nerdtools - thought it was stock. Now I remember where it came from! But I just installed "pip" and it installed the pyquery package like a champ! Too late to play with it tonight, but will have a go soon and report back. Thanks again!!

Other thing to consider is space to do any type of file recovery operation. The recommends minimum free space setting is 2x the size of the largest file on the disk. That is room for one more file to copy + room to recover a file. Like I said, this is bare minimum.

I am on unRaid 6.4rc6, and the python version is 2.7. Not sure what version comes stock on later RCs. I've had no reason so far to try to move to Python 3. THANKS!

@dmacias Hope this is not out of bounds for the devpack team, but I have been playing with Python and would like to install a python package. I found it referenced in a pretty cool script that will create an IMDB category in a Plex DB for the top 250 movies of all time (any that you own). It scrapes an IMDB web page and parses it with a Python package called pyquery. I would like to run that Python program and have some other uses as well. Here is a link to the script https://gist.github.com/shariat/313795d59931c4d128d2 You'll notice it contains this line: from pyquery import PyQuery as pq And here is a link to info on pyQuery: https://pythonhosted.org/pyquery/# And here is a link to SlackWare packages for Pyquery. (Notice it has dependencies that have dependencies ... probably need 5 or 6 packages to satisfy all those.) https://slackbuilds.org/repository/14.2/python/pyquery/ Anyway - I am a bit clueless how to get this installed in unRAID. I DLed the packages and tried to figure out where to put them and how to make them do their thing. It all looked so easy! I unpacked them, tried pkginstall, and coping things here and there. But I didn't have the special sauce to make them dance! They just sort of stared and me and laughed . Any help appreciated!! And if it could be added to the DevPack, that would be awesome! Thanks!!

Assuming you installed the Docker and re-established your libraries. Virtually everything in Plex is run from a database which assigns ID numbers to each item. These IDs will be totally different between your old database and your new database. Even the library ID will likely be different. It would be much easier to find your playlist settings and just re-establish them in the Docker.

@johnnie.black - If a file is corrupted, it seems you are totally blocked from accessing that file (for partial recovery). Is that true? To others considering what filesystem to use and like this feature, some people run tools that capture md5 or similar checksums with XFS. It's not real time checking, which has advantages and disadvantages. I run something home grown, but there are tools in CA that you can install. When I decided on xfs I was a little concerned that btrfs was not able to report free space accurately. The fact that it was more easily corrupted with a hard shutdown, and did not have nearly the user base of xfs were also factors. Also never realized why it needed ECC memory morso than any other filesystem. All this made me feel it was more fragile than xfs. I'll try beta this and beta that, but for my filesystem I definitely am very very conservative. I was bitten by a file system bug in RFS, that was losing users in droves, and, going forward, I want rock solid with huge install base including production systems. Those guys will make darn sure that the filesystem updates are extremely well tested. I continue to monitor what Johnnie has to say about btrfs, and positive experiences of other users. Have not read horror stories like I was worried would emerge. But I'm sticking with xfs, for now anyway. But I do kick the btrfs tires from time to time.

On the Plex server configuration, you can select whether to enable or disable remote access. Is that not sufficient?

1 - After the initial install, no reason to reduce the core count for normal updates. If you ever have to boot from the .ISO image again, it might be needed. 2 - this is personal preference to a degree, but the best practice is to keep the vdisk lean and store your data on the array, or in an unassigned device. The vdisk contains the OS and installed programs only. The vdisk is easier to back up and all your data is externalitied, with the important parts parity protected. 3 - Not a Mac guy, but I'd experiment with options to externalize. You can create a second vdisk if desired. For my Windows VM, I wanted to keep my TEMP folder off the SSD, so created a vdisk on an unassigned spinner. (Windows was not happy with TEMP folder on a network drive, even if mapped to a drive letter.) But if you want the iTunes library on your OS vdisk, you can certainly do that. I just like to be able to compress and backup my image file, and having a 1T image would be completely impractical for me. Here is my setup: C: - vdisk mounted on SSD cache (backed up periodically) D: - vdisk mounted on unassigned device (temp folder) E: - mapped to spinner unassigned device F: - mapped to unassigned SSD - used for VMware VMs I run under Windows. I don't map array disks to drive letters, but can easily write to the array when needed.

I am doing parity checks every 2-3 months. Always do one before and after any disk / hardware activity. Between parity checks, I do md5 verification runs, which serve a similar purpose to parity check, but they check for file corruption instead of parity corruption.

@gridrunner may have other ideas. Reduction in gaming performance from >60 to 26 FPS is not typical.

I am not a gamer, but this is not typical of VM slowdowns I have read about. I'd expect reductions of maybe 20% or so. So there might still be something not quite right in your config. If this is the sole video card, you might try the ROM file in the XML. Could also be that you are not giving enough cores or memory. Or not allocating matching cores and matching hyper-thread cores properly. Review carefully and experiment and you might find something that could pump up the video performance.

Are you using unRAID?

Have you tried the Plex DVR feature? It will record and watching live TV via an HDHR.

Does sound like a bug of some kind. @bonienl might be interested. User shares are odd beasts. They are automatically created based on root level folders on your physical disks. So if, from the command line or via an SMB disk share, you created a root directory called FRED, you'd notice suddenly you have a user share called FRED. If you remove the FRED directory, the user share will disappear. Plot thickens a bit if, through the user shares WebGUI, you customise the user share. This will create a config file. With that config file present, I believe unRaid will continue to report the user share, even if the root level folders are gone. I would check your disks for the root level folder on your disks, and if you find, see if you can manually delete them. Could be a file or directory is still present inside. I expect that is the cause of the user share popping up after the reboot.

I know that general recommendation is, when a drive is being replaced, to remove it and let unRAID rebuild it onto a new disk. I seldom/never do that. I am normally replacing at least 2, and sometimes 3 or 4 at a time. And I will install them outside the array (making sure unRAID partitioning and formatting is applied), and COPY the files from the array disks to the replacement disks. This results in completely defragmented disks, rather than a clones of the existing fragmented disks. After all the copying is done (which can be done in parallel since there is not parity involved), I do a new config, and rebuild parity. Overall I find this a more efficient process, with defragging just being a nice side effect. Of course all of this is done only after a parity check and inspection of the SMART reports / notification emails to ensure that the drives are healthy. If done properly, it introduces no additional risk with minimal drawbacks, and a huge advantage in getting through the upgrade cycle quicker. One of the big benefits of defragmentation is enhanced ability to recover data in the event of some sort of disk corruption event. Unfortunately, XFS is a file system that is particularly poor at being able to recover from such events, defragged or not. So I would question the need to run the defrag tool. Beating the crap out of the drive for 48 hours may not be worth it! With media, the data is typically read back at a slow rate compared to the disk speed, and it will be able to easily keep up with your streaming even with some head movement. Also, when moving to XFS I did some digging into how XFS works,. We tend to think of a drive having a file allocation table that maintains the file linkages. But my understanding of XFS is that it is broken up, internally, into multiple blocks each having its own file allocation table. This tends to keep files within a band of cylinders, and minimize the bad side effects of the heads moving wildly back and forth over the disk surface to read a badly fragmented file. All in all, I would not be overly concerned with disk fragmentation in an XFS array. And if you are worried about it, next time you want to upsize some disks, use my method. Feel free to ask and I can give more details.

Just curious. How much energy savings would this provide for a typical user?

Installing an unRaid update requires a reboot, which would tend to limit the uptime, particularly recently. In the old days, we could have much longer periods between updates and have longer uptimes. An extremely long uptime means you are missing a lot of updates wish is probably not a good thing!

I believe so, but as I recall it depends on setting up properly with the NZBtoMedia tools to communicate between it and the DLer.

I have EVGA 1050Ti SC card. I found a vbios on techpowerup but it said it was untested, and it didn't work (bottom half of screen looked fine, but upper half was all screwed up. So I pulled my own using GPUZ. I installed the card in my old Windows box, ran GPUZ, and extracted the VBIOS. Then editted it with HxD to remove the "nvidia header". Put it on my server, added reference in my VM XML, and it works perfect.

It doesn't happen that often that a REAL read error will happen on rebuild. But it is INCREDIBLY common that a user exchanges a bad or upsizes an existing drive and they knock a cable askew and the result is an apparent failure. Dual parity lets the rebuild complete even if that second drive gets knocked offline. Then you can fix the second issue after the rebuild. With single parity the recovery is still very possible, but certainly more complex. Good cabling and drive cages will stop this phenomenon much more effectively, but dual parity is better than nothing. But I sometimes suggest NOT doing dual parity and instead doing drive cages. They seem unrelated. But this is the connection. And the price is similar. You don't get 100% protection from anything. But drives themselves are pretty darn reliable - certainly if you look at a failure window of 1-2 days, and assuming monthly parity checks, the chances of another drive failing while trying to recover from the first is awfully small. A single "rough spot" on a different disk can subtly corrupt the recovery, but with the file integrity information you can figure out what file(s) were impacted, and restore from backujp or another source. And if a drive fails and the recovery fails, you always have the failed disk. Having a disk fail so badly that you can't get data off of it is quite rare. You might have a bad spot that affects 1 or a small set of files, but typically the lion's share can be salvaged. The problem is that dual parity does not address the main reasons single parity recoveries don't work - and that is failing disks corrupting parity. You'd need something more akin to PAR blocks for such a recovery. I experimented with this a while back, but took forever to build and no way to keep updated without re-doing. This same phenomenon can happen with Freenas. So while not perfect, single parity is pretty darn effective. You have multiple angles to pursue recovery in the proper order. People tend to loose data when they don't know what do to and make mistakes in the process. But even then, the forum experts have a remarkably high success percentage of getting all or most of the data back. Dual parity, as I've said, helps more from cabling issues and might be a help in once in a while. But without the dual parity, the recovery might have been successful anyway. I sleep very well at night with the parity scheme. I have my own file integrity scripts, and don't have experience with that plugin - but YES, having a system for capturing checksums for all disks is very worthwhile. If something does go wrong, you have means to identify which (if any) files got corrupted. Since parity operates below the file system level, it is quite possible for silent corruption to creep in, evidenced by an occasional parity error. You have to compare the checksums when you see one of these happen to determine if something unexpected has corrupted a file (more typically, a parity error is only caused by a hard shutdown and parity, not the data disks, are the cause. Essential? Not the word I'd choose. A useful enhancement? Maybe. Would not much affect parity check times, which are based largely on the parity size (all the other disk I/O is happening in parallel). Freenas likely suffers from some of the same fundamental issues that unRAID does. Maybe there is no one over there able to point out the warts and wrinkles. I know the forum there is not nearly as active as here. If that's your preference - go for it. I really don't mind someone discussing specific features of competing products. But the ultimatums are annoying. Enjoy your array! (And if you move to Freenas - good luck!!)