Jump to content

michaelsu76

Members
  • Posts

    9
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

michaelsu76's Achievements

Noob

Noob (1/14)

0

Reputation

  1. Wanted to give my post a bump. Haven't had a single bite. I'll take best offer! Drop me a PM! I'll pick up the cost to ship, just want to get these off the desk.
  2. Might seem like a silly question but I'm stumped. I'm trying to get a share to come up as "3D" with the capital "D" . I attached a screen cap for the purpose of illustration. In all my Windows 7 clients that share is coming up as "3d" with a lower case "d". This in spite of the fact that I have it set up as "3D" in Share Settings. A telnet session into /mnt/user also has it as "3D". I have other shares like "Childrens Videos" that come up with the proper capitalization. The only thing that distinguishes this share from the others is that this is the first proper share that I've assigned de novo on 5.0rc11 -- from the "Name" down. The other shares you see weren't set up de novo, but rather just came up "ad hoc" because I imported populated drives intact from an old 4.7 server. On day one when I turned on the power, unraid 5.0rc11 brought the shares up with the share names (with proper capitals) intact (both on SMB and Share Settings). The remainder of the share settings, I did have to re-enter however. I'm sure I'm missing something easy.
  3. Welp. This one came to a quick resolution. It was a bad drive after all. About two days after I posted those errors, I ran a parity check and the drive redballed. Now it's completely dead. It takes juice, but is no longer recognizable. In previous redballs, a reset would allow it to come back online and I could re-"trust" the drive. Sending this one in for RMA. I think that IDNF error was a dead giveaway. Supposedly that's a serious drive error, and I wasn't supposed to trust that drive. I just wanted to see if anyone else had a similar experience where a drive failed without any pre-existing/known SMART issues. I'm not versed in the workings of an HDD, but I'm curious what type of failure would allow for this slow death.
  4. That's including shipping. Sorry forgot to mention. PM if interested.
  5. Yeah I've tried other cables. It's been on every controller/port/backplane/slot on my Norco 4224. Mobo SATA ports, Sil3132, SASLPMV8 tried them all. The Norco makes it relatively easy to do the trouble shooting. Just have to power down, move the drive to another bay, restart. It's just then we get to suffer the indignity of a day long (~10 hours) stress test that is the parity check. Sooner or later, it's thrown an error. This little hiccup recently (the first in 2 weeks) was the least of it. Those redballs during earlier parity checks made my sphincter tighten. Remember this is a drive that redballed a few times on an entirely different rig before I ported it over to the Norco. I worry I have been lulled into a false sense of security ever since re-preclearing the drive and the passed SMART's. Like I was saying, anywhere it's failed, any other drive has done fine. Like if I move a known stable drive to the port that was previously occupied by this suspect drive: I have not yet seen an error arise from a good drive from that vacated port. We've all blamed bad cables traditionally. But it seems I think that I've eliminated cables/controllers from the equation. I just wanted to see if the opinion was out there that glitchy electronics (passed pre-clear x 2 ; passed SMARTs) can throw the aforementioned type of error. Tell me that there is no way this error comes from anything other than bad cabling/controller then I'm going to really have to scratch a temple.
  6. This is a drive that's been giving me fits. In my older server, it redballed every couple weeks from what I thought was a bad splitter. Then I moved it over to my new Norco 4224. Parity build would complete, but it would redball on parity checks without fail. This happened with on-board SATA ports, on Sil3132 card, and on AOCSASLPMV8, and on any backplane. Passed multiple long SMART tests with no pending sectors. Found out that the file system was bad, ran reiserfsck and fixed. ... Redballs went away completely. Four or five random parity checks no problem for over a week. I didn't trust this drive at all, so I transferred all the data off to a reliable drive; precleared it x2 and I relegated it to warm spare duty and literally put a share "Junk" on it just to give it a little payload. Out of the corner of my eye, like a hawk I have been watching the syslog. No rpoblems for the last two weeks. Last night, I ran a parity check overnight into the morning. 60% through, my daughter plays a cartoon at about 7am (from a separate totally non-associated share/drive)... and out of nowhere I get a hiccup: Mar 5 06:56:13 Tower kernel: ata2.00: exception Emask 0x10 SAct 0x0 SErr 0x80000 action 0xe frozen (Errors) Mar 5 06:56:13 Tower kernel: ata2.00: irq_stat 0x00100010, PHY RDY changed (Drive related) Mar 5 06:56:13 Tower kernel: ata2: SError: { 10B8B } (Errors) Mar 5 06:56:13 Tower kernel: ata2.00: failed command: READ DMA EXT (Minor Issues) Mar 5 06:56:13 Tower kernel: ata2.00: cmd 25/00:08:a8:c2:03/00:00:81:00:00/e0 tag 0 dma 4096 in (Drive related) Mar 5 06:56:13 Tower kernel: res 5a/37:00:00:00:00/00:00:00:00:5a/00 Emask 0x12 (ATA bus error) (Errors) Mar 5 06:56:13 Tower kernel: ata2.00: status: { DRDY DRQ } (Drive related) Mar 5 06:56:13 Tower kernel: ata2.00: error: { IDNF ABRT } (Errors)Mar 5 06:56:13 Tower kernel: ata2: hard resetting link (Minor Issues) Mar 5 06:56:21 Tower kernel: ata2: softreset failed (SRST command error) (Errors) Mar 5 06:56:21 Tower kernel: ata2: reset failed (errno=-5), retrying in 3 secs (Minor Issues) Mar 5 06:56:23 Tower kernel: ata2: hard resetting link (Minor Issues) Mar 5 06:56:25 Tower kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 0) (Drive related) Mar 5 06:56:26 Tower kernel: ata2.00: configured for UDMA/100 (Drive related) Mar 5 06:56:26 Tower kernel: ata2: EH complete (Drive related) We've all seen these before. Is it possible that the electronics on the drive are bad? I've troubleshot this drive to death. Any port where it's seemingly had trouble, another drive runs without a hitch. I'm thinking about RMA'ing this drive. Any advice/input? Thanks!
  7. Please make sure you're aware that these are forward--not reverse--breakout cables. 3ware CBL-SFF8087OCF-05M .5M Multi-lane Internal (SFF-8087) Serial ATA Breakout Cable One used (working pull -- in service for 4 months) $10.00 One new still sealed in plastic $20.00 I upgraded to Norco 4224 so I don't need these anymore. Buy one or both. Thanks for looking
  8. I've had similar issues and then some... I bought the TR8M from Sans Digital that came with the RR622 card. It's like the TR5M except with 8 bays. I have an MSI motherboard with a 6 x SATA controller. I have two Sil3132 cards in two PCIe x1 slots with two drives each. Total of 10 drives so far. 7 x 2TB (1 for parity), 1 x 1TB, 1 x 100GB (for cache). UnRAID 4.7. It's been silky smooth... streaming everything up to full blu-ray rips. Got this TR8M because I ran out of case space. So I plug the RR622 card into my remaining expansion slot, a PCIe x16. System doesn't even post. I ended up getting in touch with Sans Digital and they gave me a new BIOS and I could get my server to boot. But I still couldn't get my server to recognize drives in the enclosure until I put the above script into my go file. Now that I can actually work with the drives in the enclosure, I start with a pre-clear. But to my amazement, it's SLOW as molasses. I was in pre-read and I was only getting 13MB/s. Granted they're 2TB drives (WD20EURS) but all my other 2TB drives would pre-read at 70-90MB/s. At that pace it wouldve taken a week to preclear the drives. Normally takes a day and a half. Is it supposed to be this slow? I can't think of why it would be this slow. To the best of my ability it seems to me that the syslog is in order. ata11.x & ata12.x correspond to the RR622 controller and seems they posted fine in the log. And I'm not getting any obvious redflags on the EURS drives. I'll post my syslog with the hopes that the kind community will have some insight. Otherwise, I'm going to bail and return this enclosure. Maybe I was better off with an SAS controller? BTW, I yanked the drive near the end of the syslog. Hence the errors. Thanks for any insight/advice. syslog-2012-10-15.txt
×
×
  • Create New...