TexasUnraid

Just wanted to say that the automatic trackers seems to be working since the last update. I have restarted a few times and they are still there! So much easier and makes a massive difference in hard to find linux ISO's.

Update, I was in the process of clearing some data off some NTFS formatted drives. Once I removed the NTFS partition everything seems to be working normally again with the pre-clear plugin still installed and the same drives still connected. I have noticed this in the past as well, NTFS drives simply being attached to the system seems to cause strange things to happen.

That is really odd it would suddenly cause an issue and really inconvenient to have to reinstall it anytime I want to use it. Did something change recently?

I am getting this message spammed for all my UD drives anytime I refresh the main page in unraid. It also takes a really long time for the UD to load. unassigned.devices: Error: shell_exec(/usr/bin/lsof '/mnt/disks/disk' 2>/dev/null | /bin/sort -k8 | /bin/uniq -f7 | /bin/grep -c -e REG) took longer than 3s!

Is it possible to hide the historical devices in the new layout?

Is it possible to update the nzbgetVPN container to support wireguard like binhex new VPN containers? I am getting about half the speed I used to since the next gen servers went live but wireguard gets full speed on qbittorrent.

Correct, I should of made that clearer. It would be really nice to be able to see and then edit all the paths for dockers / VM's in one location. Possibly laid out in a format listing all the paths and then able to click each path and see what all it is assigned to. Along with a search option and filters to see any paths linked to the array, cache, user etc so you can track down rouge mappings. This allows for several things, you can more easily find rouge mappings, you can then edit mappings in bulk and ensure that mappings match between containers when needed. It would be a cool plugin if someone made it that is for sure.

Not this particular situation so much as in general when a path needs to be changed or you want to change a path but the effort to find all the mappings can get annoying lol. I just had to deal with this, so it is kind of a fresh wound lol.

Times like this is where a script / plugin to update all the docker/VM at once would be amazing. Always hard to know if you got them all when done manually.

Does anyone know of a way to gather all the items for subfolders in a share onto a single drive? Example; Media/shows/shows folder here I would like for all the subfolders under shows to be gathered together onto a single disk. This way worst comes to worst and a drive was lost, I know I have all the files for a particular show on a single disk. I have a script that runs regularly that gives me a list of all the folders on each disk, so if this happened I could re-rip any lost shows but this only really works if the shows are stored together on a single disk. If not then I have to go through a much more tedious process. This is also good for drive spin up, as generally we watch 1 or 2 shows at a time and by having them stored on a single disk, less drives will need to be spun up on a regular basis. Yes, I have folder splitting setup now but trying to clean up some items from when it was set incorrectly by mistake (miscalculated the depth).

Thanks for the info, it is very helpful. Very similar situation to here in Texas about ~8 months of the year anyways.

Interesting, didn't know they could go that low and still keep things cool. What temps do the drives sit at with 1000rpm? What kind of drives are you using?

What is the min RPM you can get the fans down to? My server lives in the living room, I find much more then ~1000RPM to be noticeable with most fans. Above ~1300 can get annoying when watching a movie for example. With 120mm fans I have found I can generally keep things cool and stay around ~1000rpm or less depending on the room temp. During the summer I have to bumb them to 1000, in the winter I can turn them down to 600-800.

The only point of this plugin is to allow for the use of turbo write without always forcing all drives to be spun up anytime you write to the array. You can enable turbo (aka, reconstruct write) all the time in the disk settings menu but if you want to write a 100kb file to 1 disk, all disks will be spun up to do that. This plugin allows for only the drive that is being written to, to be spun up and then if a lot of drives are being written to it will automatically switch over to turbo write for faster write speeds. Lucky you on the supermicro case, I have been looking for one myself but they are all stupidly expensive all the sudden. Yours is a 3U case right? Is it possible to fit a 120mm fan in there? I have been debating looking for the 3U version but only if I could cram 120mm fans in place of the stock ones. Not scared of some custom fab, just not sure if the chassis is physically tall enough. edit, realized it must be a 2u, the 3u are 16 bays.

It only counts data drives, so in your case you would select 1, otherwise it would not do anything. Also, 2 parity drives with only 2 data drives is serious overkill. Think someone did the calculations and a second parity didn't start making sense by the numbers until something like 15-20 data drives IIRC. Personally I would pull the second parity drive and use it as a cold backup of the most important data, possibly get another data drive to make a mirror backup of the data drives you store offline in a safe place like a fire safe. Parity is not a backup, it is only the first line of defense. The only things I trust to parity are things that can be replaced.

Small bug report, I noticed that the pre-clear button is not available next to the drive in UD anymore after the failed post read. Went to the plugin screen and decided to run a test, I started another verifcation run and then manually went over and turned off the USB dock for a second and then turned it back on. It failed in the same way, says the drive is not zeroed and same basic errors, just less of them. So I think I am going to go with it was just a USB dock error and the drive/system are fine unless someone can point out a strong reason to think otherwise?

Just had pre-clear fail during post read. Although looking at the logs it looks like the drive might of disconnected momentarily and that caused the error? It is in a USB dock so disconnecting is possible over a 72 hour period. Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 4073318255 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 27344764927 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 26952798208 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 0 Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 26952796168 op 0x0:(READ) flags 0x80700 phys_seg 255 prio class 0 Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 141407706 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 3 Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 26952796168 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Nov 23 08:22:30 NAS kernel: Buffer I/O error on dev sdu, logical block 3369099521, async page read Nov 23 08:22:30 NAS kernel: blk_update_request: I/O error, dev sdu, sector 26952796168 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Nov 23 08:22:30 NAS kernel: Buffer I/O error on dev sdu, logical block 3369099521, async page read Nov 23 08:22:30 NAS kernel: sd 9:0:0:0: [sdu] Synchronizing SCSI cache Nov 23 08:22:30 NAS kernel: sd 9:0:0:0: [sdu] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 Nov 23 08:22:30 NAS rc.diskinfo[13766]: SIGHUP received, forcing refresh of disks info. Nov 23 08:22:30 NAS kernel: usb 4-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd Nov 23 08:22:31 NAS kernel: usb-storage 4-1:1.0: USB Mass Storage device detected Nov 23 08:22:31 NAS kernel: usb-storage 4-1:1.0: Quirks match for vid 174c pid 55aa: 400000 Nov 23 08:22:31 NAS kernel: scsi host9: usb-storage 4-1:1.0 Nov 23 08:22:32 NAS kernel: scsi 9:0:0:0: Direct-Access WDC WD14 0EDFZ-11A0VA0 0 PQ: 0 ANSI: 6 Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: Attached scsi generic sg20 type 0 Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: [sdu] 27344764928 512-byte logical blocks: (14.0 TB/12.7 TiB) Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: [sdu] 4096-byte physical blocks Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: [sdu] Write Protect is off Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: [sdu] Mode Sense: 43 00 00 00 Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: [sdu] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Nov 23 08:22:32 NAS kernel: sdu: sdu1 Nov 23 08:22:32 NAS kernel: sd 9:0:0:0: [sdu] Attached SCSI disk Nov 23 08:22:33 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd - read 13799831638016 of 14000519643136. Nov 23 08:22:33 NAS unassigned.devices: Disk with serial 'WDC_WD140EDFZ-11A0VA0_9LG7XPWA', mountpoint 'WDC_WD140EDFZ-11A0VA0_9LG7XPWA' is not set to auto mount and will not be mounted. Nov 23 08:22:33 NAS unassigned.devices: Issue spin down timer for device '/dev/sdu'. Nov 23 08:22:33 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: elapsed time - 23:58:53 Nov 23 08:22:33 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd command failed, exit code [1]. Nov 23 08:22:33 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13792360529920 bytes (14 TB, 13 TiB) copied, 86255.3 s, 160 MB/s Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6577324+0 records in Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6577323+0 records out Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13793646084096 bytes (14 TB, 13 TiB) copied, 86268.2 s, 160 MB/s Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6578006+0 records in Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6578005+0 records out Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13795076341760 bytes (14 TB, 13 TiB) copied, 86282.6 s, 160 MB/s Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6578622+0 records in Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6578621+0 records out Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13796368187392 bytes (14 TB, 13 TiB) copied, 86295.3 s, 160 MB/s Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6579313+0 records in Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6579312+0 records out Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13797817319424 bytes (14 TB, 13 TiB) copied, 86309.4 s, 160 MB/s Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6579966+0 records in Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6579965+0 records out Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13799186759680 bytes (14 TB, 13 TiB) copied, 86323.5 s, 160 MB/s Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: dd: error reading '/dev/sdu': Input/output error Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6580271+1 records in Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 6580271+1 records out Nov 23 08:22:34 NAS preclear_disk_9LG7XPWA[32066]: Post-Read: dd output: 13799829540864 bytes (14 TB, 13 TiB) copied, 86330.4 s, 160 MB/s Nov 23 08:22:41 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 5 Reallocated_Sector_Ct 0 Nov 23 08:22:41 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 9 Power_On_Hours 70 Nov 23 08:22:41 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 194 Temperature_Celsius 33 Nov 23 08:22:41 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 196 Reallocated_Event_Count 0 Nov 23 08:22:41 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 197 Current_Pending_Sector 0 Nov 23 08:22:42 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 198 Offline_Uncorrectable 0 Nov 23 08:22:42 NAS preclear_disk_9LG7XPWA[32066]: S.M.A.R.T.: 199 UDMA_CRC_Error_Count 0 Nov 23 08:22:42 NAS preclear_disk_9LG7XPWA[32066]: error encountered, exiting... SMART is still fine with no signs of issues except throughput performance is a bit lower then my other drives (114-116 mostly but they are 12TB vs 14TB) 1 Raw read error rate 0x000b 100 100 001 Pre-fail Always Never 0 2 Throughput performance 0x0004 135 135 054 Old age Offline Never 108 3 Spin up time 0x0007 093 093 001 Pre-fail Always Never 315 4 Start stop count 0x0012 100 100 000 Old age Always Never 5 5 Reallocated sector count 0x0033 100 100 001 Pre-fail Always Never 0 7 Seek error rate 0x000a 100 100 001 Old age Always Never 0 8 Seek time performance 0x0004 133 133 020 Old age Offline Never 18 9 Power on hours 0x0012 100 100 000 Old age Always Never 70 (2d, 22h) 10 Spin retry count 0x0012 100 100 001 Old age Always Never 0 12 Power cycle count 0x0032 100 100 000 Old age Always Never 5 22 Unknown attribute 0x0023 100 100 025 Pre-fail Always Never 100 192 Power-off retract count 0x0032 100 100 000 Old age Always Never 6 193 Load cycle count 0x0012 100 100 000 Old age Always Never 6 194 Temperature celsius 0x0002 051 051 000 Old age Always Never 32 (min/max 22/37) 196 Reallocated event count 0x0032 100 100 000 Old age Always Never 0 197 Current pending sector 0x0022 100 100 000 Old age Always Never 0 198 Offline uncorrectable 0x0008 100 100 000 Old age Offline Never 0 199 UDMA CRC error count 0x000a 100 100 000 Old age Always Never 0 Would it detect a drive dropping out as a non-zero event? The message said the drive is not zeroed? Trying to decide if I should return it or give it another post-read.

Ah, well it might not of been when I got the message, I updated all the plugins after that but just noticed that the file activity failed to update and assumed I would keep getting bugged. I don't see it in the fix common problems messages now, so that might of been it.

What is FCP? Far as I know everything is up to date, all the plugins are updated except file activity in the plugin page. I am on beta 30 vs 35 but waiting for some downtime to make that update.

I am running the 6.9 beta and fix common problems is bugging me to update this plugin but while I try to it says my unraid version is too high? Any way to make the update go away if it can't be updated?

I am on qbittorrent 4.3 and radarr 0.2.0.1504. Imports work perfectly. Nzbget on the other hand takes forever to import. Is there a way to update to radarr v3? I am running the binhex container, I already updated to the V3 sonarr and it is much nicer but heard radarr is not ready yet?

Just wanted to say that I did some back to back speed testing via the privoxy and wireguard is indeed working and quite impressively I might say. Only seeing a ~10% overhead using speedtest.net vs no proxy. Going to try a few linux ISO's in qbittorrent now to make sure it sees the speeds it should. I wish there was an nzbget with VPN.

Good to know. Still need to do some back to back testing but does wireguard have a lot higher overhead then OVPN? With OVPN when it was working properly I would generally be able to get around 30-35MB/s on my 400-450mbit internet. In Netdata it would show I was using the full 400-450mbit for internet traffic so the differnce was the ovpn overhead. With wireguard the overhead seems to be much higher, I see ~200-250mbit internet usage (which is better then the 150-200 I saw before) but qbittorrent was only showing around ~10-12MB download (about the same as before). I will do some proper testing later with some torrents with more seeds so I know that seeds are not the bottleneck but the overhead is strange.

I got wireguard working, although I am wondering if it is possible to check that a port is open? I don't seem to be getting as many connections as I did with OVPN for some reason but I would need to do more back to back testing tomorrow to know for sure.

Where? I click the documentation link and then the qbittorrent and this is all that comes up, this is what I found before. https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md