October 11, 201114 yr True, but if the second BLK_EH error comes, and it could at literally any time without warning, you're far more FUBAR because all drives on the SAS controller will freeze, as will the Web UI, along with any safe way to reboot. These are precisely the reason why these errors are so serious, and not just a mild irritation. I would rather have my server reboot safely, than have to do a hard reset, even if the reboot was at an inconvenient time. Better that than data loss.
October 11, 201114 yr True, but if the second BLK_EH error comes, and it could at literally any time without warning, you're far more FUBAR because all drives on the SAS controller will freeze, as will the Web UI, along with any safe way to reboot. These are precisely the reason why these errors are so serious, and not just a mild irritation. I would rather have my server reboot safely, than have to do a hard reset, even if the reboot was at an inconvenient time. Better that than data loss. But taking the array down while you have files open and being used can do the EXACT same thing... corruption.
October 11, 201114 yr Perhaps I'm wrong, but I was under the impression that if files were open, the array would not stop. Issuing the stop command cleanly takes down all the services first, making sure there are no open files, and then unmounts all /dev/md drives. When this happens all of my client computers give me a warning that shares are no longer available, as you would expect. I've not noticed any more serious errors.
October 11, 201114 yr Perhaps I'm wrong, but I was under the impression that if files were open, the array would not stop. Issuing the stop command cleanly takes down all the services first, making sure there are no open files, and then unmounts all /dev/md drives. When this happens all of my client computers give me a warning that shares are no longer available, as you would expect. I've not noticed any more serious errors. That is correct... if you have no apps running on the array. If something is running on the array... the server will not even shut down as the apps are not going to be stopped, at least not by the built in unRAID powerdown.
October 12, 201114 yr So I have left my server on since Sunday morning...no problems with Block EH errors, server remains completely responsive (see previous post, trying to help out Nezil with troubleshooting). However, I have noticed that my drives aren't spinning down. Indeed, they seem to spin up on their own! Seems similar to the problem other people have been reporting. Syslog attached if anyone wants to take a gander... syslog-2011-10-11.txt
October 12, 201114 yr Just wanted to chme in, i have a clean install 5b12a, using 7 drives on a saslp-mv8 .. i too have the blh_eh.. maybe it obvious, but it only seems to fail on heavy writes/reads.. parity checks makes it fail.. and large copy jobs too.. weird though.. i have been movng more than 4.5gb to it with no problems and then suddenly sunday evening i had the error..
October 12, 201114 yr Yeah, I have the spin up issue. I am getting the system to try to spin down drives, but they spin up on their own. I am fortunate that I have 3 of the saslp-mv8s with 22 drives connected with no EH_Block errors, but the spin issues do exist.
October 13, 201114 yr For the people with or without BLK_EH errors - you should report your firmware revisions for the SASLP card (s) -each one of them as it is not shown in the syslog. They are two firmwares available and the newer one introduced some "RAID" functionality to the controller. It is possible that this extra "RAID" overhead even when the drives are seen as JBOD may be a contributing factor in these crashes. And maybe report whats the card current settings are when you go into the BIOS as Supermicro may have changed the "default" settings. Something to keep in mind.
October 14, 201114 yr running b12a on two servers since it was released, with 3 cards, no block errors, all running v 3.1.0.21. 19 drives total on the controllers with a mix of 3TB and 2TB drives. Also in the middle of pre-clearing 2 x 3tb drives on one of the controllers. I've also do a massive amount of writing to the disks on the controllers and no issues I am however getting these errors on boot, happens on all ata connections that are from each of the controllers with a drive attached. Both systems the same thing Oct 8 02:12:04 Tower kernel: ata9: sas eh calling libata port error handler (Errors) Josh
October 14, 201114 yr running b12a on two servers since it was released, with 3 cards, no block errors, all running v 3.1.0.21. 19 drives total on the controllers with a mix of 3TB and 2TB drives. Also in the middle of pre-clearing 2 x 3tb drives on one of the controllers. I've also do a massive amount of writing to the disks on the controllers and no issues I am however getting these errors on boot, happens on all ata connections that are from each of the controllers with a drive attached. Both systems the same thing Oct 8 02:12:04 Tower kernel: ata9: sas eh calling libata port error handler (Errors) Josh That may not be an error, but a description to you how the errors will be handled
October 14, 201114 yr I have no block errors with 3 cards with firmware v 3.1.0.21. Which MB? http://www.newegg.com/Product/Product.aspx?Item=N82E16813153186 Two cards on that motherboard http://www.newegg.com/Product/Product.aspx?Item=N82E16813138308 And one card on this mb so far, this is my new machine
October 14, 201114 yr I have no block errors with 3 cards with firmware v 3.1.0.21. Which MB? Sorry SuperMicro X8SIL-F-O (most drives are WD20EARS, have 2 x Hitachi Green 3TB, and one Samsung 256GB SSD for cache which I just added yesterday).
October 14, 201114 yr A little OT, but does anybody happen to have the "5.0-beta7.zip" by any chance? Please IM me. Thanks.
October 14, 201114 yr I've tried both firmwares on the SAS-LP card, and get BLK_EH errors with both. I'm back on .21 now.
October 15, 201114 yr I moved to an IBM M1015 SATA/RAID card (Rebranded LSI 9211-8i) and also bought a genuine LSI 9211-8i. Flashed the 2 cards to IT-mode and I am currently starting my unRAID b12-a performing the first parity build/check. A fresh system and hopefully a fresh and good start without that annoying "BLK_EH error" In other words. I returned the AOC-SASLP-MV8's
October 16, 201114 yr Hey guys I've been having spindown problems ever since updating from beta9. When watching HD media it buffers now and again, and when looking at the syslog, well, look for yourself. Hope this helps, this is my first syslog upload. I'll be reverting back to beta9 in the mean time since it worked for me. Cheers syslog-2011-10-16.zip
October 17, 201114 yr I moved to an IBM M1015 SATA/RAID card (Rebranded LSI 9211-8i) and also bought a genuine LSI 9211-8i. Flashed the 2 cards to IT-mode and I am currently starting my unRAID b12-a performing the first parity build/check. A fresh system and hopefully a fresh and good start without that annoying "BLK_EH error" In other words. I returned the AOC-SASLP-MV8's I was thinking of doing the exact same thing.. Please let us know if the m1015 runs with no errors..
October 17, 201114 yr I don't want to sound paranoid but it is usually not a good idea if the keys to the UnRaid kingdom are locked in one place with only one person having access to them. It can be something as simple as a health issue or unforeseen occurrence happening to the holder of the keys and one then only hopes that the hardware investment can be reused with a similar OS. I recall years ago a cartoon that showed a woman and a young boy at a funeral with a business man approaching them. The caption read "Did you ever here him mention Source Code". But what I have come to love about UnRaid is the helpful community of self sacrificing individuals. Because my 4.7 version server is rock solid the worst that can happen is take my unused 3TB Hitachi's and via HDParm make them into 2TBs and wait until the server is full and hopefully by then a stable version that supports 3TB drives is available or hope I can rotate the Hardware to a different OS that supports higher drive capacities. Keeps life interesting.
October 17, 201114 yr I don't want to sound paranoid but it is usually not a good idea if the keys to the UnRaid kingdom are locked in one place with only one person having access to them. It can be something as simple as a health issue or unforeseen occurrence happening to the holder of the keys and one then only hopes that the hardware investment can be reused with a similar OS. I recall years ago a cartoon that showed a woman and a young boy at a funeral with a business man approaching them. The caption read "Did you ever here him mention Source Code". But what I have come to love about UnRaid is the helpful community of self sacrificing individuals. Because my 4.7 version server is rock solid the worst that can happen is take my unused 3TB Hitachi's and via HDParm make them into 2TBs and wait until the server is full and hopefully by then a stable version that supports 3TB drives is available or hope I can rotate the Hardware to a different OS that supports higher drive capacities. Keeps life interesting. As has already been mentioned (probably hard to find and I won't bother to try) there are plans in place should something like that happen.
October 17, 201114 yr Good to know that there is a backup plan. Case, Drives, NICs & controller is all that is important a.t.m. for me. By the time it comes to decide for an upgrade because higher capacity drives are now the norm it only makes sense to use the then existing hardware that is current and supported by OS or Raid system under consideration. No one ever said that this was an inexpensive hobby.
October 18, 201114 yr LimeTech has a code escrow in place. In the case of LimeTech's dissolution, the code will become open source. Nothing to worry about.
October 18, 201114 yr I moved to an IBM M1015 SATA/RAID card (Rebranded LSI 9211-8i) and also bought a genuine LSI 9211-8i. Flashed the 2 cards to IT-mode and I am currently starting my unRAID b12-a performing the first parity build/check. A fresh system and hopefully a fresh and good start without that annoying "BLK_EH error" In other words. I returned the AOC-SASLP-MV8's I was thinking of doing the exact same thing.. Please let us know if the m1015 runs with no errors.. It looks very promising sofar, But then again the system has only been running for 1 day and 20 hrs. Tune back in tomorrow. Normally within or shortly after 2 days the BLK error arises.
Archived
This topic is now archived and is closed to further replies.