I'm evaluating UnRaid 6.3 on a Supermicro Xeon server with 32GB of RAM and capacity for 8 drives. I have a few questions I've not been able to find answers to and any help would be greatly appreciated!

 

I'm not clear on where to look for "sanctioned" UnRaid Docker containers/templates? The only two that come up within the UnRaid UI by default are Plex and Sync. This list seems to indicate there are a number of different template repositories:

 

https://rawgit.com/Squidly271/AppsThread/master/forumpost0.html

 

Am I to assume I should add the URLs for other template repositories with things I'm interested in to UnRaid or is there another "master list" somewhere I've not found yet?

 

Is it possible to alter the parity sync schedule? With zero data (besides what UnRaid automatically creates) it took nearly 6 hours of pounding on the drives to sync the parity file. This seems excessive and a lot of wear and tear on the drives (especially the parity drive). What is the normal time required for nightly syncs? And can it be changed to say specific days of the week instead of nightly (with an increased risk of data loss)?

 

If I assign two parity drives it's not clear to me what UnRaid does with each of them? The docs indicate the system can lose two drives without data loss so am I to assume the dual parity drives are not simply mirrored but contain different parity data? So if either parity drive fails some number, or perhaps all, of drives in the array will then be unprotected?

 

Can an array drive be removed and read as a normal XFS file system via Linux?

 

If I understand correctly, if the cache drive reaches it's prescribed capacity limit, further writes will simply go directly to the array?

 

The docs say that if you try to write a file larger than the size of your cache drive it will fail. Is that still true in UnRaid 6.3? Why can't the write go directly to the array as it would if the cache didn't have enough free space?
 

Is there any method, or planned enhancement, for the cache to move the oldest files (as nearly every other cache works) if it becomes full instead of waiting until 3AM?

 

Let's say you have a 240GB SSD cache that's nearly full. The power goes out, UnRaid is signaled by the UPS to shut down, At 100 MB/sec it's going to take around 40 minutes to copy the SSD to the array. So am I correct you need a giant UPS with massive run time to always protect what's in a suitably sized SSD cache?

 

If the above is true it would make sense to me use a small 32GB - 64GB cache that automatically moves older files as needed. This reduces the data lost if something goes wrong with the cache and makes emptying the cache more practical with typical UPS run times. But, if the docs are correct, that means any file greater than the cache size would not be writable to the NAS at all. And these days there are many things larger (system backups, VMs, encrypted containers, etc.).

 

I like the idea of increased short-term speed, reduced need to spin up the array drives, and reduced wear and tear on the array a cache offers. But, if the docs are correct, it seems like an unacceptable risk even with a pair of cache SSDs? If I used a pair of conventional 7200rpm drives for the cache, and the power goes out before UnRaid can move everything to the array, are the cache drives readable on a Linux system using BTRFS?

 

Thanks in advance for any help!

 

 

Edited June 29, 20179 yr by dev_guy

Hello and welcome.

 

Lots of questions there, here are a few thoughts.  First, you must be thinking about a different product regarding the parity sync schedule - parity is written in real time under unRAID.  Parity checks typically are scheduled monthly.  Second, SSDs are a form of persistant storage - there is no requirement to write the data to the array before letting the UPS shut things down - the data will still be there after you bring the server back up.  A UPS is still highly recommended so that a clean shutdown can be performed.

 

The main function of the cache drive in unRAID these days is *not* to cache writes to the array.  Rather, it is now the defacto "application" drive where Dockers, Docker data, and VMs are stored.  You can also use it to cache writes to the array, and if so you need to size it for the amount of data you write between mover runs (typically 24 hours).  For a typical user a 250GB SSD is a great starting point for the "application" drive.  Personally, I do not cache writes to my array.  Writes directly to the array are pretty fast, and enabling Turbo Write lets me write directly the array at nearly 1GB line speeds.

 

Random other stuff - yes, unRAID data drives in XFS format can be removed and read in another system.  Writes should shift over the array if the cache drive fills up, but I haven't tested it.  I write directly to the array so I haven't tested the "file larger than cache drive" scenario.  Dual parity allows up to two drives to fail without data loss.  If one parity drive fails, all your data drives are still protected - but you can only tolerate one more failure.

 

 

Parity doesn't protect files, it protects entire drives, full, empty, unformatted, corrupted, whatever. There are no files in parity. It's always updated in realtime, it doesn't do a nightly sync. The second parity drive is an entirely different set of equations, also running in realtime on all the array disks. The maths are much more complex on the second parity.

 

https://wiki.lime-technology.com/Parity

Old article, written before parity 2 was implemented. Still totally valid for parity 1.

30 minutes ago, dev_guy said:

I'm not clear on where to look for "sanctioned" UnRaid Docker containers/templates? The only two that come up within the UnRaid UI by default are Plex and Sync. This list seems to indicate there are a number of different template repositories:

 

https://rawgit.com/Squidly271/AppsThread/master/forumpost0.html

 

Am I to assume I should add the URLs for other template repositories with things I'm interested in to UnRaid or is there another "master list" somewhere I've not found yet?

  

If you have found those, you have found the "sanctioned" dockers. As far as i am aware Limetech only maintains those two particular dockers. The vast majority of dockers used on unRAID are created/maintained by its wonderful community. The best way to access those is by installing the Community Applications plugin, by the ineffable @Squid. 

 

37 minutes ago, tdallen said:

 Writes should shift over the array if the cache drive fills up, but I haven't tested it.  I write directly to the array so I haven't tested the "file larger than cache drive" scenario.

This totally depends on each specific user shares settings.

And only user shares can be cached, any writes directly to an array drive are never cached.

 

As for files that are larger than the free space, the key to understanding this is the fact that there is no way for unRAID to know in advance how large a written file will be. It just chooses a drive to write to according to the user share settings, and if the drive doesn't have enough free space, the write fails. How could it be otherwise?

 

Each user share has a Minimum Free setting. Set that to larger than the largest file you will ever write, and unRAID will only choose a drive that has more than minimum free when it begins to write a file.

 

There is also a Minimum Free setting for cache under Global Share Settings.

 

Thanks to everyone for being so responsive. That's a lot of good information. I'm still not entirely clear on write caching and large files but I'll dig around a bit more. I'm not sure what all is supported by SMB but Windows certainly knows file sizes before it starts writing and does a check to see if the destination has enough free space. I have feeling that doesn't happen from Windows to an SMB share. So I can see how that creates an issue.

 

UnRaid apparently has a mechanism for dealing with the cache drive filling up (at least according to the docs). The docs state the file will be written directly to the array instead. If UnRaid doesn't know the file size in advance it would only detect a problem when the cache drive reached its limit before the write completed. At that point it could only do one of three things:

 

1 - Issue an error (the write failed) and delete the partial file in cache.

2 - Continue writing the rest of the file to the array and later move the partial cached file to the array to make the file whole again (tricky and that also means the file would not be immediately available for any access).

3 - Pause the write while it moves the portion in cache to the array but the write would likely time out while it was doing so.

 

I would be interested in knowing what really happens? I might even see if I can dig up a small drive or create a small partition for the cache and write a few large files to the NAS.

 

To @tdallen I'm not clear if the cache drive must be partitioned in two or more logical volumes to serve as an application drive? Or does unRaid just manage that behind the scenes and they all dynamically share the entire drive?

 

As for as parity I have this message on my Dashboard:

 

" Last checked on Thu 29 Jun 2017 12:20:09 AM PDT (today), finding 0 errors.
Duration: 5 hours, 55 minutes, 51 seconds. Average speed: 93.7 MB/sec "

 

I was under the impression from somewhere (perhaps my error) it runs the above "check" (that took nearly 6 hours) nightly? If that won't run again for a month, that's fine. There's also this in Settings > Notifications:

 

Array status notification: "Start a periodic array health check (preventive maintenance) and notify the user the result of this check. "

 

Is that the same check that takes 6 hours on my system? If a drive starts to fail will I not be notified for up to a month when the next check is run?

 

Thanks @primeval_god I'll try the Community plugin. I was under the impression from the official unRaid 6 docs that plugins beyond the two built-in are no longer recommended as they can effect the stability of unRaid itself. The message was to use Docker and VMs for everything else.

 

 

45 minutes ago, dev_guy said:

To @tdallen I'm not clear if the cache drive must be partitioned in two or more logical volumes to serve as an application drive? Or does unRaid just manage that behind the scenes and they all dynamically share the entire drive?

No partitioning needed.

6 minutes ago, tdallen said:

No partitioning needed.

Or tolerated. Pretty sure unraid requires a single partition starting at a specific offset spanning the entire drive.

Nope - cache drive is special and can have multiple partitions. Only partition 1 is mounted. (Unless something changed since version 4.4, b2. )

 

 

Thanks for the added info. I have a 64GB SSD laying around that I might pop in as a temporary cache drive and try writing some big files. I first want to do some write speed benchmarks without any cache to see how much of a boost there is. Someone mentioned "turbo" mode and I'll into that as well. If the write performance is not significantly enhanced I'll probably not use cache but might still use an SSD (or mirrored pair) as an application drive.

56 minutes ago, dev_guy said:

1 - Issue an error (the write failed)

This is what it does when the cache doesn't have enough space. It never writes part of a file to one disk and the rest to another. Each disk is an independent filesystem, and each file exists on only one disk.

 

If you are writing to a cached user share, and if the cache drive already doesn't have enough free space according to the Cache Minimum Free set in Global Share Settings, then it will choose to write the file to an array drive instead. So, there is already a mechanism to prevent it from choosing the cache drive if it is too full. You just have to use it.

 

1 hour ago, dev_guy said:

Array status notification: "Start a periodic array health check (preventive maintenance) and notify the user the result of this check. "

 

Is that the same check that takes 6 hours on my system? If a drive starts to fail will I not be notified for up to a month when the next check is run?

unRAID constantly checks the disks SMART attributes to see if any are failing. It also keeps track of I/O errors as they happen. You can configure Notifications to alert you about any of these problems and many others. Notifications are also used by plugins, and you can even include them in scripts if you want.

 

The periodic parity check can be scheduled or not as you wish. Many people let it run monthly. On my backup server I run the parity check manually as I see fit, since that machine is not on 24/7.

 

As already mentioned, unRAID parity is maintained in realtime. The parity check is just to make sure parity is in fact correct.

Turbo Write enabled during a large copy.  For the first few GB, this copy is going at full 1GB line speed because the writes are being cached in system RAM.  It slows down as system cache (RAM) is exhausted and proceeds with normal array writes.  Towards the end I manually enabled TurboWrite to capture the difference - note that writes are once again going a full line speeds.  Full disclosure - this is under optimal conditions with an otherwise idle server and fast hard drives.

 

 

Edited June 30, 20179 yr by tdallen

 

10 minutes ago, dev_guy said:

Thanks for the added info. I have a 64GB SSD laying around that I might pop in as a temporary cache drive and try writing some big files. I first want to do some write speed benchmarks without any cache to see how much of a boost there is. Someone mentioned "turbo" mode and I'll into that as well. If the write performance is not significantly enhanced I'll probably not use cache but might still use an SSD (or mirrored pair) as an application drive.

 

Your write method depends a lot on your use cases for writing to the array and using your array.

 

If writes to the array happen through downloaders when you are not watching or waiting, the speed of the protected array matters little. It will happen when it happens. Use regular write mode.

 

If writes to the array are happening with you sitting there and waiting for them to complete, you want them to go fast. Turbo write or cached writes are your options.

 

Cached writes are only a temporary solution. The data still needs to be copied to the protected array - normally in the middle of the night. So you are paying the piper, just later.

 

Turbo writes get the data on the protected array quickly (not as fast as copying to cache). But if writes to the array are happening in parallel with other activities on your server, like serving media, copying backups to other servers, or running background processes that are reading and processing data, you do not want to use turbo write. Turbo write is going to spin every disk in your array and slow down any other drive-oriented operation (except to/from cache).

2 hours ago, dev_guy said:

Thanks @primeval_god I'll try the Community plugin. I was under the impression from the official unRaid 6 docs that plugins beyond the two built-in are no longer recommended as they can effect the stability of unRaid itself. The message was to use Docker and VMs for everything else.

 

Dockers and VMs are the preferred method for running applications on an unRAID server these days. There remain however, a number of stable and widely used plugins which focus on extending or modifying the capabilities of the unRAID OS and Web Interface in ways that are not achievable using the other methods. Community Applications for example makes installing docker containers and other plugins as easy and integrated as an app store on other platforms, many consider it essential to the V6 unRAID experience.

14 hours ago, primeval_god said:

Community Applications for example makes installing docker containers and other plugins as easy and integrated as an app store on other platforms, many consider it essential to the V6 unRAID experience.

+1

 

Be careful with the plugins you install, but CA is your gateway into experiencing what unRAID is really capable of.  Dockers are much less likely to affect system stability, and that's the majority of what you will install via CA.  Fair warning, though - unRAID can be used solely as a highly stable NAS if that's what you want.  You open up a dramatic world of possibilities via CA, Dockers and VMs, but at that point I'd say that you're using unRAID as an enthusiast platform, not just a black box NAS appliance.  IMO it's well worth it.

3 hours ago, tdallen said:

Be careful with the plugins you install, but CA is your gateway into experiencing what unRAID is really capable of.  Dockers are much less likely to affect system stability, and that's the majority of what you will install via CA

Anything (Docker / Plugin) listed in CA if it has known problems across the board, or if it causes instability of the OS will have a comment listed next to it detailing the issue and/or be removed from CA.

 

19 hours ago, dev_guy said:

I was under the impression from the official unRaid 6 docs that plugins beyond the two built-in are no longer recommended as they can effect the stability of unRaid itself.

Technically yes that is the official Limetech stance.  (Although, there are some plugins which they themselves recommend to install)  But, this stance was made when there were still "applications" (Plex / SabNZBD, CouchPotato, etc) available in a plugin form.  These basically no longer exist (and are not available within CA).  Nowadays, the only plugins available within CA are those which extend the functionality of unRaid.  @pluginCop has a strict policy that if a plugin is added to CA which is more suitable as a docker application, then the plugin is removed from CA.

Thanks again to everyone for their help here. I'm very impressed with the level of support available from users here. I'm still evaluating and finding my way with unRaid. My initial impression is there's a lot to like about unRaid but it still has some rough edges. And, reading through this forum, the number of issues involving potential data loss or inaccessible data are disturbing.

 

I'm not a Linux/BSD guy by any stretch. I know only the very basics. In more than a decade of running 3 different Qnap NAS units along with a couple of ReadyNAS units I've never lost a single byte of data despite multiple failed drives. Those products may have issues with their extra features (i.e. media servers, backup software, etc.) but the core NAS functionality has been bullet proof. No reboots needed, no hangs, volumes going offline, or anything of the sort. They just work (especially if you stick with an OS version that's stable).

 

You might rightly ask why I'm even looking at unRaid if I'm happy with Qnap. The answer is I need a rack mount NAS that is less than 16 inches deep. Neither Qnap nor Synology make such a thing. But there are suitable rackmount "shallow" chassis out there if you want to build your own. I first looked at FreeNAS but it's a bit too much of a geekfest for me. And there are many reports of improper configurations or even user actions causing massive data loss. I also really like the fact unRaid spins up only the drive being accessed plus the Docker and VM capabilities are also attractive.

 

 

1 hour ago, dev_guy said:

I've never lost a single byte of data despite multiple failed drives

I expect most unRAID users would say the same. And probably a lot of the threads where potential data loss is discussed don't result in actual data loss. I know I have been involved in a number of threads where users have shot themselves in the foot and we still saved their data.

 

And of course, no news is good news, so there won't be a lot of threads devoted to all our trouble-free use of unRAID.

1 hour ago, dev_guy said:

And, reading through this forum, the number of issues involving potential data loss or inaccessible data are disturbing.

I'd say that most of these issues are self-inflicted either due to completely misunderstand what "format" actually does, or thinking that a server can use the cheapest possible equipment with no UPS.

 

I've probably incurred the most "unclean" shutdowns due to being a developer, and have never once had a single corrupted file or drive or image

Other products are tied to specific hardware that allow the company to ensure the hardware is sound. And they provide an easy way to add or exchange disks from outside.

 

UnRaid allows a huge variety of hardware options, and users build them themselves. Many users opt to not use drive cages, and every time they add or exchange a drive, risk knocking a cable askew. But many others here build good servers, use drive cages, and they are the silent majority who experience trouble free operations the vast majority of the time.

 

Power and flexibility increase chances for problems, while something locked down reduces risks but also limits options.

 

The things that really appeal to me about unRaid are ...

1 - real time protection. As soon as file is copied to the array, it is protected

2 - independent file systems. I can take a disk out of the array and read it on another computer independent of the other disks. This means that even a calamity that affects a number of disks will not affect data on the others. And one integrity error does not render the entire array invalid! 

3 - different sized disks. I can mix arbitrary sized disks, and incrementally grow the array

4 - minimal cost of redundancy. One disk can protect almost 30 disks from a single drive failure

5 - extremely high capacity - approaching 300T, and growing

6 - unRaid had continued to improve release after release since I bought in 2007. No additional fees in spite of enormous enhancement which could really have been branded as another product. It really keeps on giving.

7 - Dockers and VMs. At first I thought this was out of place on a NAS, but no longer feel that way. UnRaid offers a compelling platform to reduce clutter and maximize the value in the unRaid server investment.

 

The choice of product you use is 100% yours. A lot of info was shared in this thread and it does take some time to read, experiment, and really understand how all the pieceparts work. Don't give up prematurely. Set up your server and run it through its paces. Then you'll be in the best position to make an informed decision.