JorgeB

I understand, but the issue I'm having is that in the example above, I click cancel on disk1 build, disk3 build progress will disappear front the GUI, so I can't cancel but it will continue to build in the background.

Because corz uses blake2s Just another option with b2sum. But if anyone is looking at checking hashes with a different program, you should be using md5 for maximum compatibility Yeah, that’s what I decided to use.

I’ll get back to you on that, I’m still hashing all my servers, it will take some time, my main interest is not bit rot per se but being able to easily check a complete disk if anything happens to it that makes me doubt some or all files integrity. Meanwhile found an issue, and this probably won’t happen to many people but if it happens, it can be a pain because you can’t stop the array: Say I want to start a manual build for disks 1, 2 and 3, so I check mark all 3 and click build, now for some reason I want to stop all 3, after clicking cancel on disk1, disk1 and 3 stop building, I can then cancel disk2, but disk3 will continue to build in the background, if I stop the array it will remain retrying to unmount disks until I use the console to kill all bunker processes.

Thanks, MD5 hashes can now be easily checked with corz. Fyi auto exports at the end of a disk build are still in old format, manual exports are in the new one. Also hashs generated using SHA and BLAKE2 are different from corz, so not compatible, maybe different formats used? These are the hashs from same file using all 3 options: MD5 Bunker: 817f434b2bc289366c4628a1d05d5d7f Corz: 817f434b2bc289366c4628a1d05d5d7f SHA Bunker: 08ba7c1a65d3d267c8f60dd995a32a0b07c14904236fb48f7d2d870206e8b4d1 Corz: 7c8f4bfd0a5d69db04638960c0be8acd7aeda7bf BLAKE2 Bunker: 0c8d4002102d70d207436b5a58aae71f861bd93e95e07d14bd263273ae5489c816eb7ff208cdde0face4177aec5ac0e0b4b13da344f2a4165c9517ad3689e127 Corz: 0b0908f09b11d07b7eb245a2ca8194c6f70f5bb50f1d61706e589c9d526f04cb

Ok, thanks, I think I get it now.

So if I were to copy some hashed files to a backup server running the same plugin I'd have to rehash them?

The BLAKE2 package is installed together with the plugin, but the plugin can't tell whether it runs on your processor or not. Ps. The checksums are not added to the file itself, but to the extended attributes which are maintained by the OS, the original file is never touched. Well, it looks like BLAKE2 works after all on my CPU, I remember failing a test on Squid’s Checksum plugin, because SSE4.1 was required.

Yep, and PARs could still help in case a 3rd disk failed with dual parity, although unlikely it's possible, so I may keep using them.

Little bug, with SHA2 selected in settings, Hashing method in File integrity control appears as none, works as expect with MD5 or BLAKE2.

I have to confess I didn’t really like the idea of adding the checksums to the file itself, maybe because I don’t understand how that works, but after trying it I really like how the plugin works. Great work as usual! PS: I believe that my AMD neon based HP N54Ls can’t handle Blake2, I will use SHA2, but I can select Blake2, shouldn’t this option be disable?

Dual parity won't help in the case you described => if the files are corrupted, the BOTH parity disks will have been updated to reflect the corruption. You'd still need some way of correcting the corrupted data. The corruption happened because a 2nd disk had read errors during a rebuild of another failed disk, with dual parity I could disable the 2nd disk and rebuild both from parity, your am I wrong?

That’s why I use 5% PAR2s for my media servers, can’t afford to backup it up all and once had a disk with some read errors while rebuilding a failed disk that left me with some corrupted files, I had checksums so I knew what files were damaged but no way of fixing them. I will probably go back to checksums only once dual parity is available.

For normal read/write operations to the array performance will be similar, for parity check/syncs and disk rebuilds a fully loaded SASLP will limit you to ~80MB/s, SAS2LP can do 300MB/s+.

Keep an eye on ebay, just recently bought two 1430SA from a German vendor, about 25€ each.

See reply #6 from this thread: http://lime-technology.com/forum/index.php?topic=43538.msg415645#msg415645

Shouldn't have to. How many people will replace drives because they've seen this error coming up, and not come on to the forums and found this thread? This needs fixed ASAP. It’s not clear to me how important this attribute is, all my Seagate drives are at 0, if this value starts increasing regularly I’d like to know, but you can disable that attribute notification from the SMART notifications settings.

For 2 ports I would recommend Asmedia 1601 based controllers, much better performance and they are cheap, like this one: http://www.newegg.com/Product/Product.aspx?Item=N82E16816124045 The one I used for testing was onboard but performance should be very similar.

There was an issue with any V6 and parity check performance, although it didn’t affect all users, it was fixed in 6.1.4, will post test results soon.

Md_write limit was removed from V6, don’t know if it makes a difference in speed but I change it directly in the flash/config/disk.cfg

Confirmed, no longer appears on my server that doesn't support blake2

I don’t know if you have plans to add more Seagates to the SASLP, but so you’re not surprised, expect parity check to slow down considerably with each additional disk you add past the 3 you have now.

Mine make the same click sound, I don’t like it, but from a google search it appears to be normal for these disks.

What OS is giving you that speed graph during the copy? Is that win10? Windows Server 2012 R2, but both Win 8 and 10 have the same graph.

I already posted on other thread but since this is the official one and for anyone interested in these disks I’ve found them to be some of the fastest I’ve used for parity check/sync speeds. This is from my latest server, still has one 3TB Toshiba 7200rpm, with all 8TB Seagates it would be slightly faster. Subject: Notice [TOWER7] - Parity sync: finished (0 errors) Description: Duration: 15 hours, 47 minutes, 30 seconds. Average speed: 140.7 MB/sec Subject: Notice [TOWER7] - Parity check finished (0 errors) Description: Duration: 15 hours, 53 minutes, 3 seconds. Average speed: 139.9 MB/sec Parity check is slightly slower because as I discovered with these drives the HP N54L has ~750MB/s max usable bandwidth on the onboard sata ports, parity sync was faster because only 3 of the 4 drives were reading, it appears the A-Link is full duplex. As for normal usage write speed, I’ve found it to be between 45 and 60MB/s for large files, and as expect slower than normal drives for smaller files, see image 2, as these are a very small percentage of my files I’m very happy with the performance.

That’s a very cool unraid server! I believe the CPU is soldered on the board, so not user replaceable. Be interested to know how the parity check speeds holds up as you add more disks, I believe that those CPUs have a single gen 2 PCIe 4x interface, although even if used by the 10 drives should provide ~160MB/s for each, which is not bad.