SSD

I didn't test this, but I would assume if it works like the normal exclude it would prevent all writing and overwriting, but wouldn't prevent reading... likely for the same reason that excluding a disk doesn't prevent existing files / folders on that disk to show up in your user share... to avoid "losing" data that isn't lost. If it does prevent reading from that disk and removes it from the aggregation that could lead to some duplication issues (not really a issue as much as waste of space) and it would be good to know if that's the actual behavior because it is different then the lower level exclude include. My understanding is that the global feature literally exclude a disk from participating in the shared fine system feature of unRaid at a technical level, based on feedback from Tom. It's as though the disk isn't there for any share purposes. You can confirm and I will apologize if you find otherwise, but I am pretty certain.

This has been discussed at length. There are good reasons - rfs is an aging filesystem and not being enhanced. We've seen a couple of file corruption bugs creep into rfs that have caused silent data corruption in some 6.0 betas - even for files that are not updated! Many have had performance problems with larger drives with rfs, especially as the drive gets fuller. Xfs is widely used. It is definitely what you should use for any new disks. Some people here have argued for leaving rfs in place for old drives but I don't agree. A bunch of annoying hangs and timeouts have gone away since I switched. I am glad it is off my system. And one more reason - the author is in jail for brutally murdering his wife. I am happy not contributing to any popularity of his invention.

You need to read at least the early part of this thread. If you rebuild your 500G rfs drive onto a 3T drive, you will wind up with a 3T rfs formatted drive. You cannot rebuild an rfs drive and have it be xfs when it us done. To unRaid the entire disk is just a long string of 1s and 0s. It cannot tell the difference between which ones related to file system versus data files. Switching to a different file system requires copying the data off of an rfs drive and onto an xfs formatted drive. This thread is full of people who have used various tweaks to the method I documented to accomplish this in a reliable way.

I believe excluding a drive from the GLOBAL setting would cause that drive to not participate in user shares (SHFS) at all, for reading, writing, or overwriting of files. But I have never tried it, and, in fact, have never heard any user exclude a disk in this manner. But if it works as I say, excluding a disk globally would make files on that disk immune to the user share copy bug. If someone has time and interest they could try and confirm. I don't recommend using this method, as it seems like playing with a live hand grenade. But just trying to explain what the OP read about global share settings, which I think was based on something I wrote.

Not sure what that invalid integer in line 842 is. Not normal. Possible post read verify issue. I'd guess cabling issue. But generally, smart attributes are not affected by cabling, except the CRC one.

I think that drive has problems. The Pending Sector count needs to be 0 for the drive to be used successfully with unRAID and that SMART report for the drive shows 1453 (it has probably gone up since). That is probably why the count shown is incrementing so slowly - the drive is continually retrying to read sectors, and eventually giving up and marking them as 'pending' to indicate a read failure. I bet if you looked at the syslog it will be filled with read errors for that drive. This is exactly why we preclear! Far better to have this happen before you load data!

The dremel sends metal shards everywhere, risky with sensitive computer components around. Clamp method is safer, as well as faster and easier, with the right clamp.

Looks perfect to me.

I believe since you will be using it in passthru mode (IT) it doesn't matter the size of the drive. The OS just needs to recognize/support the size. The only LSI controller I know of that has problems with large drives use the LSI SAS1068E chipset. Most notably the IBM Br10i. They are capped at 2T in RAID or HBA mode. I believe the 9211 supports drive sizes at least to 8T.

Don't mess with the server until you have backups of everything you don't want to lose. Copying data from drive to drive and changing formats is risky, there is a chance of typing a command wrong or not understanding the directions and erasing stuff by accident. Add to that the fact you want to eliminate the single drive failure protection by invalidating parity in order to move stuff, and you have a recipe for disaster unless everything works perfectly. Changing formats as described in this thread is not risky - except for the risk of human error. Which is something under each person's control to mitigate. I do not recommend running a non-parity protected array unless the data of value is separately backed up. Having a parity protected array protected by another parity protected array provides a lot of protection. In this configuration, I could not argue that removing parity from one of them would add a lot of risk. So long as the backup is occurring very frequently to avoid losing newly added data.

There is one other thing you need to understand about user shares. They don't always obey these rules. A user share results in a subdirectory with the name of the user share being created on each disk in the user share containing data. So if you have a user share called FISH configured on disk1 and disk2, each would have a folder called FISH. Now the tricky part is what happens if another disk, say disk4, also has a folder called FISH. Unless that disk is globally configured to not participate in any user shares, disk4 will become a somewhat reluctant member of the FISH user share. All its FISH files well show up with the user share. If a file on disk4 is updated via the user share, the update will be written back to disk4. New files well still tend to be written to disk1 or disk2, but even this is not assured. It depends on the split level and the existing subfolders present on disk4. This condition most often happens when a user attempts to remove a disk from a user share. Changing the configuration to remove a disk does nothing with the folder on the removed disk or its files. Once they figure it out, they might try to copy the files form the disk share of the disk they are trying to remove to the user share. This is a deadly mistake. Called the "user share copy bug", copying from the disk share to the user share will result in unRaid trying to copy files over top of themselves. Normally an OS would detect this and give an error, but in this situation the OS is oblivious. And the attempt will result in each and every file in disk4's FISH folder getting truncated to 0 bytes, losing all their contents. This is easy to avoid, but is something all users should understand to keep their data safe. Hope it makes sense. BTW, one way to resolve this is to rename the FISH folder on disk4 to something else, like OLDFISH. UnRaid will create a new user share for OLDFISH automatically (may take any array stop and restart). You can then move the files from OLDFISH to FISH safely.

As or more concerning, the multizone error rate has an extremely low normalized value of 1. Anything below 51 is considered failed. While you might use this drive as a "better than nothing" backup drive, I would not use it to store primary data. This drive is also quite old. The power on hours normalized value is 10. It has clearly provided you with valuable service for a long time. But it is time to let it retire to Florida!

The RFS.bug was nasty as it could affect disks even if no writes occurred to the disk. The amount of silent corruption caused by the bug is unknown. Only a person with meticulous md5s our a complete backup would be in a position to know if and how much corruption was caused. It was not found so quickly as I recall. Besides the fact that RFS is becoming far less popular, it was also developed at a time when disks ate smaller, and at least some users have performance problems (me included) causing network timeouts as disks get full. XFS had 100% eliminated that issue in my system If you are running an old version of unRaid with no update plans, no issue to keep using RFS. But if you are running 6.0+ and updating regularly, getting new kennel versions, I wholeheartedly recommend converting to XFS.

You might be right - that it is not a real number of reallocated sectors. But that does not mean that the SMART data was corrupted. We see most of the other values are 0, just like they are supposed to be. My guess is that some condition occurred to cause that number to increment to that level. All software has bugs, and the more used a piece of software is, the more defects are reported and fixed, and the more reliable the software becomes. SMART firmware is arguably one of the the least used piece of software. (Maybe not least used, but most users don't even know about smart attributes, and even those familiar with them, refer to them infrequently.) So when defects in the smart system occur, they are often not found or reported. I'd still like to see an actual smart report for other clues as to what might be happening. I'd certainly find it hard to trust the drive.

I would say that 57,240 is too many reallocated sectors. I would suggest getting a warranty replacement if the drive is eligible. The fact that it did not reallocate any more is a good sign, but it could also mean that there are no spare sectors to reallocate. No one has ever posted a definitive way to tell the number of spare sectors available. It may vary by drive model. I'd like the see the actual smart report and see the drive's normalized value. It may be approaching the failure level. If a drive has a few, even up to several hundred reallocated sectors the hold steady for 3 consecutive parity checks or preclear cycles, I'd keep using it (but continue to monitor). But I don't feel the same way about 57,000+. I'd say that 300, maybe 1000 max, would be my cutoff for trusting a drive with reallocations. Frankly I have never personally seen a drive with more than a very small number (single digit) of reallocations that don't have growing reallocations on every full disk operation. But I have seen forum posts with greater numbers. But nothing close to 1000 that I can remember.

No hard and fast rules. And some argue temps are a minor issue. Others say that it is the delta temp (ie. coolest to warmest) that makes the most difference, not the absolute max temperature. . My personal experience is that cooler is better. My drives drop into the upper teens while spun down in the winter, running up to mid 30s running hard in the summer. I have had good longevity experience - although anything a single person experiences with a few dozen drives would be considered anecdotal. All that being said, I like to see drives running in 30s. 45+ would lead me to advise more cooling. 50 I'd be worried and feel the situation was urgent. I have a couple of high capacity 7200RPM drives that run in the low 40s and I am ok with that. Your drives at 42 are in that "close to being too warm" range on my scale. I have no experience with REDS, but believe they are 5x00 RPM drives and should be cooler running. I suggest people use drive cages (5in3s or 4in3s). Each unit has a built in fan. Some cool better than others, but most do a good job. They are also very important if a drive fails and you want to replace it. It is so easy to knock something loose swapping a drive and create big-time headaches trying to recover. The drive cages all but remove the risk of a simple drive swap causing further problems.

All look good. Maybe a tad warm, but nothing to worry about.

One more update ... Update: 8/9/15: So happy with the Seagate 5T drive I had, I bought another one that i found locally on a good sale. The shell had a blue bottom - and it was much easier to extract the drive than the prior generation. The drive model was the same as what I had. It made it through the preread and zeroing phases with no problem, and was 80% through the post read. But next time I checked back on it the drive had been dropped from the server. It was /dev/sdc, and that device no longer existed. Long series of errors in the syslog with no clue what happend. I rebooted, and checked and the drive was not precleared. So set it up to postread just the very last few % and watched it. The postread finished, but then it entered a series of I/Os to the very very beginning of the drive to install the partition and preclear signature, the drive hung for a while and then dropped. Rebooted the server with the drive in another slot. Smart report was fine. Same thing. I noticed that the firmware revision was different - I think it ended with a "6" but forgot to write it down. Anyway, I returned it as a defective drive. Can't say why this happened. Maybe a bad drive that just happened to have a problem at or near sector 0, or maybe Seagate playing games. Either way, I've switched to Toshiba.

2-8g are reasonable differences on 3-4T drives. You are talking about 0.05% - 0.27%.

Different filesystems will not use exactly the same amount of space to store the same set of files. It will be rather close, but not exact. I have seen cases where XFS has used more space than RFS, and cases where the opposite is true. The md5 / content compares with are the key to verifying the copies completed successfully.

I have the issue of a short delay in watching media while a disk is spun up on my array, and it is annoying. But I see the spin up groups as a solution worse than the problem. Not interested in ALWAYS spinning up a bunch of disks as a preventative measure for a rare 3-4 second pause watching a movie. Not advocating for or against the feature being removed, just explaining why I don't use it.

I believe this feature was needed if people had configured their user shares poorly so that files for a single movie got split across multiple physical disk in the share. This was happening with regularity in the days of multiple files needed to store a single movie (e.g., DVD rips). When one file finished playing, there could be a noticeable lag before the next one started if it was on a spun down disk. Setting the user share settings properly from the beginning prevented this issue, and today most movies are converted to mkv's, which is a single file and not subject to the issue described. Some people may have a considerably large set of DVD rips from the old days that have this issue and they may have spin up groups configured to avoid the stuttering described. I don't think IDE vs SATA matters, although I guess if the feature only works on IDE drives you may be right. I never used it.

HERE is a mini-Backblaze report on Toshiba 4TB and 5TB drives. Look pretty good - especially at the current pricing. Note that there is a huge jump in price between 5T and 6T drives. And most 5T drives are Seagate SMR (shingled) at slower RPM. Not that that is necessarily bad as unRAID seems to do fine with shingled drives, but I still prefer the 7200 RPM PMR drives if the price is the same or very close. Toshiba appears the only game in town with these specs - at about the same price as 5T SMRs. Toshiba received the Hitachi drive tech in the WD acquisition back in 2012 - so these have good roots!

Original post updated with the following: Update 7/25/15: Since originally writing this review - I have learned that this drive is an SMR drive meaning that it has overlapping tracks that require very special writing. This can result in slow performance under certain circumstances. To alleviate performance issues, the drive features a persistent cache - a non SMR portion where writes are made and later, when cache is full or drive idle, the drive copies from the cache to the SMR area. I believe that I was trying to do I/O while the drive was dumping persistent cache which created some very strange performance characteristics observed and detailed in this thread. Maybe there is special logic in the USB bios to prevent this type of thing, but when attached to a normal SATA controller, the odd slowdowns were interpreted as related to a purposefully restricted BIOS making the drive perform poorly when connected to a SATA port. This theory was developed based on research I found on the internet from other users' experiences and seemed to fit the facts. I now believe this is not the case, and that the experiences users were having should actually have been attributed to the SMR technology in the drive. (Seagate never disclosed these to be SMR drives). After reading about 8T SMR drives I decided to test it again (previously it had been reverted to be used as portable USB 3 drives and used very infrequently). Once I removed it from the USB enclosure and inserted it in the server, I let it sit for over a week, so absolutely any persistent cache activity would complete. I then precleared the drive, let it sit a week, copied a bunch of data to it, and performed a parity check. The drive is performing quite admirably. My plan is to fill these drives with sequentially written data (minimal if any fragmentation) and use the PMR drive space freed by copying data to this drive for everyday reads and writes. (Although I let the drive wait about a week, a day would likely have been more than enough). Sorry for misleading anyone with my writeup, which was intended to help others avoid problems with the drive.

I took at look at your smart reports and you can see my comments below. The drive sizes of the drives included are as follows: sda - 750G sdb - 500G sdd - 500G sde - 750G sdf - 1T sdh - 500G Honestly, expect the 1T drive, I'd recommend retiring the lot of them and replacing with a new 3T that can be had for less than $100. These are all getting rather old, and with so much larger drives available economically, it may be something to consider. But that is me. If these drive sizes are working for you, I do believe at least some of them have some life left. Many of the values of smart reports are not terribly useful, but the three I look at very closely are reallocated sectors, pending sectors, and temperature. reallocated sectors are small parts of the disk surface that the drive has decided are incapable of reliably storing data. Once reallocated, it will never be un-reallocated. Drives should have 0 of these. Occasionally a small number can develop and not increase in number. This is fine. But if the value is trickling upward, this is a sign the drive is failing. pending sectors are similar, except the jury is not out yet. They may get reallocated, or the drive may decide they are ok after all. Pending sectors are dangerous in that they can cause problems if rebuilding a failed disk. You didn't have any, but if you had, the recommendation would be to run more preclear cycles in an effort to get them to either reallocate or be marked good. Limbo is a bad place to be. temperature is the only one you have control of. I don't like to see temps go above 42 or 43, but preclearing is a pretty stressful activity, and you might expect that this will be the max temp the drive will see in your array. Your temps on some drives are approaching but just under temps that I would highlight, but I am not marking that as an issue. If we were seeing temps over 45, and certainly if they got to 50, I'd be much more concerned. The other attributes you are really looking at the "VALUE" column (on the preclear output you see it as "NEW_VAL") and comparing it to the "FAILURE_THRESHOLD" column. If the value is lower than the threshold, the drive will report "FAILING NOW" in the "STATUS" column. You don't have any of these, but they are bad. If the drive manufacturer, that is warrantying the drives, says it is failing, I never question it and get my data off it as fast as possible. If you seen "near_thresh" in the status column, that is worth looking at. Means the attribute is getting close to the threshold. But there are some attributes that a certain value is normal, and dropping even one lower is failure. So if you see a value of 100 (which is a typical normal good "value" for an attribute), and a threshold of 99, I interpret that to mean it should always be 100, and not to be concerned unless it drops to 99. But if I see a value of 22, and a threshold of 21, or a value of 1 and a threshold of 0, I would be much more concerned. Let me know if any questions on the information below: 1 sda == ST3750330NS 9QK0D9WY == Disk /dev/sda has been successfully precleared == with a starting sector of 63 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sda /tmp/smart_finish_sda ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 117 119 6 ok 120090706 Spin_Retry_Count = 100 100 97 near_thresh 8 End-to-End_Error = 100 100 99 near_thresh 0 Airflow_Temperature_Cel = 60 64 45 near_thresh 40 Temperature_Celsius = 40 36 0 ok 40 Hardware_ECC_Recovered = 45 34 0 ok 120090706 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 1 sector had been re-allocated before the start of the preclear. 4 sectors are re-allocated at the end of the preclear, a change of 3 in the number of sectors re-allocated. ======================================================================= This drive has picked up 3 reallocated sectors during the preclear. Although 4 reallocated sectors is not itself a problem, often INCREASES in the reallocated sectors is a sign the drive is failing. I'd recommend doing a couple more preclear cycles. If the numbers hold steady for three preclears in a row, you are probably fine. But if the numbers trickle up every preclear or two, and you can't get to three in a row with the same value even after 5 or 6 preclears, I'd retire the drive or use it for non-critical purposes (like storing backup data you already store on your array). 2 sdb == ST3500630NS 5QG1HKD0 == Disk /dev/sdb has been successfully precleared == with a starting sector of 63 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdb /tmp/smart_finish_sdb ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Spin_Retry_Count = 100 100 97 near_thresh 0 Airflow_Temperature_Cel = 66 68 45 near_thresh 34 Temperature_Celsius = 34 32 0 ok 34 Hardware_ECC_Recovered = 57 71 0 ok 8218259 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 1 sector had been re-allocated before the start of the preclear. 1 sector is re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ======================================================================= This drive has 1 reallocated sector. This might have been like this for a very long time, or the 1 reallocation may have happened shortly before the preclear. Similar to sda above, I'd run a couple more preclears. If the 1 doesn't increase or you can get 3 preclears in a row where the number holds steady, keep it. Otherwise backup duty. 3 sdd == ST3500630AS 9QG0GA2R == Disk /dev/sdd has been successfully precleared == with a starting sector of 63 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdd /tmp/smart_finish_sdd ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Spin_Retry_Count = 100 100 97 near_thresh 0 Airflow_Temperature_Cel = 56 62 45 near_thresh 44 Temperature_Celsius = 44 38 0 ok 44 Hardware_ECC_Recovered = 53 65 0 ok 7699123 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 114 sectors had been re-allocated before the start of the preclear. 114 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ======================================================================= Same as sdb. 114, although a bit large, its not a big deal if the reallocations don't increase. It is surprising (but good) that it went a whole preclear cycle with no new ones. 4 sde == ST3750640NS 5QD0ELXR == Disk /dev/sde has been successfully precleared == with a starting sector of 63 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sde /tmp/smart_finish_sde ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Spin_Retry_Count = 100 100 97 near_thresh 0 Airflow_Temperature_Cel = 55 58 45 near_thresh 45 Temperature_Celsius = 45 42 0 ok 45 Hardware_ECC_Recovered = 62 65 0 ok 64838030 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ======================================================================= No signs of failure. 5 sdf == ST31000340AS 9QJ1VHF6 == Disk /dev/sdf has been successfully precleared == with a starting sector of 63 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdf /tmp/smart_finish_sdf ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Raw_Read_Error_Rate = 118 110 6 ok 183656712 Spin_Retry_Count = 100 100 97 near_thresh 0 End-to-End_Error = 100 100 99 near_thresh 0 Airflow_Temperature_Cel = 61 62 45 near_thresh 39 Temperature_Celsius = 39 38 0 ok 39 Hardware_ECC_Recovered = 50 36 0 ok 183656712 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ======================================================================= No signs of failure. 6 sdh == SAMSUNGHD502IJ S1PZJDWQ669795 == Disk /dev/sdh has been successfully precleared == with a starting sector of 63 ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdh /tmp/smart_finish_sdh ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE End-to-End_Error = 100 100 99 near_thresh 0 Airflow_Temperature_Cel = 74 77 0 ok 26 Temperature_Celsius = 74 76 0 ok 26 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ======================================================================= No signs of failure.