Is there a known issue with the Supermicro cards? 

 

I have too many disks to simply bypass them and use onboard controller. 

 

I've been having a similar issue, no red balls, but I do have constant sync errors since I added a 6 TB drive. Xenboot and disabling spindown did not help. I'll try moving to all motherboard ports, I did remove some 2 TB drives so this is possible for now, though I'm in the middle of consolidating/moving data to finish converting to XFS.

Here is my thread http://lime-technology.com/forum/index.php?topic=36465

Yeah, I'm in the process of converting all my drives from RFS to XFS as well...  I have tried the Xen boot and disabling spindown on the 6TBs as well, to no avail.

 

I have pulled a total of 4 drives that all are constantly throwing a "red alert" of failed SMART health check and the immediately a "green alert" of passed SMART health check.

 

I cannot shift any more data around to pull a drive... I'm running out of ideas.  All these "failed" drives preclear just fine.  I can do a new config (since unRAID wont clear a freaking red ball) wait 2 days for the parity check to run, and boom, another random red ball.  All different ports, different cables in my setup, it's just random.  No memory issues, and my PSU is sufficiently sized.  I really don't think this is hardware issue.

 

I cannot even revert back to Unraid5 because of XFS...

 

 

One option you can do is to stop the array and then mount the disks manully and migrate data.  You would need to start with a "new config" since the parity won't be valid anymore, but that way you can migrate the data to clear a drive so on the new config, you can format the newly cleared disk as XFS.  It is a bit risky since you wont have parity protection for the drives while migrating data, but if the system is not stable, it may be the only way.

 

 

Down to my last drive, got a little over 3 TBs to move, then all the array drives will be XFS (cache is still reiser), we'll see if that helps. If not, I'll move all of them to the SASLP.

One option you can do is to stop the array and then mount the disks manully and migrate data.  You would need to start with a "new config" since the parity won't be valid anymore, but that way you can migrate the data to clear a drive so on the new config, you can format the newly cleared disk as XFS.  It is a bit risky since you wont have parity protection for the drives while migrating data, but if the system is not stable, it may be the only way.

 

Thanks, thats what I was referring to when I mentioned I cannot possibly remove any more disks... I have 4 disks preclearing on a different box (multiple times for verification) and I can't shift any more data around until I know these are good.  I have had to create a new config each time, and wait for a day or so for the parity check to finish... only to have another random red ball.  

 

I believe every one that has crapped out has been on a reiserfs, but if I run an fsck on them, everything returns clear...  So I'm just trying to hold steady, not add anything more to my unstable array, and just keep rolling down the disks removing RFS and adding XFS back in. 

I was suggesting not letting the parity build run and just stopping the array and mount the low level disks and do the data copy.  Then only do the new config and start the array just to get the next disk formatted and then shutdown and copy the next batch of data.  That would eliminate the long process of waiting for the parity build to run.

I was suggesting not letting the parity build run and just stopping the array and mount the low level disks and do the data copy.  Then only do the new config and start the array just to get the next disk formatted and then shutdown and copy the next batch of data.  That would eliminate the long process of waiting for the parity build to run.

True true.  That would work... Just waiting on the last run of these preclears to ease my mind that the disks are okay. And then I'll add them back in and move stuff off and keep rolling these RFS filesystems out.

If anyone is still having this issue and feel it is a true defect, please be sure to post in the format specified in the guidelines thread:

 

http://lime-technology.com/forum/index.php?topic=34456.0

 

We can't help track down issues / resolve bugs without clear steps to repeat the issue.  In addition, I'm wondering if this thread belongs more in general support than in the defect reports forum.  Defect reports are for issues relating to defects in unRAID software that we can debug / fix.  Thoughts?

FWIW, I think there are several related issues here and I think they are indicative of a defect somewhere in unRAID 6 (probably related to the Marvell driver) that wasn't present in unRAID 5.  I'm also of the opinion that repeatability and ease of reproduction are attributes of a defect, rather than criteria that define whether something is a defect.  We've seen enough of this problem to say that these aren't one-time occurrences. 

 

That said, it's your call.  I think we want you to know that there's an issue affecting a subset of users and it's persistent enough for some of us that it's affecting our ability to use the product.  We certainly aren't going to define whether you track tricky issues like this through the Defect Reports or General Support forums.

 

I'm really enjoying unRAID 6 now that I've got it running somewhat stably by the way .  Also, standing offer - I can reproduce my problem at-will, and I'd be happy to run instrumented code if it helps get to root cause.

FWIW, I think there are several related issues here and I think they are indicative of a defect somewhere in unRAID 6 (probably related to the Marvell driver) that wasn't present in unRAID 5.  I'm also of the opinion that repeatability and ease of reproduction are attributes of a defect, rather than criteria that define whether something is a defect.  We've seen enough of this problem to say that these aren't one-time occurrences. 

 

That said, it's your call.  I think we want you to know that there's an issue affecting a subset of users and it's persistent enough for some of us that it's affecting our ability to use the product.  We certainly aren't going to define whether you track tricky issues like this through the Defect Reports or General Support forums.

 

I'm really enjoying unRAID 6 now that I've got it running somewhat stably by the way .  Also, standing offer - I can reproduce my problem at-will, and I'd be happy to run instrumented code if it helps get to root cause.

 

Thanks for this.  I totally get where you're coming from.  The truth is that in my mind, this is a hardware issue as it only affects a specific controller model.  That said, it doesn't mean we don't want to see it fixed, but it definitely makes it so that if we wanted to fix it, we'd be reviewing kernel driver code that we didn't even write to begin with.

 

I get that V5 didn't have this issue, but V5 was a much older kernel version.  Moving up kernel versions to gain access to new hardware-centric features will always have the potential to cause some problems like this.  All we can hope is that either A) these problems work out over time with kernel updates or B) we can find some time to look into this at some point in the future.

 

The reason I suggest moving this to support instead of defect is that I think hardware specific issues aren't stemming from the unRAID driver or the user share file system, but a Linux kernel / driver issue.  It's really hard to dedicate time to fixing something that affects such a small subset of users when there are other issues that affect everyone which also need to be addressed.  Even moreso when the issue isn't affecting a mobo / chipset, but just a specific SATA controller card.  The workaround would be to purchase a different one.  Not the answer folks want to hear, but there is no short-term quick fix we could or even would want to implement because we'd be messing with a driver for hardware we don't make ourselves.

 

Hoping this makes sense and isn't taken the wrong way.

I seems hard to tell if it is the driver or something else.  I have a unraid server with a SuperMicro MB and 2 of hte SAS2LP cards, and have never seen a single IO issue.  My other serversis an eVGA MB with one of the SAS2LP cards, and it alot of errors with the normal kernel, but with the Xen kernel I never see any IO errors. 

 

You would think if it is the driver itself it would be more consistant.  I think it is more of a defect in something than a general support issue since this is happening to multiple users, but i do see where you are coming from that it may not necassarily be a defect with unRaid.  Which ever sub forum you decide, it may be a good idea to pin the thread so that it is more visible and not lost with other issues.