December 1, 201510 yr Author I noticed that Supermicro's website is showing an updated driver for the SAS2LP controller for Linux: Version 4.0.0.1544. http://www.supermicro.com/products/accessories/addon/AOC-SAS2LP-MV8.cfm Doesn't look like it made it in the changes listed for unRAID 6.1.5, could this be considered a candidate for the next release? Thanks!! We don't use out-of-tree kernel drivers, except the unraid driver of course.
December 1, 201510 yr Just completed the monthly parity check and there is no history. Is there some setting I need to make to get the history to work? EDIT: parity-checks.log: Dec 01 09:20:24|0|0|0 Dec 01 14:35:52|0|0|0 The first parity check I stopped before it was completed. The second completed. When the GUI is open it should immediately add the latest parity check result, unless screen updating is off and in that case it may take up to a minute for the background process to add the entry, this information is retrieved from the syslog file. Can you post the part of the syslog file which shows the parity check result, I presume it is somewhere near the end of the file?
December 1, 201510 yr Dec 1 14:35:52 MediaServer kernel: md: sync done. time=18516sec Dec 1 14:35:52 MediaServer kernel: md: recovery thread sync completion status: 0
December 1, 201510 yr Dec 1 14:35:52 MediaServer kernel: md: sync done. time=18516sec Dec 1 14:35:52 MediaServer kernel: md: recovery thread sync completion status: 0 Ok, found the reason ... when searching for a time stamp the History function looks for a date with double digits, e.g. "Dec 01", but it needs to be a single digit only, thus "Dec 1" and no leading zeroes. Will make a correction for that. Since working on this feature was during dates with double digits, I never encountered the issue before UPDATE: this was supposed to be fixed in 6.1.6 (so I thought) but it wasn't. There is however a hot fix available, see the unRAID version 6.1.6 announcement topic.
December 1, 201510 yr I noticed that Supermicro's website is showing an updated driver for the SAS2LP controller for Linux: Version 4.0.0.1544. http://www.supermicro.com/products/accessories/addon/AOC-SAS2LP-MV8.cfm Doesn't look like it made it in the changes listed for unRAID 6.1.5, could this be considered a candidate for the next release? Thanks!! We don't use out-of-tree kernel drivers, except the unraid driver of course. Sorry, guess I'm unaware of the process. I know there used to be offshoot releases including RealTek NIC drivers (?) ... but perhaps this is more complicated. Does Linux/Slackware have to integrate these drivers first, then unRAID picks them up downstream? They're only about a month old, dunno how long it takes for adoption by the larger community?
December 1, 201510 yr Author I noticed that Supermicro's website is showing an updated driver for the SAS2LP controller for Linux: Version 4.0.0.1544. http://www.supermicro.com/products/accessories/addon/AOC-SAS2LP-MV8.cfm Doesn't look like it made it in the changes listed for unRAID 6.1.5, could this be considered a candidate for the next release? Thanks!! We don't use out-of-tree kernel drivers, except the unraid driver of course. Sorry, guess I'm unaware of the process. I know there used to be offshoot releases including RealTek NIC drivers (?) ... but perhaps this is more complicated. Does Linux/Slackware have to integrate these drivers first, then unRAID picks them up downstream? They're only about a month old, dunno how long it takes for adoption by the larger community? The Realtek drivers are the main reason we don't do this anymore unless absolutely necessary. The problem is these vendors are slow to integrate their drivers upstream. Even the latest Intel drivers do not compile with current stable kernel. Probably though, in this case it's a moot point because those drivers are for using card in RAID mode. In IT mode it uses kernel mpt2sas driver.
December 1, 201510 yr I noticed that Supermicro's website is showing an updated driver for the SAS2LP controller for Linux: Version 4.0.0.1544. http://www.supermicro.com/products/accessories/addon/AOC-SAS2LP-MV8.cfm Doesn't look like it made it in the changes listed for unRAID 6.1.5, could this be considered a candidate for the next release? Thanks!! We don't use out-of-tree kernel drivers, except the unraid driver of course. Sorry, guess I'm unaware of the process. I know there used to be offshoot releases including RealTek NIC drivers (?) ... but perhaps this is more complicated. Does Linux/Slackware have to integrate these drivers first, then unRAID picks them up downstream? They're only about a month old, dunno how long it takes for adoption by the larger community? The Realtek drivers are the main reason we don't do this anymore unless absolutely necessary. The problem is these vendors are slow to integrate their drivers upstream. Even the latest Intel drivers do not compile with current stable kernel. Probably though, in this case it's a moot point because those drivers are for using card in RAID mode. In IT mode it uses kernel mpt2sas driver. Thanks for the info, sounds like messy business. I guess it's time to replace the SAS2LP interface cards. A shame as they served me very well under unRAID 5.x.
December 2, 201510 yr ... I guess it's time to replace the SAS2LP interface cards. A shame as they served me very well under unRAID 5.x. I thought the SAS2LP cards were working just fine as of v6.1.3 with the nr_requests modification ... and that 6.1.4 had fixed the issue altogether without any need for the nr_requests changes. Is that not the case ?
December 2, 201510 yr Dec 1 14:35:52 MediaServer kernel: md: sync done. time=18516sec Dec 1 14:35:52 MediaServer kernel: md: recovery thread sync completion status: 0 Ok, found the reason ... when searching for a time stamp the History function looks for a date with double digits, e.g. "Dec 01", but it needs to be a single digit only, thus "Dec 1" and no leading zeroes. Will make a correction for that. Since working on this feature was during dates with double digits, I never encountered the issue before The date is platform or syslog daemon dependent. Keep in mind it's a leading space with rsyslogd. xxxxxxxxxxxxxxxxx 'Dec 2 08:30:01'
December 2, 201510 yr ... I guess it's time to replace the SAS2LP interface cards. A shame as they served me very well under unRAID 5.x. I thought the SAS2LP cards were working just fine as of v6.1.3 with the nr_requests modification ... and that 6.1.4 had fixed the issue altogether without any need for the nr_requests changes. Is that not the case ? While most of the reports of SAS2LP issues were related to parity check speed, there were unfortunately on the order of 6 to 10 reports of much more serious issues, possible data corruption, red balled drives during heavy traffic, repeatable parity check errors. I think all or most of the reports with a set of exactly repeatable parity check errors were associated with that card. One user name that comes to mind was kir, and there were others. You'd have to search that entire SAS2LP issue thread, a very long read, for more. Near the end, I had invited these users to test the nr_requests fix, but there's a natural reluctance to test something that damages your data or system. I believe there are a couple of negative reports, saying no improvement, and no positive reports that I have seen. Most likely, many of those users have replaced the card and can't test (or won't without a positive report first).
December 2, 201510 yr The date is platform or syslog daemon dependent. Does this mean there will be differences between systems running the same unRAID version? Is there a specific setting which sets the date/time format for syslog?
December 2, 201510 yr ... I guess it's time to replace the SAS2LP interface cards. A shame as they served me very well under unRAID 5.x. I thought the SAS2LP cards were working just fine as of v6.1.3 with the nr_requests modification ... and that 6.1.4 had fixed the issue altogether without any need for the nr_requests changes. Is that not the case ? While most of the reports of SAS2LP issues were related to parity check speed, there were unfortunately on the order of 6 to 10 reports of much more serious issues, possible data corruption, red balled drives during heavy traffic, repeatable parity check errors. I think all or most of the reports with a set of exactly repeatable parity check errors were associated with that card. One user name that comes to mind was kir, and there were others. You'd have to search that entire SAS2LP issue thread, a very long read, for more. Near the end, I had invited these users to test the nr_requests fix, but there's a natural reluctance to test something that damages your data or system. I believe there are a couple of negative reports, saying no improvement, and no positive reports that I have seen. Most likely, many of those users have replaced the card and can't test (or won't without a positive report first). Glad to hear not everyone is suffering. Mine will redball a drive for no reason. Near as I can tell, the controller just stops talking to the drive, then unRAID (understandably) gets very upset. Since this is my main server, I'm loathe to do much testing with each release since I can't risk this system. I ended up picking up a pair of Dell PERC H310 controller cards, as I understand they work very well. Wish I had more time to mess with it, would be nice to figure out what's really happening. I'll attach a partial syslog (grabbed it from a Telnet console window) if anyone is interested. You can PM me if you wanna talk more about it, don't mean to stuff up this thread. PS: This is still on unRAID 6.1.3 with nr_requests set to 8 for all drives. cortex-20151201.txt
December 2, 201510 yr ... I guess it's time to replace the SAS2LP interface cards. A shame as they served me very well under unRAID 5.x. I thought the SAS2LP cards were working just fine as of v6.1.3 with the nr_requests modification ... and that 6.1.4 had fixed the issue altogether without any need for the nr_requests changes. Is that not the case ? While most of the reports of SAS2LP issues were related to parity check speed, there were unfortunately on the order of 6 to 10 reports of much more serious issues, possible data corruption, red balled drives during heavy traffic, repeatable parity check errors. I think all or most of the reports with a set of exactly repeatable parity check errors were associated with that card. One user name that comes to mind was kir, and there were others. You'd have to search that entire SAS2LP issue thread, a very long read, for more. Near the end, I had invited these users to test the nr_requests fix, but there's a natural reluctance to test something that damages your data or system. I believe there are a couple of negative reports, saying no improvement, and no positive reports that I have seen. Most likely, many of those users have replaced the card and can't test (or won't without a positive report first). Glad to hear not everyone is suffering. Mine will redball a drive for no reason. Near as I can tell, the controller just stops talking to the drive, then unRAID (understandably) gets very upset. Since this is my main server, I'm loathe to do much testing with each release since I can't risk this system. I ended up picking up a pair of Dell PERC H310 controller cards, as I understand they work very well. Wish I had more time to mess with it, would be nice to figure out what's really happening. I'll attach a partial syslog (grabbed it from a Telnet console window) if anyone is interested. You can PM me if you wanna talk more about it, don't mean to stuff up this thread. PS: This is still on unRAID 6.1.3 with nr_requests set to 8 for all drives. While I can certainly understand your reluctance to test with the SAS2's, the "fix" for the issue was supposedly introduced in v6.1.4 => so there's little benefit from providing details from 6.1.3. On the other hand, if all is working perfectly with the PERC H310's, I certainly understand your reluctance to switch back to the SAS2's on your main server (I would not do that -- if you don't have a test box, then I'd just leave well enough alone).
December 2, 201510 yr ... I guess it's time to replace the SAS2LP interface cards. A shame as they served me very well under unRAID 5.x. I thought the SAS2LP cards were working just fine as of v6.1.3 with the nr_requests modification ... and that 6.1.4 had fixed the issue altogether without any need for the nr_requests changes. Is that not the case ? While most of the reports of SAS2LP issues were related to parity check speed, there were unfortunately on the order of 6 to 10 reports of much more serious issues, possible data corruption, red balled drives during heavy traffic, repeatable parity check errors. I think all or most of the reports with a set of exactly repeatable parity check errors were associated with that card. One user name that comes to mind was kir, and there were others. You'd have to search that entire SAS2LP issue thread, a very long read, for more. Near the end, I had invited these users to test the nr_requests fix, but there's a natural reluctance to test something that damages your data or system. I believe there are a couple of negative reports, saying no improvement, and no positive reports that I have seen. Most likely, many of those users have replaced the card and can't test (or won't without a positive report first). Glad to hear not everyone is suffering. Mine will redball a drive for no reason. Near as I can tell, the controller just stops talking to the drive, then unRAID (understandably) gets very upset. Since this is my main server, I'm loathe to do much testing with each release since I can't risk this system. I ended up picking up a pair of Dell PERC H310 controller cards, as I understand they work very well. Wish I had more time to mess with it, would be nice to figure out what's really happening. I'll attach a partial syslog (grabbed it from a Telnet console window) if anyone is interested. You can PM me if you wanna talk more about it, don't mean to stuff up this thread. PS: This is still on unRAID 6.1.3 with nr_requests set to 8 for all drives. While I can certainly understand your reluctance to test with the SAS2's, the "fix" for the issue was supposedly introduced in v6.1.4 => so there's little benefit from providing details from 6.1.3. On the other hand, if all is working perfectly with the PERC H310's, I certainly understand your reluctance to switch back to the SAS2's on your main server (I would not do that -- if you don't have a test box, then I'd just leave well enough alone). Understood ... someone (sorry, I forget who) reported seeing a redball on 6.1.4 with the SAS2LP so I ended up skipping the upgrade. Was hoping that the new Linux driver for SAS2LP (see my previous post) might be of some use, but I guess not. Given that this system ran flawlessly on 5.0.6 (and earlier) for years, suddenly having an occasional redball on a random drive seems too much trouble to deal with. If I can get my hands on another set of breakout cables, maybe I can transfer the SAS2LP cards to my test system before I put them up on eBay. Those are only 2TB drives (not 4TB drives), so it's not exactly the same test.
December 3, 201510 yr I also have problems with my AOC-SAS2LP-MV8 cards being able to preclear drives from them I get "A mandatory SMART command failed" error and the preclear will stop. Not a huge issue since I have sata ports on my motherboard I can preclear from. Otherwise the SAS2LP works fine for me since v6.1.4. I get decent parity check speed. If I had it to do over again though I wouldn't have bought them. I think IBM M1015 controllers are a safer bet for all around compatibility in unraid.
Archived
This topic is now archived and is closed to further replies.