wheel

Nice. Sorry for not thinking of that myself; basically paralyzed with fear right now, brain's not quite there. Also attached post-reset log of most recent WTF-ery (non-compressed .txt) syslog-2017-05-24.zip syslog-2017-05-24.txt

OK, so it's looking like two disks are dead (unless and until I can upload a 5-24 full log to the site, which doesn't look like it's happening now) from the pair of SMART reports below. Other random drives I selected deliver normal SMART reports. Considering I made it through nearly a decade of UnRAID usage without a dual-drive failure, I guess things could've been worse. Does anyone recommend I leave the system on until I can successfully upload a syslog here, or should I just go ahead and start the giving up process of figuring out what (if anything) I can salvage from these two drives and how best to get back to a parity protected situation on the remaining drives? Going to be a fun day / week. smartctl -a -d ata /dev/sdd smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Read Device Identity failed: Input/output error A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. and smartctl -a -d ata /dev/sde smartctl 6.2 2013-07-26 r3841 [i686-linux-3.9.11p-unRAID] (local build) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Read Device Identity failed: Input/output error A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

Then I'm screwed. Every time I try to load a syslog I get an error message from this site halfway through the upload, " There was a problem processing the uploaded file. -200 " UnRaid GUI shows a thumbs up icon for both Disk 5 and Disk 10 under the SMART Status windows for each; going to try checking via UnMenu now. These most recent (and now apparently looping) lines make me feel like something is irrevocably screwed: May 24 05:13:09 Tower kernel: REISERFS error (device md10): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [6920 8521 0x0 SD] May 24 05:13:09 Tower kernel: REISERFS error (device md10): vs-13070 reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [6920 9047 0x0 SD] May 24 05:13:09 Tower kernel: program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO May 24 05:13:40 Tower last message repeated 218 times May 24 05:14:41 Tower last message repeated 364 times May 24 05:15:42 Tower last message repeated 366 times

OK guys, I really want to shut this thing down now, but hate to do that if I'm losing something I may need to fix a multiple drive failure. Log is throwing these out at me now: ) May 24 05:09:48 Tower kernel: cdb[0]=0x8a: 8a 00 00 00 00 01 bf d7 af 18 00 00 00 08 00 00 May 24 05:09:48 Tower kernel: md: disk10 write error, sector=7513550552 (Errors) May 24 05:09:48 Tower kernel: sd 3:0:1:0: [sde] Unhandled error code (Errors) May 24 05:09:48 Tower kernel: sd 3:0:1:0: [sde] (Drive related) May 24 05:09:48 Tower kernel: Result: hostbyte=0x04 driverbyte=0x00 (System) May 24 05:09:48 Tower kernel: sd 3:0:1:0: [sde] CDB: (Drive related) Like it keeps wanting to (and failing to) write to Drive 10. Still no DISK DISABLED on UnMenu or UnRaid GUI for Disk 10. DEFINITELY getting scared now though.

Hate to tempt fate, but just checked directory structure of a couple multi-drive user shares through Windows and nothing *seems* amiss... really hoping it's just one drive and the Disk 10 read errors were just parity checking one drive against the other!

Glad I ran a non-correcting parity check; looks like Disk 5 died during the check (currently disabled), and I have a warm spare ready to go. Only thing that throws me off is towards the bottom of the log, after a series of read error messages from Disk 5, there's a set of notifications that seem like they're having problems reading from Disk 10 as well (right before it shuts down the parity check). I'm hoping against hope that these Disk 10 read errors are because UnRaid was trying to check that disk against the parity drive for Disk 10 purposes, or it was coming up next or something, and that two drives did not die simultaneously / are currently disabled (sure doesn't look that way on UnMenu or UnRaid GUI, but I'm a little freaked out right now). I can't attach the parity check / error log for some reason, so I'm pasting the lines that concern me below - my plan's to install the replacement drive and let everything rebuild as normal, but does anyone see anything I should do before I follow those steps? I'm guessing this is where Disk 5 died: May 24 04:12:16 Tower kernel: md: disk5 read error, sector=4070714128 (Errors) May 24 04:12:19 Tower kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 (Errors) May 24 04:12:19 Tower kernel: ata2.00: BMDMA stat 0x65 (Drive related) May 24 04:12:19 Tower kernel: ata2.00: failed command: READ DMA EXT (Minor Issues) May 24 04:12:19 Tower kernel: ata2.00: cmd 25/00:00:58:2b:a2/00:04:f2:00:00/e0 tag 0 dma 524288 in (Drive related) May 24 04:12:19 Tower kernel: res 51/40:00:58:2b:a2/40:00:f2:00:00/00 Emask 0x9 (media error) (Errors) May 24 04:12:19 Tower kernel: ata2.00: status: { DRDY ERR } (Drive related) May 24 04:12:19 Tower kernel: ata2.00: error: { UNC } (Errors) May 24 04:12:19 Tower kernel: ata2.00: configured for UDMA/133 (Drive related) May 24 04:12:19 Tower kernel: ata2.01: configured for UDMA/133 (Drive related) May 24 04:12:19 Tower kernel: sd 3:0:0:0: [sdd] Unhandled sense code (Drive related) May 24 04:12:19 Tower kernel: sd 3:0:0:0: [sdd] (Drive related) May 24 04:12:19 Tower kernel: Result: hostbyte=0x00 driverbyte=0x08 (System) May 24 04:12:19 Tower kernel: sd 3:0:0:0: [sdd] (Drive related) May 24 04:12:19 Tower kernel: Sense Key : 0x3 [current] [descriptor] May 24 04:12:19 Tower kernel: Descriptor sense data with sense descriptors (in hex): May 24 04:12:19 Tower kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 May 24 04:12:19 Tower kernel: f2 a2 2b 58 May 24 04:12:19 Tower kernel: sd 3:0:0:0: [sdd] (Drive related) May 24 04:12:19 Tower kernel: ASC=0x11 ASCQ=0x4 May 24 04:12:19 Tower kernel: sd 3:0:0:0: [sdd] CDB: (Drive related) May 24 04:12:19 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 f2 a2 2b 58 00 00 04 00 00 00 May 24 04:12:19 Tower kernel: end_request: I/O error, dev sdd, sector 4070714200 (Errors) May 24 04:12:19 Tower kernel: ata2: EH complete (Drive related) May 24 04:12:19 Tower kernel: md: disk5 read error, sector=4070714136 (Errors) May 24 04:13:20 Tower kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen (Errors) May 24 04:13:20 Tower kernel: ata2.00: failed command: FLUSH CACHE EXT (Minor Issues) May 24 04:13:20 Tower kernel: ata2.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0 (Drive related) May 24 04:13:20 Tower kernel: res 40/00:00:58:2b:a2/40:00:f2:00:00/00 Emask 0x4 (timeout) (Errors) May 24 04:13:20 Tower kernel: ata2.00: status: { DRDY } (Drive related) May 24 04:13:20 Tower kernel: ata2.00: hard resetting link (Minor Issues) May 24 04:13:21 Tower kernel: ata2.01: hard resetting link (Minor Issues) May 24 04:13:26 Tower kernel: ata2.00: link is slow to respond, please be patient (ready=0) (Drive related) May 24 04:13:30 Tower kernel: ata2.00: SRST failed (errno=-16) (Minor Issues) May 24 04:13:30 Tower kernel: ata2.00: hard resetting link (Minor Issues) May 24 04:13:31 Tower kernel: ata2.01: hard resetting link (Minor Issues) May 24 04:13:36 Tower kernel: ata2.00: link is slow to respond, please be patient (ready=0) (Drive related) May 24 04:13:40 Tower kernel: ata2.00: SRST failed (errno=-16) (Minor Issues) May 24 04:13:40 Tower kernel: ata2.00: hard resetting link (Minor Issues) May 24 04:13:41 Tower kernel: ata2.01: hard resetting link (Minor Issues) May 24 04:13:46 Tower kernel: ata2.00: link is slow to respond, please be patient (ready=0) (Drive related) May 24 04:14:15 Tower kernel: ata2.00: SRST failed (errno=-16) (Minor Issues) May 24 04:14:15 Tower kernel: ata2.01: limiting SATA link speed to 1.5 Gbps (Drive related) May 24 04:14:15 Tower kernel: ata2.00: hard resetting link (Minor Issues) May 24 04:14:16 Tower kernel: ata2.01: hard resetting link (Minor Issues) May 24 04:14:20 Tower kernel: ata2.00: SRST failed (errno=-16) (Minor Issues) May 24 04:14:20 Tower kernel: ata2.00: reset failed, giving up (Minor Issues) May 24 04:14:20 Tower kernel: ata2.00: disabled (Errors) May 24 04:14:20 Tower kernel: ata2.01: disabled (Errors) May 24 04:14:20 Tower kernel: ata2: EH complete (Drive related) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714144 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714152 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714160 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714168 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714176 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714184 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714192 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714200 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714208 (Errors) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] READ CAPACITY(16) failed (Drive related) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] (Drive related) May 24 04:14:20 Tower kernel: Result: hostbyte=0x04 driverbyte=0x00 (System) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] Sense not available. (Drive related) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714216 (Errors) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] READ CAPACITY failed (Drive related) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714224 (Errors) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] (Drive related) May 24 04:14:20 Tower kernel: Result: hostbyte=0x04 driverbyte=0x00 (System) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] Sense not available. (Drive related) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714232 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714240 (Errors) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] Asking for cache data failed (Drive related) May 24 04:14:20 Tower kernel: sd 3:0:0:0: [sdd] Assuming drive cache: write through (Drive related) May 24 04:14:20 Tower kernel: sdd: detected capacity change from 3000592982016 to 0 (Drive related) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070714248 (Errors) Then, after a series of these: May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070715088 (Errors) I got these: May 24 04:14:20 Tower kernel: sd 3:0:1:0: [sde] Unhandled error code (Errors) May 24 04:14:20 Tower kernel: sd 3:0:1:0: [sde] (Drive related) May 24 04:14:20 Tower kernel: Result: hostbyte=0x04 driverbyte=0x00 (System) May 24 04:14:20 Tower kernel: sd 3:0:1:0: [sde] CDB: (Drive related) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070715096 (Errors) May 24 04:14:20 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 f2 a2 2f 58 00 00 04 00 00 00 May 24 04:14:20 Tower kernel: end_request: I/O error, dev sde, sector 4070715224 (Errors) And then back to the "disk 5 read error" series, until interrupted by this: May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714136 (Errors) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714144 (Errors) May 24 04:14:20 Tower kernel: md: md_do_sync: got signal, exit... (unRAID engine) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714152 (Errors) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714160 (Errors) Which continues on with the 'disk 5 write error" series, but gets interrupted like this: May 24 04:14:20 Tower kernel: sd 3:0:1:0: [sde] Unhandled error code (Errors) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714528 (Errors) May 24 04:14:20 Tower kernel: sd 3:0:1:0: [sde] (Drive related) May 24 04:14:20 Tower kernel: Result: hostbyte=0x04 driverbyte=0x00 (System) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714536 (Errors) May 24 04:14:20 Tower kernel: sd 3:0:1:0: [sde] CDB: (Drive related) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714544 (Errors) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714552 (Errors) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714560 (Errors) May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714568 (Errors) May 24 04:14:20 Tower kernel: cdb[0]=0x88: 88 00 00 00 00 00 f2 a2 33 58 00 00 01 40 00 00 May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070714576 (Errors) May 24 04:14:20 Tower kernel: end_request: I/O error, dev sde, sector 4070716248 (Errors) Then after getting back to "disk 5 write error" repetition, I get this, which is what concerns me: May 24 04:14:20 Tower kernel: md: disk5 write error, sector=4070715152 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070715160 (Errors) May 24 04:14:20 Tower kernel: md: disk10 read error, sector=4070715160 (Errors) May 24 04:14:20 Tower kernel: md: multiple disk errors, sector=4070715160 (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070715168 (Errors) May 24 04:14:20 Tower kernel: md: disk10 read error, sector=4070715168 (Errors) May 24 04:14:20 Tower kernel: md: multiple disk errors, sector=4070715168 (Errors) The logger appears to stop the "multiple disk errors" logging at this point, and these last two lines (disk 5, disk 10) repeat until the end: May 24 04:14:20 Tower kernel: md: multiple disk errors, stopped logging (Errors) May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070715472 (Errors) May 24 04:14:20 Tower kernel: md: disk10 read error, sector=4070715472 (Errors) And here's the end: May 24 04:14:20 Tower kernel: md: disk5 read error, sector=4070716496 (Errors) May 24 04:14:20 Tower kernel: md: disk10 read error, sector=4070716496 (Errors) May 24 04:14:21 Tower kernel: md: recovery thread sync completion status: -4 (unRAID engine) May 24 04:14:21 Tower kernel: md: recovery thread woken up ... (unRAID engine) May 24 04:14:21 Tower kernel: md: recovery thread has nothing to resync (unRAID engine)

This is probably a stupid question, but was the 5.0.5 system putting itself into controlled shutdown without any prompting (or even unrelated action, that I could tell) from my end normal? If not, are there any signs of what could have caused that in the log? Right now, my plan's to run a parity check to be safe, followed by a cache drive replacement. At that point, I'll continue moving files to the array, but hate to add things right now if there's a chance anything could go wrong. I'll start the parity check before I fall asleep tonight unless I'm advised to do otherwise on here first!

OK, I cp'd syslog and syslog.1 (didn't see any subdirs that seemed to indicate they'd hold previous logs), and these were the only ones available in the main directory at that time. Hope one or the other holds some clues as to what's going on! Thanks again for any guidance or warnings. syslog.1.txt syslog.txt

So yesterday got pretty busy and the cache drive swap didn't happen, but nothing strange popped up on UnMenu or UnRaid GUI either; stayed out for the night, and just got back home. Everything looks fine on UnMenu, but I notice the syslog summary seems sparse. Went to check the entire thing, and this is all it says: Display syslog /var/log/syslog Click Here to Download Complete /var/log/syslog May 20 04:40:01 Tower syslogd 1.4.1: restart. May 20 09:58:53 Tower dhcpcd[1285]: eth0: renewing lease of 192.168.1.10 (Network) May 20 09:58:53 Tower dhcpcd[1285]: eth0: acknowledged 192.168.1.10 from 192.168.1.1 (Network) May 20 09:58:53 Tower dhcpcd[1285]: eth0: leased 192.168.1.10 for 86400 seconds (Network) Total Lines: 4 Should I be concerned that my system seems to be shutting itself down and restarting its syslogs on its own volition?

Thanks for checking and responding so quickly! I'll give booting the array a shot, mess around for a little while to make sure nothing strange pops up in GUIs or SMB, and if all seems well, go for a power down and replacement of the cache drive. Anything funky comes up, I'll be back here with logs. Thank you again!

System: Supermicro - X8SIL CPU: Intel® Core™ i3 CPU 540 @ 3.07GHz Cache: 128 kB, 512 kB, 4096 kB Memory: 32768 MB (max. 16 GB) Network: eth0: 1000Mb/s - Full Duplex I was planning on upgrading my 19-array 1-cache 1-parity-drive tower from 5.0.5 (last upgrade I'd made) to a current version when I replaced the cache drive (which had started running hot late last year), but life got in the way on both fronts. I hope that delay doesn't prove fatal today! I've been away from home for about a day, and moved about 10gb of files from one network location to my now-strange Tower's cache drive, where they moved into their destination array locations seemingly without a hitch. A few minutes after confirming the files were no longer in my cache directory, I got an SMB disconnect error from windows. Went to check the UnMenu GUI, and that wouldn't load; tried the UnRaid GUI next, and it loaded but said the array was offline. I went straight for the system log button, but the GUI locked and nothing loaded after the log window popped up; within a few minutes, the Tower beeped and what appeared to be a clean shutdown had completed. I started the system back up (log attached) and UnMenu started displaying odd information right away. It showed 8, then 6, "protected array drives" up top, and the remainder of my drives down below in the "Not In Protected Array" section. These remaining drives were each listed with their /dev/sd* name, but each one also had a /dev/sd*1 dupe beneath it. Over the course of a few minutes, those "Not in Protected Array" drives shifted up to the top section, leaving only the cache drive not protected (as expected), but keeping the /dev/sdf & /dev/sdf1 duplicate listing for that cache drive. During this entire drive-shifting process over on UnMenu, UnRaid GUI seemed totally normal, like all was well (a few temperature shift notifications notwithstanding). I can understand just enough of the log to be dangerous, and it sure reads like something not-normal is going on here, but I'll be damned if I can figure out what. As of right now, I don't want to touch a thing until I have a better idea of what is happening, so I figured I'd post immediately and see if anyone has any ideas of how best (and most safely) to proceed. Thanks a ton to anyone for help or guidance if possible! ETA: I have *not* yet tried restarting the array since the reboot, despite "Parity Is Valid" and "Configuration Valid" assurances. syslog-2017-05-19.txt

Bizarre situation here: PreClear user for 4+ years, 6tb PreClearer for 2+ years, and I've never encountered anything like this. I know dangerously little about non-Windows/Mac commands beyond what I've read on this board in specific Unraid support situations. I've been getting refurbished 6tb drives through Amazon lately because they're dirt cheap and I have plenty of time to run PreClear on each one multiple times before throwing a new one in the array. So far, this has worked well: 4 drives, 1 bad (immediately), 3 tests each. 7200rpm drives, about 60 hours total (didn't record these successful PreClears). I've read that the pre and post read segments can slow down as the PreClear hits the edges of each disc (or I'm misremembering that, but that there's some part which "naturally" slows). Just got another refurbished 7200rpm 6tb. Over the course of a couple of days on each PreClear, I noticed that slowdown (dramatically) towards the end of each post read, as well as towards the end of each pre read. Total (successful, no noticeable red flags to me) drive time per pre-clear: ~110 hours. All of these 6tb PreClear sessions have been run on a Rosewill eSATA external dock. Something must be wrong with this drive, right? I ran both instances of PreClear on two separate .screens, which I hope will allow me to pull whatever diagnostic data anyone would need at this point to help me figure out whether something strange is going on with this drive or if the speed drop off is just a quirk of PreClear and my system. Hardware setup: CASE: Fractal Define R4 MOBO: Supermicro MBD-X10SL7-F-O ATX LGA 1150 Intel C222, DDR3 CPU: Xeon E3-1271v3 RAM: 2x 8GB G.SKILL Ripjaws X ECC PSU: Corsair RM-650 INTERNAL CAGE: 4-Drive UnRaid 5.0.5 Thanks for any guidance!

Won't that require turning everything off anyways, though? If I have no network access via webgui nor telnet, and I use the command prompt to get a syslog, is there any way to get that syslog off the flash drive without network connection? I have to power down and remove the flash drive, right? I really hope I'm missing something simple here; if so, syslog incoming.

This might be something simple, but it's definitely never happened to me before - tower seems fine, monitor just shows "root" prompt as usual, but I can't load the webgui (last time I did was this morning when check was at ~85%) and when I try to telnet in, I get a "Could not open connection to the host" error. This tower's been running strong, no problems, no plugins, nor apps, nor even unmenu. Vanilla UnRaid. My instinct was to go for a clean power down through the monitor/keyboard, but wanted to check here and see if I should take any other steps for safety's sake before I do that...

Running another parity check, and it's 51-53 degrees; middle of the case 6tb (parity) is hanging in there at 38 degrees. At the rate the last one finished, this'll be done by tomorrow after work - if temperatures stay consistent, I'll try moving 6tb #2 down to an empty gap in the middle of the cage (right next to the other 7200rpm 6tb, which should be fun) and Parity checking again to monitor temperatures... For context, everything else in "the stack" (white caddies) is almost consistently 40, except the bottom drive at 36. (they're WD Green 2TBs plus a Seagate 2tb). An HGST 4tb (@~44-45) is physically right below the hot 6tb. The two 2tbs (WD Green) in the least ventilated, 5.25 slots are ~32-33 each. This is a nigh-on-full case, by the way - two in the 5.25s, every caddy slot filled, and 3/4 slots in the PSU-adjacent cage filled. It seems like a weird variance in temps across the box to me, but I'm not exactly experienced in this area...

So it's kind of crazy: the first 6tb DOES make a pretty loud noise when the test is run, but you can't hear it through the case. With the case open, it was actually hard to tell the difference in the noises - maybe the internal positioning? 6tb #1 is currently in the cage sitting next to the PSU, while #2 is in the top "hotswap" (white caddy) slot. Noise aside, I decided to try adding 6tb #2 to the array and running a parity check. Which consistently kept 6tb #2 at 53-55 degrees Celsius the whole damn check. The closest drive to that in temperature was a 4tb situated directly below the 6tb (mid-40s); a 2tb in the 5.25 slot directly above the 6tb (little more metal separation there?) was low 40s, and everything else (including the 6tb parity drive in the PSU-adjacent cage) was hanging in there at 40 or less. So, noise isn't weird, but temperature is. I really don't want to find myself stuck buying another $300+ drive or sweating out a sale in the near future, so my instinct is to RMA over the temperature issue alone... Any suggestions before I pull the trigger and mail the sucker out tomorrow?

Drive RMA'd, and its replacement is almost done with its two Preclear cycles; funny thing is, drive STILL makes audible noise through the case, but it's WAY tamer than the last one. Normal hard drive access noise, during the read parts of the Preclear - nothing like that insanely loud "farting" noise from the first one. I'm still a little concerned that I'm hearing anything at all, but at least it's a "normal" hard drive noise now. Assuming I come home to a clean set of Preclear results, I'll probably keep this one... Wish I'd've paid more attention to my first HGST 6tb NAS Preclear process and noticed whether it'd made any noise at all during Preclear reads, but I didnt, so I'll likely just take the "sounds better than the last one" approach and keep my fingers crossed!

That's the direction I've been leaning since the noises started at the beginning of the first Preclear... Oh well, week-long turnaround, 3 days for another 2 cycles, and I can finally say Project Quiet Box is complete. Well, complete-ish.

The wild part is that I cleared an identical drive in the identical way in the identical box not two weeks ago - no noises. Unless this is a brand new firmware issue and I just happened to catch the gap between versions, would it be weird for two drives in the same run to have different performance like that?

Smart report attached. Everything SEEMS fine. It's that damn noise (also, fact that it consistently ran at 51-52 degrees C) that's freaking me out. Go for a third cycle, or RMA before the weekend hits? smart.txt

...trust the Preclear, or RMA that sucker to be safe? I hate to push my timetable back another week, but I'm leaning towards better safe than sorry. This is noticeable noise through a Fractal R4 (insanely quiet) case, and the hard drive in question is an HGST 7200rpm NAS 6tb. Every ten seconds or so on a read, every minute and a half or so on write. Like a normal hard drive "crunch" on steroids; it was almost a "fart" at first (for lack of a better descriptor), but it's smoothed out into something closer to heavy hard drive activity noise (but still the first drive activity noise I've heard through this case, which has run 2-cycle Preclears on 12 other drives now). Any advice from the hard drive experts around would be greatly appreciated!

This is kind of funky. Filled the tower with disks, Precleared, started array - no problem. Moved a few files to try it out after parity calisthenics. No problem. Got in a 6tb from a sale that I'll be using as a primary disk. Turned off, installed, booted. 6TB there, 2TB missing. Powered down, went back to check cabling. Everything seemed secure, so dis/reconnected the missing drive. Booted, saw 2tb was still gone, gave up on it as failed disk (also did this for a 4TB that Precleared fine, but wouldn't show up a couple of boots later). Started preclearing 6tb. I go into web GUI to start up the array, and notice a 4TB is missing. I go back to the monitor to check my disk /sk*'s, and now the 2tb I gave up on... Is showing up again? So I'm running a Preclear on the 6tb and the wonky 2tb. When those are done, I'm dis/reconnecting everything until I can completely rule out wiring. ...which may not take long. 6tb's in the top tray (least headroom), so maybe it's just an echo, but for lack of a closer descriptor, it sounds like it's "farting" every two or three minutes. I have a feeling I'll be RMA'ing this one before week's end. BUT THEN, once I get this Preclear / ghost drive mess sorted, I'll take photos for the thread. Haven't forgotten!

I might be missing something completely obvious here, but is there a trick to installing 3.5" HDDs in the 5.25" bays at the top of the case? Do I need to order some sort of extra internal harness, or turn them 90 degrees (though couldn't figure out the plugs that way)? Apologies for what may be a very stupid question, but figured I'd ask. Also, I'm going through several "aged" disks that have worked well in past Unraid boxes (and a handful that were on the verge of dying, I think); my current plan is to just Preclear each twice before adding them to a new array. Should I be doing anything more intensive, or if Preclear's enough, should I be looking for any unusual warning signs beyond the normal "allocated" numbers at the end?

CERTAIN. You know how Firefox leaves up thumbnail previews of previously visited sites? For most of the month of January, I had one up for the webgui, with two DISK_DSBL and red balls. It was pretty depressing. Stays off for the better part of a month, boots up, and the disk that was running screamingly hot and is incredibly close to failure (per SMART) or at least old age death (sucker's over 3 years) actually survived long enough to rebuild the one that WAS dead - or at least I think was dead? I'm going to try preclearing that sucker a few times once I confirm I won't need to pull anything off of it w/Reiser. It just seems like an UnRaid Christmas Miracle that waited a little over a month to kick in. I'll take it. I just wish my experience could've helped some others, but I'm OK with going down in history as host to an unraid mystery.

So I'm not even 100% set up with this box yet (pictures coming, I promise!), but I'm loving the noise factor so much that I'm seriously considering moving at least one if not both of my old multi-cage multi-fan towers into these cases. HOWEVER, these other two are archive towers in the basest sense. Writes will be rare; once stuff is on there, it's staying. No plans on any applications of any kind. This means those systems could be the opposite of a beast, so long as they're unraid-sufficient. How "cheap" could I go on a motherboard and still retain 14 SATA slots (with or without an add-on card)? Same question for RAM and CPU; seems like I'd keep pretty much everything else the same. With those cases still at $80 each at Newegg, even if I don't pull the trigger on one or both of these "anti-beast builds" for awhile, I kind of want to grab a case or two now if I know I'll be filling them in at some point later... Any thoughts on a slimmed-down version of this build are greatly appreciated!