mattbr

Hey, I'm trying to figure out how to make RSync work over an Unassigned Devices mounted SMB share. I'm trying to sync around 200k files, over several thousand folders, and it's simply refusing to have a friendly discussion about special characters. I'm -avsP'ing everything, because I'm not quite that stupid, but there's still a whole bunch of files that won't copy. I've tried DirSyncPro as well, to no avail, so my current assumption is that it's something that has to do with Unassigned Devices... Any way around this without having to go at it manually / rename the offending files and folders ?

Yeah, figured this wasn't the one to cut my dockerisation newbie teeth on... looks like it's VM time, folks ! (and thanks for taking the time to look into it, @Squid)

Hey guys, would anyone with the knowledge on how to do this be willing to take the time to make an UnRaid template for this PFSense log visualiser ?

For those with adoption problems, this seems to have done the trick. It'd been mentioned here, but without a walkthrough. For some reason, the GUI approach didn't work for me. TL;DR: ssh into the AP. then mca-cli Now issue the set-inform command with the IP address of your Unifi controller [in our case, the IP of your UnRaid box. Don't forget to change to the correct port if you're not allocating 8080 to the controller]. set-inform http://192.168.3.2:8080/inform

Figured - and I'd assume assigning the data drives randomly won't change a thing since parity is going to be rebuilt. (in case someone else runs into something like this: remember to turn Docker off when you restart the array, in case one of the apps start hitting one of the drives. Looks like it happened here, so my (possible) pain is your gain)

There's a new config step before that, right ? So new config - check which don't have a FS - new config - assign the drives without a fs to parity - start.

Oookay... so, it looks like something happened, either from me hitting the power button, or from the usb drive going down. Super.dat won't fly, and one of the drives shows as having no filesystem (I'd assume that was the parity drive, but I was running dual parity, so...). Is there a human-readable version of the previous drive assignments somewhere ?

Great, thanks a lot for the help !!!

Well, wouldn't mount this time... but booted fine from a freshly flashed key. So I guess that's that... I'm a moron who didn't do a screenshot of my drive configuration, is that stored somewhere, or should I risk booting things up with the old super.dat ?

Hi guys, my unraid box went down yesterday. Started looking into it this morning, and I'm a bit stumped. My feeling is it could either be an LSI controller or a cable gone bad (there's a bunch of drives missing from the LSi bios page), but the kernel panic message itself seems to point more towards a system thumbdrive issue, (it happens right after there's an attempted mount on it) even though it mounts and copies fine on an other machine. Anybody got ideas ? X10SDV kernel panic.mp4

will do ! thanks again for all the help !!!

Running 6.2.4 and a 950 pro, it hasn't missed a beat. Those things do tend to run a little bit warm, though.

Ok, so, back at this (was travelling for a bit), and with a nice external drive full of mangled filenames - by the volume of data, there hasn't been much if any loss, and what I don't have in one of two other arrays, I should be able to, erm, rebuild anyway, so it isn't like I'm losing my life's work if I wipe the drive. Just booted the array up, problematic drive not plugged in. It shows as missing, array stopped, everything looks to be assigned as it should (minus the problem drive obviously), disk prefs set to start with a stopped array. What's the best course of action from here ? NewConfig, rebuild parity for the good drives and after that add the problematic one as an empty drive ? (in terms of data rebuilding, the plan is to wait for the screwed drive to come back online, then go read the rsync docs to figure out how not to touch anything that's been added recently to make sure any files that might have been upgraded on the still-good part of the array don't get stepped back to a previous incarnation - I'd assume du -hs * | sort -h would still work to, in this case, give me the names of the empty folders, right ?)

Definitely should've asked for help sooner... I was mostly trying to prevent damage to the other drives in the array... hence the pulling of the "bad" drive and the shutdown of the array. Seeing the "bad" drive and parity being written freaked me out, since I figured it'd mean certainty of losing both - hence "ok, let's try to minimise risk to the rest of the data, see if anything at all can be salvaged, and take it from there" approach. So, practically, it's "reconnect the drive, press the go button", the array will then boot stopped, newconfig, don't trust parity, let it do it's thing, and then start getting whatever was on that drive back on, right ? No need to pre-clear it again ?

Thought I'd done the stop - unassign - start unassigned - stop - reassign dance, though clearly messed up somewhere and just went "yay ! unassigned devices says it's mounting and ok <sigh of relief>!" or something stupid. I'm doing the repair from CLI on another machine - the server is shutdown, I didn't want to risk hosing the other data drives as well.

Hey, yeah, know I should've asked... but, well, live and learn... Thing is there was no option to rebuild the disk that I could find, and stopping / reassigning just led it to staying emulated. It's formated in XFS. The superblock is hosed, says xfs_repair, which is running.

So, dinked around on a running array, touched a sata cable the wrong way, tried to follow the For unRAID v6 section of the wiki, and things went wrong. The single affected drive got formatted before being added back (as an empty drive), and when I restarted a parity check to try to rebuild, the only writes were to parity (which was, prior to this, good and checked, by luck, there was a cron'd parity check overnight) and to the affected drive (in about equal numbers). I've stopped the array, booted up a systemrescueCD on another machine to see if there's anything salvageable on the drive itself, the data on the drive was, I think, generally pretty much backed up offsite and not exactly essentially anyway, but getting it back would be nice, and, most importantly - how can I make sure I don't hose the other drives in the array when I start it back up ?

Also, there's this cute little kink with the SM BMC where you need to physically unplug the device to make it reset and actually apply the cooling profile... lowering the thresholds fixed the rest of it, thanks a lot for the hint !!! (while I'm at it - I'd also corrected the temp thresholds for the M.2, since they're significantly higher than what you'd have for those spinny 60's things we still have to live with for the time being... not sure it had any effect other than no more blinky gifs, which is something)

And useful to stop the SM boards from the annoying cycling thing, too I'd tried the raw commands, they seemed to go through but don't seem to have any effect. Thanks for the pointer - forgot to mention I'd already set the IPMI to optimal. Best I can see is an error during boot with ipmifan saying the motherboard isn't supported yet...

Hey, I'm having this weird annoying issue with a Supermicro X10 xeon-d board, which had the SM "cycling" thing going at default... Switched a few things around in the IPMI settings, and the board will now boot with fans at a reasonable speed, which'll ramp up to full-on after a minute or so, so I'd suspect only once Unraid loads... I mean, it's not throwing errors or anything, it's mostly that it probably makes the box noiser than it could or should be... (I've tried putting the upper thresholds to proper variants of the manufacturer's max speeds, didn't change a thing, and also tried adding the Dynamix temp/autofan plugins on top, no luck with that, can't detect the PWM controller or any other temp sensor than the CPU's coretemp) Any clue as to what I'm doing wrong ? Section 607_FAN1 ## this is the silent wings case fan ## Possible values: Yes/No Enable_All_Event_Messages Yes ## Possible values: Yes/No Enable_Scanning_On_This_Sensor Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Recoverable_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Recoverable_Going_High Yes ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Critical_Threshold 300.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Critical_Threshold 200.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Recoverable_Threshold 100.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Critical_Threshold 1600.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Critical_Threshold 1700.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Recoverable_Threshold 1800.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Positive_Going_Threshold_Hysteresis 100.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Negative_Going_Threshold_Hysteresis 100.000000 EndSection Section 674_FAN2 ## this is a noctua 92mm ## Possible values: Yes/No Enable_All_Event_Messages Yes ## Possible values: Yes/No Enable_Scanning_On_This_Sensor Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Recoverable_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Recoverable_Going_High Yes ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Critical_Threshold 400.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Critical_Threshold 300.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Recoverable_Threshold 200.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Critical_Threshold 2100.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Critical_Threshold 2400.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Recoverable_Threshold 22000.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Positive_Going_Threshold_Hysteresis 100.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Negative_Going_Threshold_Hysteresis 100.000000 EndSection Section 741_FAN3 ## this is a noctua F12 ## Possible values: Yes/No Enable_All_Event_Messages Yes ## Possible values: Yes/No Enable_Scanning_On_This_Sensor Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Recoverable_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Recoverable_Going_High Yes ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Critical_Threshold 400.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Critical_Threshold 300.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Recoverable_Threshold 200.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Critical_Threshold 2100.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Critical_Threshold 2400.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Recoverable_Threshold 22000.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Positive_Going_Threshold_Hysteresis 100.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Negative_Going_Threshold_Hysteresis 100.000000 EndSection Section 808_FAN4 EndSection Section 875_FANA ## this is a noctua 92mm ## Possible values: Yes/No Enable_All_Event_Messages Yes ## Possible values: Yes/No Enable_Scanning_On_This_Sensor Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Assertion_Event_Upper_Non_Recoverable_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Critical_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Lower_Non_Recoverable_Going_Low Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Critical_Going_High Yes ## Possible values: Yes/No Enable_Deassertion_Event_Upper_Non_Recoverable_Going_High Yes ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Critical_Threshold 400.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Critical_Threshold 300.000000 ## Give valid input for sensor type = Fan; units = RPM Lower_Non_Recoverable_Threshold 200.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Critical_Threshold 2100.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Critical_Threshold 2400.000000 ## Give valid input for sensor type = Fan; units = RPM Upper_Non_Recoverable_Threshold 22000.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Positive_Going_Threshold_Hysteresis 100.000000 ## Give valid input for sensor type = Fan; units = RPM; 'None' to not use hysteresis Negative_Going_Threshold_Hysteresis 100.000000 EndSection

Yeah, I would've expected them to be a touch quicker, but it's close enough to not really be high on my worry list. I'll split up the ports when I get around to it and see what happens the next time it's time for a parity check.

So, this is really summary, but just in case it can be of use to someone in deciding something, here's a little tidbit. I've just finished parity checking a new, fresh, 4-drive non-pro WD Red (WD80EFZX) array, running of one of the SAS ports of a supermicro xeon-d board. Duration: 16 hours, 35 minutes, 27 seconds. Average speed: 134.0 MB/sec I also have an array of 5 only Seagate Archives (ST8000AS0002) drives running off the sata ports of an X10SL7-F, with a bit north of 20TB of data on it, depending on the day. Duration: 15 hours, 33 minutes, 27 seconds. Average speed: 142,9 MB/s (there's a bit of variance in the parity-checking history, depending on writes - slowest I've seen it is 81,2 , probably due to heavy non-parity checking activity, fastest has been 144,2) Single parity in both cases. Not sure how replicable all of this is, or how it'd relate to arrays with both shingled and non-shingled drives, or if there's some other variable (likely one between the keyboard and the screen), so take it all with a pinch of salt.

Awesome, thanks !

Thanks for the hint - normally, I *should* be... what I don't quite get is if I borked my config somehow, and ended up with a parity-protected cache drive or something stupid, or if there's something else at play that generates that bottom result.

So, I'm trying to figure out why unrars aren't hitting cache speed (and unrar'ing seems to choke the system - everything *should* be on cache, but system stats during unrar are more consistent with array drive speeds and WebGui becomes unresponsive, and nope, doesn't seem to be CPU or RAM). In the process, I got this interesting result from the diskspeed graph... CLI output is diskspeed.sh for UNRAID, version 2.4 By John Bartlett. Support board @ limetech: http://goo.gl/ysJeYV /dev/sdb (Cache): 558 MB/sec avg /dev/sdc (Disk 4): 158 MB/sec avg /dev/sdd (Disk 1): 159 MB/sec avg /dev/sde (Disk 2): 163 MB/sec avg /dev/sdf (Parity): 158 MB/sec avg /dev/sdg (Disk 3): 156 MB/sec avg and then, that confusing little line on the bottom - is it a bug in the script, or is there something else at play I'm missing here ?