SSD

Here is some commentary on your drive issues: » reported_uncorrect=31 Unsure - not a good sign but same number as ata_error_count below, I am assuming they are related » high_fly_writes=112 Not a big deal » current_pending_sector=64 Not good. See below. » offline_uncorrectable=64 Related to pending sectors. » ata_error_count=31 Often related to a cabling problem on the drive. Preclearing worth a try, but wouldn't bet the ranch on it. Also check the cabling to the drive (cabling will not cause pending sectors but may be causing the ata_errors and reported_uncorrect). Note that most attributes will not reset back to zero. The cure may only be evident if the values do not increase. Pending sectors are the exception. The values DO reduce, and you are looking for that value to go back to zero. Occasionally pending sectors vanish after a parity check, but more often they cause reallocated sectors. If they clear and don't cause reallocations, you're likely ok (I've seen this happen quite a few times, and I chalk it up to some firmware bug). Drives have "spare" sectors and are able to reallocate bad sectors to spare sectors, my experience on the forums is that once sectors start to fail, they continue to fail, and unless the values stabilize such that you can run 3 consecutive parity checks and not have the values change, the drive is on the road to failure and should be replaced. I am curious if unRAID reported read errors on the drive after a parity check. If so, these pending sectors should have cleared themselves. unRAID is supposed to perform a write to a disk reporting a read error with the correct values for the sector (it can figure this out by looking at all of the other drives to compute the sector). If the sector is pending, this should force the drive to remap the sector. But sometimes these pending sectors show up and cause no read errors. I do not understand this phenomenon, but maybe the preclear will cause the drive to resolve these. Pending sectors that result in OS level errors are dangerous as they can affect the ability to use that drive for rebuilding a different failed drive in the future.

My comment about tempting the fates was the boastful tone, not that he did not have a well conceived plan. Truly unique works are definitely worthy of being backed up. Photos, financial records, correspondences, etc. But media can be recovered in other ways - and is not necessarily lost. And I do believe that the reliability of one's primary storage location DOES come into play in determining what data (beyond the critical) to back up. A very secure primary storage leads to a less percentage of needing a backup and therefore a lesser percentage of loosing the value of the data. Taken to absurdity, if the data would cost $1 to reconstruct, and the backup solution would cost $5000, regardless of the chance of loss, there is no need to backup the data. At the other end, if the data would cost $1M to reconstruct, and the backup costs $5000, with a 10% chance of data loss, there is an absolute need for backup. But what about ... if the data would cost $5000 to reconstruct, and the backup costs $1500, with a 10% chance of data loss vs if the data would cost $5000 to reconstruct, and the backup costs $1500, with a 0.1% chance of data loss. Would the need for a backup be affected? I think yes. Clearly the problem is more complex than I lay out. The cost to reconstruct involves hours of a person's leisure time. That has a value. But taking backups also takes time and effort. And data losses are not always absolute. In fact, data losses are often small. All this plays in. A person has to weigh all of these variables in making decisions about backing up replacable works.

Tempting the fates, aren't we?

Yes. I would report as a defect in the defect subforum.

You should be able to navigate to the directory from the command line and remove the directory ... cd /mnt/disk6 rm disk4 Also delete the user share disk4.cfg as trurl indicates. Between the two the disk4 share should be gone. That was a weird one!

A user share called disk4 sounds like a dangerous thing! It likely hides the disk4 disk share. Was this purposeful?

You would want to preclear and add the new drive to the array and follow a progression similar to that described in my OP.

Is it possible to create a plugin that would add a tab to the WebGUI to provide unRAID specific utility features?

The SM's use a 92mm fan instead of 80mm. The stock fans move a lot of air and work great for my application. But they can be easily swapped for quieter units. The 92mm fans move more air at the same RPM and should allow quieter operations. 120mm fans move even more air and wold be quieter than either 80mm or 92mm, but I am not aware of a 5in3 drive cage with 120mm fans, although the cheap but effective Rosewill 4in3s do use 120mm fans.

Disk definitely virginal. Never seen such low numbers! Self-tests are a good idea as was already mentioned. If the self-test passes, the behavior might be due to bad cabling. Although this doesn't have the normal symptoms, I'd definitely try replacing the SATA cable.

If these temps are during the heat of summer and after a preclear (which elevates the temps pretty good) I think you're good.

All three look okay. The drive temps are warm though. In the low to mid 40s. That is okay but I prefer to see them in the 30s. You might consider a little extra cooling. The ECC recovered attribute is a little unsettling, but modern drives store data with redundancy acknowledging that media related errors will exist and that the redundancy is used in the normal usage use case to detect and correct such errors. Seagate it's very upfront reporting this, whereas other drives either mask this activity our have it occur to a lesser extent. My slight personal bias against Seagate not withstanding, these drives have successfully passed the preclear. I suggest, as with any drive, that you continue to monitor the smart reports over time.

Welcome aboard! I am not convinced that the 5T drive in this external chassis is an SMR. I was seeing very different performance on sequential READS between using the drive with USB3 and SATA / AHCI. Still not clear why. Others have shucked these drives and didn't have this issue. But your comments are definitely relevant to discussions that are occurring about the 8TB SMR drives..What you say about corruption of static files and dramatic reductions in performance as files become fragmented with use ate spot on.

Replacing a drive with a bigger drive without breaking parity is already available and has been for a very long time. During this process the array is actually unprotected, but as long as you still have the old drive you can still revert to the protected state if anything goes wrong. I am not sure that your idea of having the old drive and the new one both plugged in and cloning actually adds any significant value, and it seems it could add a lot of unnecessary complexity. (Commenting on bolded section] So long as you refrain from writing to the disk being rebuilt during its reconstruction process.

RFS and XFS do use different amounts of space - sometimes XFS uses a bit more but usually it is less. You can use Windows properties from the Samba share and get an exact number of bytes used by the files. These should match if you copy but don't move/remove the source files.

9TB Array in 2008! BTW - those 1T drives are still in service (in my backup array)!

Saw a used SM for $50 on eBay. I have bought a couple used ones and had good luck. YMMV

You have a few unusual readings ... 7G0 188 Command_Timeout 0x0032 100 099 000 Old_age Always - 1 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 2 These may be indicative of a loose cable. Odd though, thought you'd see some ATA errors with CRC errors. 26w 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 4 Similar. Should not be getting CRC errors. bxn 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 8 More CRC errors. I would not be too happy with these results. I have never seen this type of behavior. Given you got a few of these on each drive I might conclude that it was the controller or some other common denominator of all drives (all on same SAS/SATA connector)? Or I could easily blame it on Seagate, who'se quality has not been stellar for quite some time. But their 4TB have been pretty well regarded recently so this is surprising. Inviting other opinions. Anyone seen this before? I think I might try running another preclear cycle hooked to a different computer hooked to motherboard ports. Note that once these attributes increment - they never go back to zero. But if you preclear on a different server and they don't go up, it is something related to the other server and not with the drive. If they keep creeping upward, I'd be tempted to send them back and spend a few more bucks to get the HGSTs.

So that would be a "yes".. Dammit! Ok, will need to load the old drive outside of the array and copy my files back to the new drive. I would have left it as RFS if I would have known this to be the case, honestly I don't think this is well described in the messages on the GUI (or I am dumb, but I think I am a tad more technical than the average "noobie"). I am very very optimistic you will get the data off the " failed". If not start a new thread and many users should be able to help recover. Your scenario was the reason I created this sticky thread, although it was covered in announcement threads too. People using betas have to stay current on the forums to get the necessary info to avoid known bugs and pitfalls. IMHO, even a very basic understanding of how parity works would make it obvious that replacing a drive could not change it's format. If only we could protect ourselves from ourselves.

Good idea. I'll do that. But note that the disk does not have to be empty as step 1 says. If you are confident that the files have been successfully copied to another disk, you can change it's file system and reformat it. It will then be empty. Deleting terabytes of data from an RFS disk is pretty time consuming. Even the command options given that remove files in the process are not necessary.

When you change the disk format (step 2), the disk will appear unformatted when you start the array. You would then format it in the usual way. Parity is maintained through the format operation.

Will this prevent corruption if a drive red balls during the copy?

Very interesting data correlating specific SMART attributes to failure. HERE

So, for step 8, you could use ... rsync -nrcv /mnt/[source] /mnt[dest]/t >/boot/verify.txt It should be done from a screen session or it will time out and stop. This will put the output in a file on the flash disk. It will likely have little or no output, but this will preserve it in case it is lengthy and would scroll off the screen. You can view the output with this command in another session: cat /boot/verify.txt

I agree. For the second scenario, you'd want to assign the 750g to the cache slot, and change it to use XFS. You can format it once the array is started. Changing disk1 to XFS would be very quick. Removing the 750g drive will require rebuilding parity which will take a number of hours. Plan accordingly.