Aaron Oz

I searched and found people asking to reorder their drive numbers, but couldn't find an answer to removing unused drive numbers. I've shrunk my array down as I've added bigger drives. It's not a big deal, mostly a curiosity, but I'm not left with two drive numbers skipped, in my array. I could just make 10->7 and that would do it. It's a minor thing, I'm just more curious about the possibility and/or process. Or, is having empty drive slots a negative in any way?

Perfect. Thanks! Much easier to exclude the 1 in this case.

I'm shrinking my array one drive, and the last time I did this, I asked myself this question. So before I do this again, I thought I'd get a solid answer. If you Exclude a drive from a share, do you also need to "Include" all drives except for the one that's been excluded? (A picture is worth 1000 words)

It doesn't look like SAS spin down is on development radar. I bet $10 that Unraid just isn't able to spin down SAS drives My log just fills up with this (I think it best to remove SAS drives from spin down): Jan 20 13:21:10 Tower kernel: mdcmd (132099): spindown 10 Jan 20 13:21:10 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:10 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:11 Tower kernel: mdcmd (132100): spindown 2 Jan 20 13:21:11 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:11 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:11 Tower kernel: mdcmd (132101): spindown 10 Jan 20 13:21:11 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:11 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:12 Tower kernel: mdcmd (132102): spindown 2 Jan 20 13:21:12 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:12 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:12 Tower kernel: mdcmd (132103): spindown 10 Jan 20 13:21:12 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:12 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:13 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:13 Tower kernel: mdcmd (132104): spindown 2 Jan 20 13:21:13 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:13 Tower kernel: mdcmd (132105): spindown 10 Jan 20 13:21:13 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:13 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:14 Tower kernel: mdcmd (132106): spindown 2 Jan 20 13:21:14 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:14 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:14 Tower kernel: mdcmd (132107): spindown 10 Jan 20 13:21:14 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:14 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:15 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:15 Tower kernel: mdcmd (132108): spindown 2 Jan 20 13:21:15 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:15 Tower kernel: mdcmd (132109): spindown 10 Jan 20 13:21:15 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:15 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:16 Tower kernel: mdcmd (132110): spindown 2 Jan 20 13:21:16 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:16 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:16 Tower kernel: mdcmd (132111): spindown 10 Jan 20 13:21:16 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:16 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:17 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:17 Tower kernel: mdcmd (132112): spindown 2 Jan 20 13:21:17 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:17 Tower kernel: mdcmd (132113): spindown 10 Jan 20 13:21:17 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:17 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:18 Tower kernel: mdcmd (132114): spindown 2 Jan 20 13:21:18 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:18 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:18 Tower kernel: mdcmd (132115): spindown 10 Jan 20 13:21:18 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:18 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:19 Tower kernel: mdcmd (132116): spindown 2 Jan 20 13:21:19 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:19 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:19 Tower kernel: mdcmd (132117): spindown 10 Jan 20 13:21:19 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:19 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:20 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:20 Tower kernel: mdcmd (132118): spindown 2 Jan 20 13:21:20 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:20 Tower kernel: mdcmd (132119): spindown 10 Jan 20 13:21:20 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:20 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:21 Tower kernel: mdcmd (132120): spindown 2 Jan 20 13:21:21 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:21 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:21 Tower kernel: mdcmd (132121): spindown 10 Jan 20 13:21:21 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:21 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:22 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:22 Tower kernel: mdcmd (132122): spindown 2 Jan 20 13:21:22 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:22 Tower kernel: mdcmd (132123): spindown 10 Jan 20 13:21:22 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:22 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:23 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:23 Tower kernel: mdcmd (132124): spindown 2 Jan 20 13:21:23 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:23 Tower kernel: mdcmd (132125): spindown 10 Jan 20 13:21:23 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:23 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:24 Tower kernel: mdcmd (132126): spindown 2 Jan 20 13:21:24 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:24 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:24 Tower kernel: mdcmd (132127): spindown 10 Jan 20 13:21:24 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:24 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:25 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:25 Tower kernel: mdcmd (132128): spindown 2 Jan 20 13:21:25 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:25 Tower kernel: mdcmd (132129): spindown 10 Jan 20 13:21:25 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:25 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:26 Tower kernel: mdcmd (132130): spindown 2 Jan 20 13:21:26 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:26 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:26 Tower kernel: mdcmd (132131): spindown 10 Jan 20 13:21:26 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:26 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:27 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:27 Tower kernel: mdcmd (132132): spindown 2 Jan 20 13:21:27 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:27 Tower kernel: mdcmd (132133): spindown 10 Jan 20 13:21:27 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:27 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:28 Tower kernel: mdcmd (132134): spindown 2 Jan 20 13:21:28 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:28 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:28 Tower kernel: mdcmd (132135): spindown 10 Jan 20 13:21:28 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:28 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:29 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:29 Tower kernel: mdcmd (132136): spindown 2 Jan 20 13:21:29 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:29 Tower kernel: mdcmd (132137): spindown 10 Jan 20 13:21:29 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:29 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:30 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:30 Tower kernel: mdcmd (132138): spindown 2 Jan 20 13:21:30 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:30 Tower kernel: mdcmd (132139): spindown 10 Jan 20 13:21:30 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:30 Tower kernel: md: do_drive_cmd: disk10: ATA_OP e0 ioctl error: -5 Jan 20 13:21:31 Tower kernel: mdcmd (132140): spindown 2 Jan 20 13:21:31 Tower emhttpd: error: mdcmd, 2639: Input/output error (5): write Jan 20 13:21:31 Tower kernel: md: do_drive_cmd: disk2: ATA_OP e0 ioctl error: -5 Jan 20 13:21:31 Tower kernel: mdcmd (132141): spindown 10

Brilliant! Thanks for the suggestion.

Big drives are so cheap now, that I'd like to start reducing the number of drives in my server. I read the instructions on how to do it via 2 different methods. Looks good, no problem. The question I have comes to manually moving all the files off that drive, and onto another. One of the folders on the drive I'd like to remove contains a lot of Plex data. What I see are hundreds of folders within folders, but only a few of them have any files. Which makes sense, because that folder is shared across many drives. From a windows interface, what would happen if I just move that folder from the drive I'm removing, to another drive that already has that folder? I believe windows is going to ask me if I want to replace it... but I don't want it to replace anything. Will it just move any of the files into existing sub-folders on the other drive? Or maybe there a more intelligent way to move the folders via SSH? I know enough Linux to get by, but a command to move only files from one folder to another that already exists in another drive, is beyond my knowledge. Thanks for any thoughts!

Cool. Thanks for the input. Yeah, they've never not spun up. Is there a variable to tell UnRaid to delay before starting the array? If my kids or wife decide to turn on the server while I'm not around, they won't know to log in and start the array manually. It would be nice if starting the array could be delayed a few more seconds.

Interesting... great observations. And Frank, your thinking is correct, except the slow spin-up drives isn't due to a cold environment. Those two disks are SAS. They are connected to a Dell PERC H310. Watching the boot sequence, I noticed that those drives get spun up slower (........). So it seems the array tries to start before the drives are fully spun up. By the time I go in there, the drives are up and connected and the array is complete. That leads me to think a couple things; SAS SCSI drives aren't used in UnRaid that often and they all spin up more slowly (I don't think that's true) For some reason my H310 / SAS drives spin up more slowly than anyone else's (can't explain that, but it seems likely) I've missed an obvious setting, just like I missed having the onboard controller in IDE VS AHCI. FYI, that H310 is controlling two other SATA drives, too. So I don't think it's the card causing the problem.

Whelp... doesn't seem to have been the battery. I just happened to put an entirely new MB into my server. All works great! First boot up, no problem. I shut the server down last night and just restarted it this morning, and I had "State Configuration" and the array was offline. Everything was right, so I started it, no problems. I've attached the full diagnostics zip file. If anything can see anything, that would be appreciated! tower-diagnostics-20181219-0804.zip

Recently, upon power up (from a complete power down), UNRAID starts with the arrayoffline. It says "stale configuration". But all looks correct. If I just reboot the server from there, upon reboot, the array is started automatically. Looking at the log file (attached), I see an error that says; kernel reports TIME_ERROR: 0x41: Clock Unsynchronized Would it make sense that if a CMOS battery is dead, and the motherboard can't keep time when the power is off, UNRAID would see the configuration as stale due to a time mismatch? That theory makes sense to me because UnRaid fixes the clock and with a reboot, the motherboard keeps the updated time. So that's why it starts the array. But I thought I'd check with those more knowledgeable than myself to make sure this isn't a sign of a potentially bigger problem. tower-syslog-20181216-1236.zip

IDE drives are both officially replaced! Yeah, I left them both attached as-is, to maintain proper master/slave as each one was swapped out. Only after both were swapped did I pull both of them. Thanks again.

OMG! YES!!! THANK YOU, THANK YOU!!! Tears of happiness. I NEVER would have though about an IDE cable going bad. Drive 2 is once again, happily being rebuilt and that IDE cable is in the trash. Let me know how I can buy you a beer.

Interesting idea! Trying now.

Ugh... by the look of some of these logs, I might have fried those old IDE drives. tower-diagnostics-20181123-1023.zip

Okay, thanks for your insight, John. That sounds like a reasonable idea. Regarding logs, unfortunately, I was forced to power cycle reboot once it went unresponsive. You're right regarding being a bad idea moving them to a WinPC. There are some good tools in Linux, so I'll leave the drives in the UnRaid server. Just doing some "checks" I got the dreaded "Unknown code er3k 127" message. I'll continue searching the forum and see if any more responses come in.

If it's the RFS superblock and if reiserfsck --rebuild-sb[X] worked, is it possible UnRaid could recognize the disks again? I'm tempted, but don't want to run anything on those disks until someone who knows what their doing says it's worth a try...

Yeah, pretty sure the IDE drives were disconnected during the rebuild. "Partition format: Unknown". Probably nothing I can do short of data recovery. Maybe an old version of TestDisk that supports ReiserFS...

I believe I'm about to experience my first data loss with UnRaid since I bought my key in 2006. And it's all my own fault My Disk 2 was being rebuilt (my fault, detailed in another thread) and during the rebuild, the server went unresponsive (to login's either local or via SSH). I also think I know why this might have happened, detailed in my "Post Mortem" below the image. So, likely, my fault. I hoped it was still rebuilding and that a service went down or something... but 15 hours later (long after a rebuild would have been complete), I decided to reboot. Disk 2 did not rebuild, and my two old IDE drives (which I was planning on replacing this weekend and why I'm working in disks') are now saying "Wrong". But they are the right disks. I think I'm dead in the water. Should I try to read the data off the two 400 GB drives? In essence I'd just be losing the data from the 1TB drive... Then, if I do that, do I change all 3 of these drives to "no device"? But somehow I'd have to force UnRaid to rebuild the parity without those 3 devices... Post Mortem, I think I know why the two IDE drives might have gone offline during the rebuild. I had to plug in 1 fan while the server was rebuilding, and might have jostled that $*&!@ finicky IDE cable so that the drives went offline. That sounds about like my luck so far. Anyway, thoughts would be welcome. My gut reaction is to take the 400GB IDE drives to my WinPC and try to read the data off of them.

Yeah, thanks! UnRaid is happily rebuilding the drive, now. Relatively inexpensive education, I suppose.

Thanks, Trurl. Agreed, bad idea. I've never plugged an UnRaid drive into a WinPC before. And never planned to do it this time, either. So... some insight that might help anyone new to SAS drives; this is why it happened. I have two SAS drives I just reformatted to 512b/sector. I added them to the drive housing for my server (it holds three drives per housing). One of the SATA drives from my UnRaid server was already in this housing. I wanted to do some testing and such to the SAS drives on my Windows machine. So I ran the housing with 3 drives over to my WinPC and plugged them in. Now, since SAS drives are a different connection than SATA, my two SAS drive connectors would only plug into the SAS drives, so there's no way I would accidentally plug my SATA UnRaid drive onto my SAS cable, right? Except I'm new to SAS drives, and just learned that the SAS connector is backwards compatible the SATA/Power connections. So, without any need to think or checki/look, because there's no way I could have it hooked up wrong (as was my assumption), I deleted the partition on what I though were my two SAS drives. Except I deleted the partition to one SAS drive and from the existing UnRaid SATA drive. Perfect example of not paying attention. Lesson learned.

Ah! So happy to have asked the question, then. Thanks! Hearing you spell it out, that makes sense.

I've done a few silly things around PC's in my life, this is right up there. Long story not told; I deleted the partition from one of my UnRaid drives while it was plugged into a PC. I just put the drive back into my UnRaid server without a partition. I'm surprised that the array is started, without any warnings. It sees the correct drive in the correct spot, so I hope I've not confused UnRaid with this issue. So-- I know I need to have UnRaid rebuild the drive, but what's the proper procedure for rebuilding the exact drive that was in there originally? It currently says; Unmountable disk present: Disk 2 • ST31000524AS_6VPEE2RK (sdm) I have a checkbox: Format will create a file system in all Unmountable disks, discarding all data currently on those disks. Yes I want to do this Do I let it format the drive, and then it will ask if I want to rebuild the array using the newly formatted drive?

Thanks Squid! I'll take a look at that option.

Interesting. Thanks, will do. I had 15 more days on the trial, so didn't consider that.

I believe this message is based upon the new release being available, correct?