ZipsServer

Members
  • Posts

    128
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

ZipsServer's Achievements

Apprentice

Apprentice (3/14)

0

Reputation

  1. Hi everyone. I have finally accepted the fact that it is time for me to upgrade my original 2013 build to a solution that supports more disks (16+). I am also completely ignorant to the current state of hardware and what is hot. The good thing is that I really only use Unraid for network storage and downloading. Part of me wants to stay with a tower to keep it small and pleasant to look at, but I am probably leaning towards a rack mount chassis that supports 16+ 3.5" drives. I would like recommendations on what to do with the old hardware. Anyone have ideas on how to use it in a new build? Gear List: Asus F1A75-V PRO AMD A8-3870 3.3GHz APU 2x4GB DDR3 LSI SAS Card Flashed to IT Mode + 2 x (SAS -> 4 SATA breakout cables) 2x ICY DOCK 4 in 3 Hotswap Cage Rosewill 4 bay hot swap 2.5" Xigmatek Elysium Tower Chassis Rosewill 550W SMPS ZALMAN 120mm CPU Fan 14 x 3.5" Spinning disks 4 x 2.5" SSD I have an additional tower as well as an HP blade chassis that runs Proxmox with most of my VMs/containers. I use my Unraid machine for downloading, network storage, and backups (of course). I would like at least 16 bays (preferably hot swap). My budget is around $500-$600 for a chassis and components. I have a feeling that may put me in the used market?
  2. I should have mentioned that I already tried another USB port (one integrated on the MB and one plugged in to the MB via an adapter) I also do not have any SATA ports free. I only have 14 slots and they are all filled. Really need to upgrade to a new case/SAS backplane. (That is also why I am running three other drives via USB ports)
  3. I had a new 12TB disk (attached via USB) fail on preclear twice now. I am on Unraid 6.9.0-beta25 with Unassigned Devices 2020.07.26b (Plus 2020.05.22). I also tried on Unraid 6.8.3 before upgrading to the new beta. Here is the disk log which is showing errors that I do not understand. Furthermore the errors seems to happen earlier before the webui notified me that the preclear had failed. I have precleared other USB disk drives multiple times before (> 6 months). However recently (< 1-2 months) I am having problems with other disks attached via USB (causing docker/system hangs and other nasty things) Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] 1465081856 512-byte logical blocks: (750 GB/699 GiB) Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Write Protect is off Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Mode Sense: 47 00 10 08 Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] No Caching mode page found Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Assuming drive cache: write through Jul 29 19:43:31 MasterTower kernel: sdb: sdb1 Jul 29 19:43:31 MasterTower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk Jul 29 19:43:31 MasterTower kernel: BTRFS: device label cache1 devid 2 transid 9272 /dev/sdb1 scanned by udevd (1339) Jul 29 19:44:13 MasterTower emhttpd: WD_Elements_25A3_574D41553430303136323237-0:0 (sdb) 512 1465081856 Jul 29 19:48:38 MasterTower kernel: sd 1:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=0x00 cmd_age=0s Jul 29 19:48:38 MasterTower kernel: sd 1:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 00 00 00 00 00 00 20 00 Jul 29 19:48:38 MasterTower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 Jul 29 19:48:38 MasterTower kernel: blk_update_request: I/O error, dev sdb, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0 Jul 29 19:48:38 MasterTower kernel: Buffer I/O error on dev sdb, logical block 0, async page read Jul 30 17:18:01 MasterTower kernel: sd 1:0:0:0: [sdb] Spinning up disk... Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16). Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] 23437705216 512-byte logical blocks: (12.0 TB/10.9 TiB) Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] 4096-byte physical blocks Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Write Protect is off Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Mode Sense: 47 00 10 08 Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] No Caching mode page found Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Assuming drive cache: write through Jul 30 17:18:18 MasterTower kernel: sdb: sdb1 Jul 30 17:18:18 MasterTower kernel: sd 1:0:0:0: [sdb] Attached SCSI disk
  4. The rcpbind log spamming with NFS shares has been brought up in other posts such as this Unfortunately, there is no way to stop these log messages that I know of currently. I have sent a message to the support email but have not heard back. I really don't understand why more people don't complain about the rcpbind spamming.
  5. A new diag is attached. A preclear using the Unassigned Devices plugin just failed for some reason. mastertower-diagnostics-20200726-1307.zip
  6. Could it possibly be a disk problem? I have three external hard drives running in a btrfs pool through Unassigned Devices. My system just froze again and I was unable to run diagnostics. I also noticed that my dockers using the Unassigned Devices btrfs pool were not working properly and the Unassigned Devices plugin UI was not displaying any info. I hard disconnected the external hard drives and everything returned to normal. Unsure if this was the cause of previous problems. Attached is the diags i just ran. mastertower-diagnostics-20200719-1509.zip EDIT: I want to clarify that I have run these external disks through a preclear without any errors and SMART seemed to be ok. This leads me to believe there may be a problem with using a manually created btrfs pool (no raid) with external disks. Any thoughts here?
  7. This problem has happened 5+ times now. Every time I am unable to get diagnostics. I am able to get the syslog, but it really only shows rcpbind messages from my NFS shares.
  8. I ran a MEMTEST for 18 hours with no errors. Still unsure what is causing these issues.
  9. Hiya, Unfortunately I have had some reoccurring "out of memory" problems with my server over the past few weeks. This time I was actually able to get some diagnostics output which I have attached. I had to run `diagnostics` from the command line which also gave errors. Starting diagnostics collection... Warning: file_put_contents(): Only 0 of 5 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 80 Warning: file_put_contents(): Only 0 of 15 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 12 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 665 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 13 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 599 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 1034 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 15 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 11 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 15 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 14 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 11 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 85 Warning: file_put_contents(): Only 0 of 82 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 101 Warning: file_put_contents(): Only 0 of 2 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 120 Warning: file_put_contents(): Only 0 of 34 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 122 echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device echo: write error: No space left on device Warning: file_put_contents(): Only 0 of 29 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 160 Warning: file_put_contents(): Only 0 of 25 bytes written, possibly out of free disk space in /usr/local/emhttp/plugins/dynamix/scripts/diagnostics on line 160 EDIT: Currently running a MEMTEST. First pass completed without an error. tower-diagnostics-20200710-1912.zip
  10. Again, Posting here because of more kernel OOM erros. This time I was unable to stop containers and the webui went down (nginx 500). Still unable to run diagnostics.
  11. My server just crashed for the second time due to memory errors. I am pointing my finger at this issue filling up the log and causing errors that I don't understand I was not able to download diagnostics (I am assuming some process was killed that it needed) but I was able to download the syslog. Happy to share it privately. Jun 18 21:40:37 MasterTower kernel: Timer-Scheduler invoked oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), nodemask=(null), order=0, oom_score_adj=0 Jun 18 21:40:37 MasterTower kernel: Timer-Scheduler cpuset=07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0 mems_allowed=0 Jun 18 21:40:37 MasterTower kernel: CPU: 2 PID: 16549 Comm: Timer-Scheduler Tainted: G W 4.19.107-Unraid #1 Jun 18 21:40:37 MasterTower kernel: Hardware name: System manufacturer System Product Name/F1A75-V PRO, BIOS 2507 01/29/2015 Jun 18 21:40:37 MasterTower kernel: Call Trace: Jun 18 21:40:37 MasterTower kernel: dump_stack+0x67/0x83 Jun 18 21:40:37 MasterTower kernel: dump_header+0x66/0x289 Jun 18 21:40:37 MasterTower kernel: oom_kill_process+0x9d/0x220 Jun 18 21:40:37 MasterTower kernel: out_of_memory+0x3b7/0x3ea Jun 18 21:40:37 MasterTower kernel: mem_cgroup_out_of_memory+0x94/0xc8 Jun 18 21:40:37 MasterTower kernel: try_charge+0x52a/0x682 Jun 18 21:40:37 MasterTower kernel: ? __alloc_pages_nodemask+0x150/0xae1 Jun 18 21:40:37 MasterTower kernel: mem_cgroup_try_charge+0x115/0x158 Jun 18 21:40:37 MasterTower kernel: __add_to_page_cache_locked+0x73/0x184 Jun 18 21:40:37 MasterTower kernel: add_to_page_cache_lru+0x47/0xd5 Jun 18 21:40:37 MasterTower kernel: filemap_fault+0x238/0x47c Jun 18 21:40:37 MasterTower kernel: __do_fault+0x4d/0x88 Jun 18 21:40:37 MasterTower kernel: __handle_mm_fault+0xdb5/0x11b7 Jun 18 21:40:37 MasterTower kernel: handle_mm_fault+0x189/0x1e3 Jun 18 21:40:37 MasterTower kernel: __do_page_fault+0x267/0x3ff Jun 18 21:40:37 MasterTower kernel: ? page_fault+0x8/0x30 Jun 18 21:40:37 MasterTower kernel: page_fault+0x1e/0x30 Jun 18 21:40:37 MasterTower kernel: RIP: 0033:0x154aa86131c0 Jun 18 21:40:37 MasterTower kernel: Code: Bad RIP value. Jun 18 21:40:37 MasterTower kernel: RSP: 002b:0000154a655fab60 EFLAGS: 00010202 Jun 18 21:40:37 MasterTower kernel: RAX: ffffffffffffff92 RBX: 0000560b17d40fa0 RCX: 0000154aa8612ed9 Jun 18 21:40:37 MasterTower kernel: RDX: 0000000000000000 RSI: 0000000000000080 RDI: 0000560b17d40fc8 Jun 18 21:40:37 MasterTower kernel: RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 Jun 18 21:40:37 MasterTower kernel: R10: 0000154a655fabc0 R11: 0000000000000246 R12: 0000560b17d40fe0 Jun 18 21:40:37 MasterTower kernel: R13: 0000560b17d40fc8 R14: 0000154a655fac60 R15: 0000560b17d40fc4 Jun 18 21:40:37 MasterTower kernel: Task in /docker/07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0 killed as a result of limit of /docker/07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0 Jun 18 21:40:37 MasterTower kernel: memory: usage 512000kB, limit 512000kB, failcnt 16659 Jun 18 21:40:37 MasterTower kernel: memory+swap: usage 512000kB, limit 1024000kB, failcnt 0 Jun 18 21:40:37 MasterTower kernel: kmem: usage 6576kB, limit 9007199254740988kB, failcnt 0 Jun 18 21:40:37 MasterTower kernel: Memory cgroup stats for /docker/07777a87eab516b7cdc4926c695d190776b64ffb7bd64dd0323a8e74d75ec5a0: cache:4292KB rss:500828KB rss_huge:4096KB shmem:0KB mapped_file:396KB dirty:132KB writeback:132KB swap:0KB inactive_anon:4KB active_anon:501112KB inactive_file:2168KB active_file:1884KB unevictable:0KB Jun 18 21:40:37 MasterTower kernel: Tasks state (memory values in pages): Jun 18 21:40:37 MasterTower kernel: [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name Jun 18 21:40:37 MasterTower kernel: [ 3423] 0 3423 50 1 28672 0 0 s6-svscan Jun 18 21:40:37 MasterTower kernel: [ 3489] 0 3489 50 1 28672 0 0 s6-supervise Jun 18 21:40:37 MasterTower kernel: [ 3797] 0 3797 50 1 28672 0 0 s6-supervise Jun 18 21:40:37 MasterTower kernel: [ 3800] 99 3800 638611 125200 2191360 0 0 mono Jun 18 21:40:37 MasterTower kernel: Memory cgroup out of memory: Kill process 3800 (mono) score 982 or sacrifice child Jun 18 21:40:37 MasterTower kernel: Killed process 3800 (mono) total-vm:2554444kB, anon-rss:500796kB, file-rss:0kB, shmem-rss:4kB Jun 18 21:40:37 MasterTower kernel: oom_reaper: reaped process 3800 (mono), now anon-rss:0kB, file-rss:0kB, shmem-rss:4kB
  12. Hello, My file transfers to the array and within the array have been running suspiciously slow recently (20MB/s vs 80-90MB/s). There has also been increased CPU usage. I checked my logs and it appears there is a kernel memory warning, but I cannot discern any info beyond that. Diagnostics attached. mastertower-diagnostics-20200411-2059.zip
  13. Here is an example from my system. I had just rebooted so the syslog shouldn't be terribly long, but it should show the ridiculous number of rcpbind log messages. mastertower-diagnostics-20200411-1743.zip
  14. I am having the same problem with PIA. None of the endpoints are working for me. Had to set STRICT_PORT_FORWARD='no' to get PIA to work.
  15. Is there any reason Lidarr might be gobbling up memory and causing my server to freeze up? Twice now Lidarr has been associated with a process called `mono` using 3+GB (>30%) of MEM. Both times this caused my server to come to a standstill.