JorgeB

Agree, should also allow it, maybe LT didn’t anticipate that situation, should be easy to add.

Are you sure this is true? From my online searches and experience I’m don’t think so, I posted somewhere on this thread that one of my disks redballed during the rsync copy, this resulted in a corrupted file, there was no error on the rsync operation. You would also expect to see some read activity after copying a file if rsynch was verifying it and it does not happen. But I do believe you don’t need to run checksums after copying unless a disk error occurs. Edit: I believe this below better explains it and why it’s only important to run checksums in case of a disk write error. http://unix.stackexchange.com/questions/30970/does-rsync-verify-files-copied-between-two-local-drives

I did the New Config the first time, but got to thinking, and tried the shortcut - and it was over and done so fast I couldn't believe it. But it checked out completely! And I've repeated it since. I first tried to figure out how to trick super.dat, to avoid having to reassign all the drives over and over after New Config, but it was going to be more work than it was worth, so I gave up on that idea, then hit on the simple idea above. But I didn't actually expect it to work! Especially so quickly! The changing the formats part I discovered the hard way, but it's easy enough to do. This works since at least v6.0.0, note that you can only change assigned disk slots, i.e., you can trade disks from slot 1 and 2, but if you have slot 4 empty and want to trade a disk from slot 5 it won’t let you, for that you still need a new config.

I don't find this. I recently set up a new install and run the script on 5 old drives on my test server. I did use the Preclear Plugin though. If you at any point in the past had a drive configured it will run, but on a new installation disk.cfg does not exist and the plugin won’t run without it, easiest way it to hit new config like Jbartlett pointed out.

This is normal while doing multiple preclears, on my server noticeble with 3 or more.

Tools > new config

Dual channel helps parity checks on server with many disks (12+), if I’m remembering correctly got an increase of about 10 to 15% on an Intel server and a little more on AMD.

UnRaid creates redundancy on a drive by drive basis. And to unRaid, a drive is always full of 1s and 0s. It has no idea what they mean. Different drives from different manufacturers do have different reliability characteristics. I've had excellent luck with HGST drives (previously Hitachi). Toshiba got some of that technology and the 5T drives they made have also been reliable for me. The newer models, X300, I have no experience with. I don't think they use the Hitachi technology. Of all the drives I have owned, Seagates have been the most unpredictable. Some models have been awful. Others good. I have not jumped into the 8T world, but experience here appears good. The idea that using a drive for it's intended purpose is somehow going to make it fail sooner is flawed. It they are going to fail under normal usage, you want that to happen so you can return them and get new ones. Although there are things you can duo to make drives fail early, like running them at very high temps, copying large amounts of data to them is not dangerous at all. Do it and let the chips fall where they may and then return for factory new replacement (if possible) or RMA (if past return date) the bad ones. Take the lessons learned to your next purchase decision. We tend to think of finding smart issues as a bad thing, but it is far better to get these errors during preclear and weed out the bad ones before your valuable data is at risk. Good luck! What he said. You were either unlucky with your previous disks or have some underlying issue, like bad cooling or inadequate power supply.

The initial parity sync will always write 100% of the disk, even if all data disks are empty. After that parity is updated, i.e., you write 20GB to a data disk, same amount will be written to parity.

I did that on mine, also upgraded one 3tb drive with an 8tb, this is the same “workout” as building parity.

Looks like a controller issue, all disks on the SASLP dropped offline, maybe try it on different slot if available.

Either way will work, use the most convenient for you.

I tried both and could not find any performance difference with Unraid, still ended up using the LSI firmware just in case.

Should be plug n play, didn’t need to disable bios on mine, it needs latest firmware for >2tb support.

Yep

I did one recently, not because of a failure but for upgrading a 3tb drive, duration was similar to a parity check/sync. Event: unRAID Data rebuild: Subject: Notice [TOWER7] - Data rebuild: finished (0 errors) Description: Duration: 14 hours, 55 minutes, 14 seconds. Average speed: 149.0 MB/sec Importance: normal

Add it after append, it should work, maybe it works even for other marvell chipsets, let us know.

This is how it always worked for me.

Either will work, note however that XFS only supports single cache, for a pool you need BTRFS.

Install Dynamix system stats plugin, start building/checking one and look at the CPU load, if low start another one and so on. With MD5 I can do four at a time in my fastest servers, 2.5 to 2.7Ghz Dual Core Sandy and Ivy Brige CPUs, my HPs N54L microservers on the other hand can only handle two at a time.

Go to tools and click new config, it will create disk.cfg

Fstrim won't work, you'll get fstrim: /mnt/cache: FITRIM ioctl failed: Input/output error

First confirm your SSD has TRIM support: hdparm -I /dev/sdX Look for: * Data Set Management TRIM supported (limit 8 blocks) If it does your possibly using an HBA that doesn't support FSTRIM, e.g., LSI9211-8i.

Although you’re not using parity, you can’t replace one data disk with another, you have to go to tools and do a new config, then just re-assign all disks you want to use now.

Sounds good.