garycase

I also have a trusty old C2SEA on one of my servers -- I did the BIOS update YEARS ago with no problem. However, I doubt it really makes a difference at this point -- if a system update was to require a feature not supported by the C2SEA I very much doubt that the 2012 BIOS would resolve that => if that was to happen the only alternatives would be to retire the trusty old C2SEA or to not do any further UnRAID updates on that system.

You could, of course, simply drop one in your array and use it … if it fails it's no big deal assuming you have a parity protected array (even less of an issue if you're using dual parity). However, current drives easily achieve 5TB (and higher) without reverting to SMR technology, so I'd be more inclined to just get a new drive if you need the added capacity. My most recent array has a dozen 8TB HGST drives that work great.

It can certainly slow things down if you're constantly waiting for spin-ups to access directories. One way to mitigate this is to set your disk spin-down timer to a value that will eliminate most spin-downs while you're actively using the system (e.g. 3 or 4 hours); and then click on Spin-Up when you're going to be using the system a lot. If you do this, you might also want to set the md_write_method to "reconstruct write", which will makes writes appreciably faster (but this setting requires all disks be spinning for a write).

FWIW one of my systems is running a version identified as version 2018.10.14 on the Plugin page but as 2.2.0j on the Settings page. My other systems are using the version shown as 2016.08.26 and as 2.1.1 on the Settings page. I've held off on updating the older versions since the newest one seems to have some issues. I assume that at some point in the not-too-distant future the plugin will update to 2.2.1 (or later) with the built-in "Check for Updates" feature on the Plugin page, and that will resolve the current issues.

Agree … the latest version doesn't seem to be working. I upgraded my storage server to 6.6.3 and updated to the latest version of Dynamix Cache Directories; then decided to revert to 6.5.3 due to a massive increase in parity check time (nearly 3 hours) -- but Cache Directories is still on the latest version (2018.10.14). After reading the last couple posts here, I checked to see if it's working -- I have it set to only cache ONE of my shares ("Backups"), but if I access that share ALL of the disks spin up and it takes several seconds to read and display the info. Prior to the upgrade, accessing that share was virtually instant, as the directory info was cached.

A note on forcing a UUID value on virtual machines. It's probably obvious, but in addition to allowing you to use the same license on a physical and virtual machine, this also allows you to use the VM on other hardware. This has the BIG advantage of protecting your system from hardware failure without the need to reload anything. If the physical machine you're running a VM on fails, just move the VM to a new system and it will run just fine -- no activation; no programs to reinstall; etc.

A few thoughts r.e. backing up a Windows 10 system -- regardless of whether it's bare metal or a VM ... => There are really two different things to back up -- (a) the actual OS, and (b) all of your data. => The OS doesn't really need backup very often … an image backup once/quarter (or even every 6 months) is probably fine. This is what you need to actually restore the OS should something catastrophic happen … but if it's a few months behind all you need to do is run a couple cycles of Windows Update to get it back up-to-date. You DO want to update the image if you make significant changes to the programs installed, but other than that it only needs to be updated a few times a year. Given that, it's simple enough to just shut down the system and make an image (for bare metal) or copy the VHD (for a VM). I don't see a problem with an occasional shutdown to do this; although you can also do the image from a "live imager" … such as Acronis, Image for Windows, etc. I've been very happy with Image for Windows on my bare metal systems, but haven't tried it on a VM (too simple to just copy the VHD, so no need). And I DO minimize activity on the system whenever I'm running the image utility (basically don't use it for anything while it's imaging). Regardless of the reliability of modern "live imagers", I'm "old school" when it comes to creating an image -- I like the system to be completely dormant during that process. => Your data should be backed up VERY regularly (daily or even more frequently). But this can easily be done from within the running OS using any desired synchronization utility (e.g. SyncBack) Doesn't require shutting down the OS or even the running apps, although depending on the utility used for the backups it may fail to backup open files (i.e. files currently being modified/created) -- but this isn't a big deal, as they'll be backed up the first time the utility runs after the file activity has been finished. As long as you have an image and a current data backup, recovery is very simple: (a) restore the image; and (b) restore all of your current data [If you're using SyncBack, (b) is simply a matter of running your restore profiles in "Restore" mode immediately after you've restored the image]. Then (c) do all windows updates to get the OS up-to-date.

Not sure what you're referring to r.e. "... one 6-pin connector". IF the voltages are correct and you wire them correctly, then yes, you could power one of the cages from that feed. But if there's any doubt, I'd just use a splitter, which you KNOW is providing the right voltages to the right places

With only a single reallocated sector I wouldn't be at all concerned -- especially if the count doesn't in crease. And of course with dual parity you're well protected should the drive suddenly decide to fail. I never replace a drive just because of a small # of reallocated sectors; as long as the count stays static. If it gets higher than I like, but is still a stable number, I'll replace the drive and use the one with the reallocated sectors for storing off-line backups.

There's no reason you couldn't do that; but why? Turbo-write is generally used to get the quickest possible writes directly to the array, so your data is immediately fault-tolerant and doesn't have to go through the cache. Since you're caching all your writes, then the amount of time it takes to do the actual writes to the array is "hidden" from you anyway, since from the user's perspective that data has already been written to the array. In most cases, those writes are also automatic ... that's the whole idea of the mover script. ... nevertheless, you can simply turn on turbo-write; initiate the mover; and then later just turn off turbo-write.

A 650w would be fine, but 550w is really all you need. Even if you bumped up to a 1070i video card a 550w PSU is still sufficient ... and if you changed to a more modern motherboard with an i7-8700 you'd actually be using LESS power than your i7-2600. [The TDP of an i7-8700 is 65w compared to 95w for the i7-2600; and the newer motherboard would also use less power than the older chipset with the 2600]

There are a variety of tools that work well for testing disks. If you have a Windows box with a spare SATA port or an eSATA or USB3 dock you can easily test any new disks on that. I do this using WD's Data Lifeguard utility (works fine with any manufacturer's drives) ... but you can also use the testing utility from the manufacturer of your disk if you prefer. Note that pre-clear can still be used for this purpose as well if you want to use your UnRAID system as your testing box. But as already noted, pre-clear is NOT needed anymore for the primary purpose it was developed (over a decade ago !!) ... which was to eliminate the down time you would have on a server while it was clearing a new disk. v6 of UnRAID clears the disk automatically BEFORE it is added to the protected array; so the array functionality is not impacted at all by adding new disks to it. When Joe L developed pre-clear, he did include a bunch of activity to test the drives; but the primary reason was to have a new drive zeroed before it was added to the array -- and he coordinated with Tom to include a "pre-clear signature", so UnRAID would know this drive could be quickly added. That functionality still works; but is simply not needed any more. Other than Data Lifeguard, you could use Seagate's SeaTools, SamSung's HUtil, HGST's Drive Fitness Test, or any of a variety of 3rd party tools like HDDScan, DiskCheckup, HD Tune, Crystal Disk, etc.

I suspect that most newer controllers don't have the issue that this resolves; but for those of us who still have older systems it's a very useful feature to eliminate any "stutter" in media playback caused by another drive spinning up on the same controller as the one we're streaming from. It's easy enough to avoid that -- either spin all drives up when streaming media; or don't use the array for anything else when you're streaming ... and the issue this resolves won't ever happen. But unless there's a good reason to eliminate the feature, I'd prefer to see it retained.

As aleady noted, since you didn't have any hash values for your files, there's nothing this plugin or any other checksum utlity can do to help identify corrupted files. You're also not likely get any notification of errors when copying files from the disk. For those files you have backups of, the best way to confirm you have good copies is to do a binary comparison between the files on the UnRAID server and your backups. Any files that don't match, you'll need to manually check to see if you can tell which is the good one -- and then replace the other one. Note that since you don't have checksums for either set of files you have no way of confirming computationally which is actually the correct file. Doing the comparison is easy -- just any any good comparison utility that does a binary compare. I use FolderMatch (not free), but there are several free utilities that can do this as well. [ http://www.foldermatch.com/ ] If there are any mismatches, it's clearly a bit more tedious, but hopefully you won't have any (or at least not many) of those. Since your backups are apparently not local, I'd download a bunch at once onto a PC; then do the comparisons for those; then repeat as needed until you've checked everything. Adding a UPS was the most important improvement you made -- I've told folks for decades this is MANDATORY accessory for EVERY PC ... a power-protected PC that never undergoes an unexpected "yank" of the power cord (which is basically what a power failure is without a UPS) has FAR fewer hardware issues than an unprotected PC. And for a server it's even more important. Hopefully you bought a quality UPS unit -- as a minimum it should have AVR, and ideally you want a true sine wave output. One other thing you can do to give you some idea of whether there's definitely corruption or not is to see if parity is good on the system. Do a parity check and see if there are any sync errors detected. Note that many would suggest doing a non-correcting check, but I see no reason to do that. You WANT parity to be good, so even if UnRAID's assumption that the error is in the parity isn't correct, that's really the only place it can be corrected, since you have no way to knowing which other disk it might be on. If there are sync errors, you'll know for sure you had some corruption, and you need to then do the testing outlined above r.e. file comparisons. Of course if you don't find any, then all you'll know is that the corruption was either on the parity disk (that's good, as it will be resolved by the parity check); or it's on a file you don't have backedup -- in which case there's no way to identify that file. Unfortunately, even if there are NO parity errors, that doesn't absolutely mean you didn't have some corruption, as a write sequence may have been completed immediately before the power loss but before all file operations were completed. But if that's the case, there's likely very few files involved.

To find the GUID for any flash drive: Just download the USB creator for Mac, and make the USB flash drive you want to use bootable. Boot to it; then click on "Flash" on the main screen. This will show you the GUID for that flash drive. HOWEVER, if you have a flash drive that's already been licensed, then plug that drive into a computer and copy the license key from the flash drive to a "safe" place (a folder on your PC or Mac). This will be a file named Pro.key, Plus.key, etc. THEN you can download the USB creator (for Mac or Windows as needed); make the flash drive a bootable UnRAID flash drive; and then copy the key file back to the Config folder on the flash drive, and you can then boot UnRAID from it. BTW, upgrading to 6.4.1 should not have had any impact on your UnRAID flash key's ability to boot unless you were using a flash drive that you have moved the key from. If that's the case, then you need to use the flash drive you transferred the license to -- NOT the old one you transferred it FROM. That drive is no longer valid, since the license has been transferred.

Thanks Johnnie -- that's nice to know ... and much better than disabling the monitoring of the attribute. In fact, I had done that quite some time ago for a disk with reallocated sectors, but had forgotten you could do it

CRC errors aren't all that unusual. I have one drive with quite a few (number hasn't changed in years); and one other drive with 1 CRC error that has been there since I added the drive a few months ago (a new 4TB WD Red in one of my older arrays). I don't like the "error indicator" on the Dashboard for these, so I simply went to disk settings and unchecked the "UDMA CRC error rate" attribute so it's not reported ==> easy enough to just look at SMART data periodically to see if anything's changed; and if there were real problems you'd almost certainly see other errors anyway (i.e. an uncorrectable error).

As you've noticed, it's possible that an XFS volume won't be able to hold as much as a Reiser volume of the same size due to file system overhead differences. Assuming you did a COPY (not a MOVE) and all the data is still on disk #1, you can simply delete all of the data from #14 and then copy everything to disk #13 (which clearly won't run out of space since it's a full TB larger than #1. Not sure why the array is sluggish -- a reboot should indeed resolve that.

As I noted, the meaning was clear as long as you thought about it.

The meaning is clear, but the numbers are reversed -- the file system uses about 1GB per TB. [It would be difficult to allocate a TB for each Gb ]

Changing the file system will indeed result in the disk being formatted & all data being lost from that disk. Not sure exactly which list of steps you're referring to ... this is a very long thread with several lists ... but the concept is simple. Just PAY ATTENTION to where your data is at all times, and after you've safely moved it off of an RFS disk, you can then change that RFS disk's format to XFS and let UnRAID format it -- then use it for the next target disk. That process is really independent of "moving the assignments" around to satisfy your organizational OCD. You can do the reassignments after each format change -- or you could just do them all at the end after you've completed the format changes. There's another LONGER (and arguably safer) way to do this -- it's actually what I did when I finally decided to convert my media server to XFS (really just an OCD thing to have all my servers using the same file system -- since it was just 16 disks of mostly static content there wasn't any real reason to switch the file format) ==> and this approach didn't result in any disk assignments changes or physical relocation of the disks .... One-at-a-time, just do the following: (a) Copy all of the content of a disk to another location not on the server [Being OCD, ALL of my copies were verified, so I just did a TeraCopy of the entire disk to a folder on my main PC called "UnRAID DiskX" ... I changed the X to match the current disk I was converting]. Clearly this requires that you have a large enough disk to hold all of the data [I used a spare 8TB disk that I put in my PC for this purpose] (b) Change the format of the disk in UnRAID to XFS and format it. (c) Copy all the data back [I again used TeraCopy with verification. That process is simple; safe (although for the time that data only exists on the PC it's "at risk" since it's not fault tolerant -- although you should still have your backups just in case); and no drive is ever moved or reassigned. It DOES take a long time -- two complete copies of every disk's data with verification isn't all that fast [The copy TO the PC is pretty fast ... over 100MB/s in my case; but the copy back to the server is slower, since you're copying to a parity protected array].

Understand -- and with single parity you can freely move the drives to any assigned slot you want. I certainly understand a bit of OCD ... my wife would tell you I have a LOT of that . [Just not in my server drive assignments and data distribution]

While I understand the psychology of putting "important files" on a newer drive; note that there's no difference in how well protected those files are. Not sure what difference it makes, but you can certainly do this if you want. Note that if you change slot assignments, it will invalidate parity if you're using dual parity. [The assignments can be freely changed with single parity]

Yes, of course. You can replace the parity drive with any size drive you want (12TB anyone??). Then you can add a drive of the same size (and format it XFS). Then you could simply move all of the files off of an RFS disk, and reformat it to XFS ... and repeat the process for all of the RFS drives.

Did you notice the date on the post you responded to ?? [More than 7 years old ]