May 4, 201610 yr Hey Folks... I have been doing some work on the server the last few days. I was on the last step until I get some new disks and I had some errors. Wondering if this is life threatening or if I can just ignore it - Ignorance is bliss! Here is what lead me to today.. Array consists of a bunch or 2tb drives. One of the data drives has Relocate sector count of 2. Its been like that for sometime so I was not to worried about it but was gearing towards a replacement. A week or so ago another 2tb data drive failed. I was able to swap in a replacement and rebuilt without a problem. A couple days ago I added a 4TB drive to the array - precleared it then swapped it in as my parity. I left the orginal 2tb parity drive in but unassigned. Yesterday I removed the drive with the relocate errors out of the array and put the old parity drive in its place. During this rebuild is when I got 146 errors. Any thoughts on the matter? Its all just media that can be replaced and backups from desktops that are further backed up to offsite locations. It would suck to loose the media but not the end of the world. Hence my lack of worry. Before I swap any more drives I though I should try and figure this out though.. Attaching logs for reference sake... Many thanks in advance!!!! Mike tower-diagnostics-20160504-0653-anon.zip
May 4, 201610 yr Community Expert Do you mean sync errors? The only errors I see are sync errors during the parity check after upgrading to 4TB, there are no errors during disk4 rebuild, although those sync errors just two days after the parity sync are somewhat troubling, do another parity check, if there are sync errors again there's some issue.
May 4, 201610 yr Author I was hesitant to start a parity check. I was thinking maybe I could revert back to the old disk or something. Oh well.. Parity check started - I am fairly new to Unraid.... thanks! Mike Do you mean sync errors? The only errors I see are sync errors during the parity check after upgrading to 4TB, there are no errors during disk4 rebuild, although those sync errors just two days after the parity sync are somewhat troubling, do another parity check, if there are sync errors again there's some issue.
May 4, 201610 yr Author Ok... I newb question... Where are you looking to see the errors? I am reading through the log files and not seeing much that helps me. I am interested in learning to be a little more self sufficient. I have email alerts setup and here is the message I got last night: Event: unRAID Data rebuild: Subject: Notice [TOWER] - Data rebuild: finished (146 errors) Description: Duration: unavailable (no parity-check entries logged) Importance: warning Cheers, Mike Do you mean sync errors? The only errors I see are sync errors during the parity check after upgrading to 4TB, there are no errors during disk4 rebuild, although those sync errors just two days after the parity sync are somewhat troubling, do another parity check, if there are sync errors again there's some issue.
May 4, 201610 yr Community Expert During the parity sync several sync errors were corrected: May 1 03:30:01 tower kernel: md: recovery thread woken up ... May 1 03:30:01 tower kernel: md: recovery thread checking parity... May 1 03:30:01 tower kernel: md: using 1536k window, over a total of 3907018532 blocks. May 1 03:30:31 tower kernel: md: correcting parity, sector=1915648 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915656 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915664 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915672 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915680 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915688 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915696 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915704 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915712 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915720 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915728 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915736 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915744 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915752 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915760 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915768 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915776 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915784 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915792 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915800 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915808 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915816 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915824 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915832 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915840 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915848 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915856 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915864 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915872 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915880 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915888 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915896 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915904 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915912 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915920 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915928 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915936 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915944 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915952 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915960 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915968 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915976 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915984 May 1 03:30:31 tower kernel: md: correcting parity, sector=1915992 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916000 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916008 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916016 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916024 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916032 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916040 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916048 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916056 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916064 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916072 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916080 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916088 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916096 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916104 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916112 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916120 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916128 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916136 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916144 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916152 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916160 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916168 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916176 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916184 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916192 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916200 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916208 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916216 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916224 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916232 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916240 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916248 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916256 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916264 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916272 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916280 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916288 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916296 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916304 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916312 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916320 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916328 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916336 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916344 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916352 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916360 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916368 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916376 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916384 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916392 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916400 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916408 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916416 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916424 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916432 May 1 03:30:31 tower kernel: md: correcting parity, sector=1916440 May 1 03:30:31 tower kernel: md: correcting parity, stopped logging ... May 1 15:21:28 tower kernel: md: sync done. time=42687sec May 1 15:21:29 tower kernel: md: recovery thread sync completion status: 0 Disk read errors appear like this example from another server, in this case disk13 is the problem: May 3 23:48:03 tower kernel: md: disk13 read error, sector=3273577816 May 3 23:48:03 tower kernel: md: disk13 read error, sector=3273577824 May 3 23:48:03 tower kernel: md: disk13 read error, sector=3273577832 May 3 23:48:03 tower kernel: md: disk13 read error, sector=3273577840 I don't see any disk errors during disk4 rebuild: May 3 15:45:55 tower kernel: md: recovery thread rebuilding disk4 ... May 3 15:45:55 tower kernel: md: using 1536k window, over a total of 1953514552 blocks. May 3 15:45:57 tower emhttp: shcmd (311): :>/etc/samba/smb-shares.conf May 3 15:45:57 tower avahi-daemon[27452]: Files changed, reloading. May 3 15:45:57 tower emhttp: Restart SMB... May 3 15:45:57 tower emhttp: shcmd (312): killall -HUP smbd May 3 15:45:57 tower emhttp: shcmd (313): cp /etc/avahi/services/smb.service- /etc/avahi/services/smb.service May 3 15:45:57 tower avahi-daemon[27452]: Files changed, reloading. May 3 15:45:57 tower avahi-daemon[27452]: Service group file /services/smb.service changed, reloading. May 3 15:45:57 tower emhttp: shcmd (314): pidof rpc.mountd &> /dev/null May 3 15:45:57 tower emhttp: shcmd (315): /etc/rc.d/rc.atalk status May 3 15:45:57 tower emhttp: Starting Docker... May 3 15:45:57 tower kernel: BTRFS info (device loop0): disk space caching is enabled May 3 15:45:57 tower kernel: BTRFS: has skinny extents May 3 15:45:57 tower logger: Resize '/var/lib/docker' of 'max' May 3 15:45:57 tower logger: starting docker ... May 3 15:45:57 tower kernel: BTRFS: new size for /dev/loop0 is 107374182400 May 3 15:45:58 tower avahi-daemon[27452]: Service "tower" (/services/smb.service) successfully established. May 3 15:45:59 tower kernel: device veth6d2a60a entered promiscuous mode May 3 15:45:59 tower kernel: docker0: port 1(veth6d2a60a) entered forwarding state May 3 15:45:59 tower kernel: docker0: port 1(veth6d2a60a) entered forwarding state May 3 15:45:59 tower avahi-daemon[27452]: Withdrawing workstation service for vetha181d9f. May 3 15:45:59 tower kernel: docker0: port 1(veth6d2a60a) entered disabled state May 3 15:45:59 tower kernel: eth0: renamed from vetha181d9f May 3 15:45:59 tower kernel: docker0: port 1(veth6d2a60a) entered forwarding state May 3 15:45:59 tower kernel: docker0: port 1(veth6d2a60a) entered forwarding state May 3 15:45:59 tower logger: SABnzbd: started succesfully! May 3 15:45:59 tower logger: Dropbox: started succesfully! May 3 15:45:59 tower kernel: device veth95ce063 entered promiscuous mode May 3 15:45:59 tower kernel: docker0: port 2(veth95ce063) entered forwarding state May 3 15:45:59 tower kernel: docker0: port 2(veth95ce063) entered forwarding state May 3 15:45:59 tower avahi-daemon[27452]: Withdrawing workstation service for veth5bbb007. May 3 15:45:59 tower kernel: docker0: port 2(veth95ce063) entered disabled state May 3 15:45:59 tower kernel: eth0: renamed from veth5bbb007 May 3 15:45:59 tower kernel: docker0: port 2(veth95ce063) entered forwarding state May 3 15:45:59 tower kernel: docker0: port 2(veth95ce063) entered forwarding state May 3 15:45:59 tower logger: Sonarr: started succesfully! May 3 15:45:59 tower logger: plex: started succesfully! May 3 15:45:59 tower kernel: device vetheb4187a entered promiscuous mode May 3 15:45:59 tower kernel: docker0: port 3(vetheb4187a) entered forwarding state May 3 15:45:59 tower kernel: docker0: port 3(vetheb4187a) entered forwarding state May 3 15:45:59 tower avahi-daemon[27452]: Withdrawing workstation service for veth59d9399. May 3 15:45:59 tower kernel: docker0: port 3(vetheb4187a) entered disabled state May 3 15:45:59 tower kernel: eth0: renamed from veth59d9399 May 3 15:45:59 tower kernel: docker0: port 3(vetheb4187a) entered forwarding state May 3 15:45:59 tower kernel: docker0: port 3(vetheb4187a) entered forwarding state May 3 15:45:59 tower logger: CouchPotato: started succesfully! May 3 15:46:01 tower ntpd[1641]: Listen normally on 6 docker0 172.17.42.1:123 May 3 15:46:01 tower ntpd[1641]: new interface(s) found: waking up resolver May 3 15:46:06 tower logger: Updating templates... Updating info... Done. May 3 15:46:06 tower kernel: EXT4-fs (loop1): mounted filesystem with ordered data mode. Opts: (null) May 3 15:46:06 tower emhttp: Starting libvirt... May 3 15:46:06 tower logger: Starting libvirtd... May 3 15:46:06 tower kernel: kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround May 3 15:46:06 tower dnsmasq[3748]: read /etc/hosts - 1 addresses May 3 15:46:06 tower dnsmasq[3748]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 addresses May 3 15:46:06 tower dnsmasq-dhcp[3748]: read /var/lib/libvirt/dnsmasq/default.hostsfile May 3 15:46:06 tower sSMTP[28539]: Creating SSL connection to host May 3 15:46:06 tower sSMTP[28539]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 May 3 15:46:06 tower kernel: device vnet0 entered promiscuous mode May 3 15:46:06 tower kernel: br0: port 2(vnet0) entered listening state May 3 15:46:06 tower kernel: br0: port 2(vnet0) entered listening state May 3 15:46:07 tower kernel: device vnet1 entered promiscuous mode May 3 15:46:07 tower kernel: br0: port 3(vnet1) entered listening state May 3 15:46:07 tower kernel: br0: port 3(vnet1) entered listening state May 3 15:46:07 tower kernel: kvm: zapping shadow pages for mmio generation wraparound May 3 15:46:08 tower kernel: kvm: zapping shadow pages for mmio generation wraparound May 3 15:46:08 tower sSMTP[28539]: Sent mail for [email protected] (221 2.0.0 closing connection w188sm18653qhb.9 - gsmtp) uid=0 username=xxx outbytes=760 May 3 15:46:09 tower sSMTP[28737]: Creating SSL connection to host May 3 15:46:09 tower sSMTP[28737]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 May 3 15:46:11 tower sSMTP[28737]: Sent mail for [email protected] (221 2.0.0 closing connection i83sm12415qkh.19 - gsmtp) uid=0 username=xxx outbytes=810 May 3 15:46:11 tower sSMTP[28865]: Creating SSL connection to host May 3 15:46:11 tower sSMTP[28865]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 May 3 15:46:13 tower sSMTP[28865]: Sent mail for [email protected] (221 2.0.0 closing connection y206sm22220qhc.0 - gsmtp) uid=0 username=xxx outbytes=773 May 3 15:46:14 tower sSMTP[28930]: Creating SSL connection to host May 3 15:46:14 tower sSMTP[28930]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 May 3 15:46:14 tower kernel: docker0: port 1(veth6d2a60a) entered forwarding state May 3 15:46:14 tower kernel: docker0: port 2(veth95ce063) entered forwarding state May 3 15:46:14 tower kernel: docker0: port 3(vetheb4187a) entered forwarding state May 3 15:46:16 tower sSMTP[28930]: Sent mail for [email protected] (221 2.0.0 closing connection z77sm7386qkb.29 - gsmtp) uid=0 username=xxx outbytes=720 May 3 15:46:21 tower kernel: br0: port 2(vnet0) entered learning state May 3 15:46:22 tower kernel: br0: port 3(vnet1) entered learning state May 3 15:46:36 tower kernel: br0: topology change detected, propagating May 3 15:46:36 tower kernel: br0: port 2(vnet0) entered forwarding state May 3 15:46:37 tower kernel: br0: topology change detected, propagating May 3 15:46:37 tower kernel: br0: port 3(vnet1) entered forwarding state May 3 15:48:39 tower kernel: unregister_netdevice: waiting for lo to become free. Usage count = 1 May 3 17:59:55 tower dhcpcd[1594]: br0: renewing lease of 192.168.1.3 May 3 17:59:55 tower dhcpcd[1594]: br0: rebind in 32400 seconds, expire in 43200 seconds May 3 17:59:55 tower dhcpcd[1594]: br0: sending REQUEST (xid 0x57bcc30a), next in 3.3 seconds May 3 17:59:55 tower dhcpcd[1594]: br0: acknowledged 192.168.1.3 from 192.168.1.1 May 3 17:59:55 tower dhcpcd[1594]: br0: leased 192.168.1.3 for 86400 seconds May 3 17:59:55 tower dhcpcd[1594]: br0: renew in 43200 seconds, rebind in 75600 seconds May 3 17:59:55 tower dhcpcd[1594]: br0: writing lease `/var/lib/dhcpcd/dhcpcd-br0.lease' May 3 17:59:55 tower dhcpcd[1594]: br0: IP address 192.168.1.3/24 already exists May 3 17:59:55 tower dhcpcd[1594]: br0: executing `/lib/dhcpcd/dhcpcd-run-hooks' RENEW May 3 17:59:55 tower dhcpcd[1594]: br0: ARP announcing 192.168.1.3 (1 of 2), next in 2.0 seconds May 3 17:59:57 tower dhcpcd[1594]: br0: ARP announcing 192.168.1.3 (2 of 2) May 3 21:50:16 tower kernel: md: sync done. time=21861sec May 3 21:50:16 tower kernel: md: recovery thread sync completion status: 0
May 4, 201610 yr Author Awesome Johnnie. I appreciate you taking the time breaking this out for me... Gives me some legs to understand what is going on. Any thoughts as to why the email saying I got the errors after the rebuild? During the parity sync several sync errors were corrected: ..........
May 4, 201610 yr Community Expert That notification is the strange part, maybe it's related to the previous sync errors, do you now how many sync errors were corrected?
May 4, 201610 yr Author To be honest no.. I just setup the alerts a couple days ago as well. I did not notice any errors during the parity check with the new 4TB. Only the new error message with the rebuild. I will wait it out and see how the parity check goes. Again its not the end of the world. I just don't like mysteries ;-) Estimated speed: 105.5 MB/sec Estimated finish: 8 hours, 39 minutes Not to much longer! Again many many thanks for the assistance. That notification is the strange part, maybe it's related to the previous sync errors, do you now how many sync errors were corrected?
May 4, 201610 yr Community Expert Somebody tell me if I am wrong but I seem to recall that, many times, parity sync errors occur when the array is shutdown improperly which results in a write buffer not being 'flushed' to the parity drive before the actual power shutdown.
May 4, 201610 yr Author That might explain it Frank. I did have a improper shutdown at one point during all this. Was trying to take the array offline and it hung. No response anywhere so it was power cycled and parity checked... Time wise it is probably related as well. Somebody tell me if I am wrong but I seem to recall that, many times, parity sync errors occur when the array is shutdown improperly which results in a write buffer not being 'flushed' to the parity drive before the actual power shutdown.
May 4, 201610 yr Community Expert Not in this case because the server didn't reboot between the parity sync and the parity check: Apr 29 06:47:31 tower kernel: md: recovery thread woken up ... Apr 29 06:47:31 tower kernel: md: recovery thread syncing parity disk ... ... Apr 29 18:48:05 tower kernel: md: sync done. time=43234sec Apr 29 18:48:06 tower kernel: md: recovery thread sync completion status: 0 May 1 03:30:01 tower kernel: md: recovery thread woken up ... May 1 03:30:01 tower kernel: md: recovery thread checking parity... ... May 1 15:21:28 tower kernel: md: sync done. time=42687sec May 1 15:21:29 tower kernel: md: recovery thread sync completion status: 0
May 5, 201610 yr Author Will move on and hope not to many things are messed up :-) Based on the logs and the sector count any way to figure out what files occupy those sectors? unRAID Parity check: 04-05-2016 20:39 Notice [TOWER] - Parity check finished (0 errors) Duration: 13 hours, 7 minutes, 1 second. Average speed: 84.7 MB/s
May 5, 201610 yr Community Expert Use the GUI and look at all of the SMART reports for all of the drives. You want to particularity be looking at Attributes # 5, 196, 197, 198 and 199. If any are more than zero (with the possible exception of #5), that disk is suspect. If you have any disks with #199 errors, replace the SATA cable and make sure that cable is securing connected to the drive. If it is a locking cable be sure to replace it. (WD-- and possibly some other manufacturers-- has redesigned the connector on their drives so that most locking cables no longer provide a reliable electrical connection!)
May 5, 201610 yr Author Thanks Frank... Based on your write up I have one questionable disk. I will roll the dice for a little bit until I can find some 4TB's on sale. I asked earlier but will throw it out there again. Based on the logs and the sector id? Logs are: May 1 03:30:31 tower kernel: md: correcting parity, sector=1915648 Any way to translate that to a file? Many thanks to all! Mike
May 5, 201610 yr Community Expert I asked earlier but will throw it out there again. Based on the logs and the sector id? Logs are: May 1 03:30:31 tower kernel: md: correcting parity, sector=1915648 Any way to translate that to a file? Not possible, not even which disk it is.
May 5, 201610 yr Author Thats to bad. I am surprised they would even report it if its of no value. I would have thought it was a virtualized sector ID based on the amalgamation of all the drives. Oh well. Again not the end of the world. I lose a little trust though when we cannot id the cause and effect of this type of issues. Many many thanks all! Mike Not possible, not even which disk it is.
May 5, 201610 yr Community Expert Thats to bad. I am surprised they would even report it if its of no value. I would have thought it was a virtualized sector ID based on the amalgamation of all the drives. Oh well. Again not the end of the world. I lose a little trust though when we cannot id the cause and effect of this type of issues. Many many thanks all! Mike Dynamix File Integrity plugin Good complement for unRAID, especially for this type of situations.
Archived
This topic is now archived and is closed to further replies.