Hi together,

 

the topic says it all, but let me say some words to my situation. Maybe it could help.

 

I run Unraid 4.7 for the last 2 years without any problems. I start with a Asrock G785GXH with 6 sata ports. As all ports are full i bought a 2 port SIL3132 controller and as this hdds are full i bought a SIL3124 4 port controller with pci-express. All went fine at this time.

My write speed to array was about 25MB/s. Only my parity check was slow. i have 25MB/S speed at parity check.

So i ask me what can i do to increase my parity check speed. I dont know why but my hope was unraid 5.0. So the day comes and i install unraid 5.0 but the speed was bad again, but i have no parity sync errors. So a friend give me a 8 port SAS 3082E-R Controller. It´s only a controller for hdds with max 2 TB but i only have 1,5 TB hdds. I switch in the controller and the speed from parity check goes to 40 MB/s. Ok i thought that was better but others have 80MB/s and more. so what can i do next. then i found in the forum the "unraid-tunables-tester". The scripter says only with 4GB RAM and more it make sense to use this. So i bought 2 GB RAM to come on 4GB RAM. I start the script and it gives me for best performance these values "4728, 2128,2128" I use this values and my parity speed increase to 75 MB/s. Now i was satisfied with the parity check speed.

But what was with write speed to the array ? To increase this speed i bought a small 250 GB cache disc. But now the trouble begins, i hope you understand the next words with my bad english. After insert the cache disk, unraid wont boot anymore. The bios shows me all hdds but when unraid should boot from usb stick i become the message to insert a boot medium. So i disable the cache disk from power and then unraid boot. Ok i thought my power supply was to small for all the hardware and i bought a bigger power supply but i have the same situation. Then i tested and switch of a data disk from power, to see if the problem was the new hdd. But if a switch of a data hdd and switch on the new cache disk unraid starts. so it could not be a power problem and not a hdd problem. Long words it was the "new" SAS controller if i take out this controller and switch in my 2 old SIL Controller unraid boot. I´m happy and begin a parity check to see how the speed was. And there i become 1717 parity sync errors.

This was a long story and hope someone read it although.

 

As i have insert the SAS Controller the parity disc was on the SAS Controller. So my hope is that there is no corrupt data and only the parrity disc was not ok while the SAS Controller has a defect.

But how could i check if the data is ok ? I could make a parrity check and correct the errors but is this the rigth way ?

 

Thanks for any help, if my english was not readable please ask if you need other informations.

 

Eisi

 

syslog-2013-09-15.zip

The boot problem was likely that the BIOS removed the flash as the boot device after the cache was installed. Did you check the BIOS settings? The syslog does not indicate which drive is at fault. Post SMART reports for all array drives.

@dgaschk

 

thanks for your answer. The bios settings are ok, in bios himself i saw the usb stick and the usb stick was the first and only boot medium.

 

Did you mean a smart status report or a short smart test ? Could i make a smart report with disk management in unmenu or must i use a specific command ?

 

Eisi

 

Edit: Hope that this is the correct report in Attachment

Smart_Report.zip

The reports all look good. Surprisingly good considering the age of most of the drives. It is not possible to determine which drive, if any, is at fault. This is the main problem with a single parity system like unRAID. When dual parity is implemented it will then be possible to identify a faulty drive. You may try to find the bad drive, if any are bad, by reading the files on each disk. It is most likely that the data disks are correct and parity is wrong. I would run a correcting parity check followed by another check that should have zero errors. unMenu includes the md5deep package that lets you inventory checksums to verify disk contents.

@dgaschk

 

thanks for your held and fast answer. I have now installed the md5deep package, but how must i use it now ? I could not see any menu entries to start the check and ißm not a linux expert

 

Thanks for your help

 

Eisi

 

... dual parity ... it will then be possible to identify a faulty drive.

Is that really true?  Whan I think about it, I'm not so sure.

Seems like two extra bits are not enough for determing the position of the error.

Do you have any references to support your statement?

 

Using a diagonal parity, in addition to the row parity currently used, the location of faulty data can be determine by their intersection. This describes how DP works: http://media.netapp.com/documents/tr-3298.pdf

@dgaschk

 

thanks for your held and fast answer. I have now installed the md5deep package, but how must i use it now ? I could not see any menu entries to start the check and ißm not a linux expert

 

Thanks for your help

 

Eisi

 

See here: http://md5deep.sourceforge.net

As long as ONE bit has failed (not 2), you can determine the specific disk associated with that error by analyzing the additional error information that's stored for additional error correction.

 

If you're using a diagonal parity scheme, as outlined in the article dgaschk referred to, you simply examine the associated diagonal parity bits for each element of the failed parity column until you find the pair that don't match => the intersection of these identifies which bit on which disk has failed.

 

If the implementation is a Galois field based on Reed-Solomon coding (as used in most RAID-6 implementations), the computations are a bit more complex, involving a bit of Galois field algebra, but it's still conceptually simple (if a bit more computationally complex).    Any good text on computational coding theory will outline the details.    The one I have is by Berlekamp -- which is actually still available [ http://www.amazon.com/Algebraic-Coding-Theory-Elwyn-Berlekamp/dp/0894120638 ], but I'm sure there are newer ones that are less costly if you're really interested.

 

I suspect that if UnRAID eventually is updated for dual parity, Tom will use the diagonal parity implementation, as it's computationally simpler.

 

@dgaschk

 

i have start a scan with:

 

md5deep /mnt/disk1/ -r

 

now i become many many output lines, but how could i find out that there is an error with one of the files ?

 

Eisi

 

@dgaschk

 

i have start a scan with:

 

md5deep /mnt/disk1/ -r

 

now i become many many output lines, but how could i find out that there is an error with one of the files ?

 

Eisi

 

md5deep can NOT tell you if there are any errors unless you have PREVIOUSLY scanned all the files and saved their md5 values.    THEN you can run it to verify those values.

 

I don't use this specific tool to save and verify checksums, but the syntax is outlined in several threads on this forum, and on many Linux help sites => just Google for MD5Deep syntax and you'll get several sites that outline it.

 

This is from one of those:

 

To generate a list of file signatures for a directory and all subdirectories:

 

# md5deep -r /data0 > data0md5.sum

 

And then to check integrity later on:

 

# md5deep -rx data0md5.sum

 

You may want to download this and install it on Windows:  http://corz.org/windows/software/checksum/

 

Then you can create checksums for all your files by simply right-clicking on a disk (or folder) and selecting "Create checksums"

 

... and you can check them by right-clicking and selecting "Verify checksums"

 

... all from within Windows Explorer

 

Note that NO checksum utility can help you check your files now -- you have to have the checksum values available to do that.

 

The only way to confirm what files may have errors in them now is to compare them with your backups.  If you don't have backups, then there's simply no way to isolate what may have been damaged.    But if you computer checksums on all of your disks using either Corz or md5deep (or any other similar utility); then if anything happens in the future you'll be able to check your files by simply running a verification check.

 

@garycase

 

Thanks for the good clarification

 

Eisi

 

Gary is correct.

 

... dual parity ... it will then be possible to identify a faulty drive.

Is that really true?  Whan I think about it, I'm not so sure.

Seems like two extra bits are not enough for determing the position of the error.

Do you have any references to support your statement?

 

Using a diagonal parity, in addition to the row parity currently used, the location of faulty data can be determine by their intersection. This describes how DP works: http://media.netapp.com/documents/tr-3298.pdf

 

Intersection of what?  Parity is simply an extra bit strored, whose value depends on the sum of each corresponding bit on the data disks.  So parity can detect and report an error when odd number of those bits have been flipped, but can give no indication of the position(s) -- which bit(s) were flipped.  The article you linked to doesn't say a word about detecting the position of the error(s).  Now, if you know which disk(s) have failed, (logged errors, or became unavailable), then yes, parity will help you reconstruct them.  But just finding parity errors with a parity check cannot tell you where the errors came from.  Double parity adds just one more extra bit in the picture.  Basically, it does what single-parity does.  You'll need a few more extra bits if you want to be able to determine the position of the parity error, something like what ECC memory does.

 

 

 

Please refer back to the paper. It may be simpler to imagine the diagonal as vertical (columns). If row 3 has an incorrect parity somewhere and column 4 has a mistake somewhere then we can deduce that the error is at position 3,4. Position 3,4 refers to a specific bit on a specific drive.

Please refer back to the paper. It may be simpler to imagine the diagonal as vertical (columns). If row 3 has an incorrect parity somewhere and column 4 has a mistake somewhere then we can deduce that the error is at position 3,4. Position 3,4 refers to a specific bit on a specific drive.

With multiple parity errors you can't make such deductions.  The OP for example had 1717 erors.

 

Imagine how with two bits flipped in a row, the horizontal parity will not even detect an error.  Then you'll have two diagonal stripes reporting errors, and no idea what to intersect them with.

 

Again, that article you mention draws nice pictures of how their parity is implemented, and that will help you reconstruct two failed disks, but makes no mention about detecting which disk(s) have failed, by means of the parity algorithm alone.  You should already know which disk(s) have failed by other means, like system read or write errors, or disk becoming altogether inaccessible, etc.  But if you run a parity check on a set of seemingly healthy disks, and find parity errors, then the parity algorithm by itself is of no help to you.

 

It will be possible to identify upon which disk all 1717 errors occurred if they all occur on a single disk.

If multiple diagonals have errors then then a set of disks covered by the diagonals are potential error candidates. It's likely that only a single disk will be included in all incorrect diagonals. There are other cases that result in a probabilistic result. If multiple diagonals do not share a common drive then multiple disks have errors. Assuming a single disk with bad data, a greater number of errors makes identifying the bad disk more likely.

This is not the place to discuss computational error correction algorithms, but I will make one more comment:  as I noted before, you CAN identify the specific disk for any single bit error in a parity stripe.  The implication of that is that if the errors are all from the same disk, it doesn't matter how many there are (1, 2, 1717, etc.), you CAN identify the specific disk for all of them if you have either diagonal parity or Reed-Solomon P+Q computational parity (as RAID-6 uses).

 

If there are 2 errors in the same parity stripe (i.e. errors on 2 different disks at the same bit #); then you can't do that anymore.    In this specific case, it's very likely that all 1717 errors are on the same disk (likely the parity disk) ... so that could in fact have been deterministically computed if UnRAID supported dual parity.

 

But since UnRAID does NOT have dual parity support, this is somewhat irrelevant to this issue 

Hi,

 

sorry for reopen this thread, but the problem seems to be bigger

 

After running a parity check with correct last day , the check found 4000 erros. I start a parity check direct after finish to see if there is any correcting, but in the first minutes the check found errors again

 

Any hint for me how to find out what is wrong ?

 

Could i do a reiserfs --check for all disk to see if there are errors ?

 

Thanks for any help

 

Eisi

 

@Patilan

 

thanks for your help. Should i use any options or standard mem test ?

 

Eisi

 

@all

 

thanks for your help. I found th e error, as i build in the old controllers, on the 4 port controller get the raid 5 mode active. I dont know how this happens because i must create the set in bios of controller. After disable this set of 3 disk a parrity check corrects alle the errors. I have to be on the safe side deltes all the files i have copy to raid since the "old" controller is working.