garycase

Did you buy "just long enough" cables? That can make a BIG difference. Sometimes it's also helpful to use left-hand connections, depending on just how the cables need to run. I try to also use cables that are no more than an inch or two longer than they need to be. These guys sell both left-hand and right-hand cables in just about any length you might want (in 2" increments starting at 4"): http://www.cpustuff.com/left-angle-to-straight-sata-cable/

Agree ... however, "used" is far less important than what CPU it is. An older generation should certainly be worth less; but if it's a current generation CPU it's not going to functionally any different than a new one. The only thing you're losing relative to a new one is the warranty ... clearly it will expire before a new one would.

Indeed. I suspect the third choice ("Auto") may eventually do what I had hoped it now already did -- i.e. use turbo write IF all of the disks were already spinning; normal write otherwise. My earlier post you referred to noted that this had been discussed -- I had hoped that v6.2 now had that implemented (but clearly it does not). But the presence of the third choice would certainly seem to imply that it may be coming :-)

Are you sure about this? [i'm not at home this month, so can't test this] I'd have thought the "Auto" mode would use turbo write if all disks were already spinning; normal writes otherwise. IF that is the case, the easiest way to turn on turbo writes for a group of files [e.g. if you're getting ready to copy a bunch of large media files] would be to simply click on the Spin Up button in the GUI.

Note that when the rebuild finishes, disk 7 will be exactly how it was before -- including the formatting (which will still be Reiser). At that point you can stop the array; change the format for disk 7 to XFS (do NOT unassign it); and then when you Start the array it will format the drive.

It's certainly true that if you have proper backups the risk of waiting for an actual failure is somewhat mitigated. Between that and dual parity you have very little likelihood of data loss when a drive fails. ... it continually surprises me, however, how many folks consider their data important enough to build a fault-tolerant server but not important enough to back up !!

As noted above, there's nothing intrinsically wrong or "bad" with a high reallocated sector count as long as it's not continuing to grow. If it's growing, then that's a good indication that the drive is failing; and while you COULD wait for the actual failure, it seems that the prudent thing to do is to be a bit more pro-active. The whole idea of SMART is to provide a health check for your drives -- so if it's showing bad things happening, I'd think you'd want to take some action based on that.

As noted, there's nothing wrong with re-allocated sectors. All modern drives are DESIGNED to reallocate any defective sectors to a spare location. A much more serious issue is if you start getting "pending" sectors ... these are defective sectors that are in use and can't be reallocated because the drive can't successfully read them to reallocate the contents. If you start getting these, I'd replace the drive ASAP. But if you simply have a few reallocated sectors, the drive is fine. As already suggested, I'd simply watch to be sure the count doesn't start getting out of control. An occasional increase in the number is okay; but if it starts growing rapidly you likely have a major area of the disk that has become defective and I'd then replaced the drive.

No need to pre-clear an SSD.

No, the parity disk does not have a file system. Parity is maintained, so no sync is needed.

It'd be far neater to simply have the correct lengths. I'd buy a few 10" and 12" cables from cpustuff => if you're not sure which you need, just buy several of each ... never hurts to have a few spare cables handy

Not sure whether 8" is the correct length or not -- I'd measure carefully before ordering. These guys sell cables in about any length you'd need -- 4", 6", 8", 10", 12", 14", 16", 18", 20", 22", 24", etc. http://www.cpustuff.com/right-angle-to-straight-sata-cable/ ... they also sell hard-to-find left-hand cables, which can be very useful if the orientation of your SATA ports requires them to use angled connectors (also in a variety of lengths). http://www.cpustuff.com/left-angle-to-straight-sata-cable/

This seems like the best solution. Agree ... this completely isolates the Docker from the underlying script. With an easy-to-follow outline of what the user needs to do r.e. downloading the script and where to store it, this would eliminate any conflict between the two software authors.

Yes, that would be a good solution => especially the 2nd one, where there's no extra work involved to integrate the script with the Docker.

Why can't you give him a direct link to the script so he doesn't have to redistribute your work? Problem solved. You did make this tool for people to use it I assume? This would certainly seem a reasonable solution -- especially if John adds a note indicating the author of the script requests donations if you find the tool useful and includes a direct link to his donation page [as he said he would do]. ... It does seem like a petty argument -- there's clear attribution of credit for the script including links to the site; and John's not pretending he did any of the work ... it's very clear he simply built a Docker container. Surely this can be resolved amicably.

Yes, your power supply is fine for what you want to do.

48 hours !! It would take less time to simply (a) copy the 3TB of data to a spare drive on a PC over the network; (b) reformat the drive; and then © copy the data back to it => and the result would be ZERO fragmentation Copying 3TB would take ~ 9 hours to copy and about 24 hours to copy back (due to slower writes) ... so perhaps 33 hours to get zero fragmentation. Not sure either process is worth the bother -- fragmentation isn't a big deal with the typical use case for these arrays ... but if the goal is as little fragmentation as possible, the copy off/copy back process would result in NONE.

You only made one BIG mistake ... You should have said "Great ... I'll take a dozen of them !!" 8)

Works fine, but more copying than you really need. You could simply do this: (a) Copy all of disk1 and disk2 to disk5 (& verify) (b) Reformat disk1 and disk2 to XFS © Copy disk3 to disk1 and disk4 to disk2 (& verify) (d) Reformat disk3 and disk4 to XFS Done Unless you have some reason you want your data on specific disks, that's all you need to do.

This is VERY simple. Simply Stop the array; go to the Main tab; click on the disk you want to change; and then change the "File System Type" to what you want. (e.g. XFS) NOTE: This will result in this disk being formatted when you then Start the array, which will DESTROY all data currently on the disk ... so be sure you are only doing it to a disk that's either empty or that you've already copied all the data off of and don't need anymore. You can change multiple disks at once before starting the array (e.g. if you've copied all the data from two disks and are ready to format them both).

The moving around you just did is what gets folks into trouble with the "user share copy bug." e.g. somebody will add a disk to the "exclude" list for a share; and then do a move (or copy) from the disk that's no longer included [e.g. \\Tower\disk1\media\<file to copy> ] to the share [e.g. \\Tower\media\ ], expecting that this will now put the file on one of the disks still included for the share. What happens, however, is that the file contents are lost, as it becomes a zero length file [This is the "user share copy bug"]. The BEST workaround is to never do this !! Personally, I've never moved any data around on the server => it's completely irrelevant where data is stored within a share, except perhaps for keeping videos that are spread over multiple files (e.g. DVD .VOB's) together so minimize drive spinups and consequent delays in playback -- which can easily be controller via the split level setting. If I DID want to move some data, however, I'd absolutely only use disk references ... NOT user share references.

What you're referring to is the "user share copy bug". You do NOT want to write to a user share from a component of that share. The result will be a complete loss of the data for the files involved in the write. THAT is what you can carefully eliminate by removing the disks you want to write to from ANY use in a share -- i.e. by adding them to the global exclude list. A better approach is to NEVER do that write -- i.e. do NOT write to the share. i.e. never do what you noted: "mv /mnt/disk1/media/stuff/a /mnt/user/media/stuff/" If you want to move files writhing a share to a different disk, use the DISK reference ... NOT the share reference. e.g. it's okay to do this: "mv /mnt/disk1/media/stuff/a /mnt/diskX/media/stuff/"

NO! If you exclude the disk globally it won't be included in any share ... even if it's listed in that share's "Includes" Correct ... Includes/Excludes -- whether local or global -- only apply to writes. No disks are excluded when showing the contents of a share for reading.

The global settings are just what they say => you can define which disks are available for use in your shares or are excluded. [You shouldn't use both -- use either the Include or Exclude, depending on which is easiest for what you want to do] The individual share settings define which disks -- of those that are available -- will be used for your individual shares.

There's a plugin that makes it very simple to use the feature. Go to the Plugins page; click on Install plugin; and copy the following line into the URL blank ... then click Install. https://raw.github.com/bergware/dynamix/master/unRAIDv6/dynamix.cache.dirs.plg