Jump to content

TheMantis

Members
  • Content Count

    39
  • Joined

  • Last visited

Community Reputation

0 Neutral

About TheMantis

Converted

  • Gender
    Undisclosed
  1. The new dashboard looks the duck nuts. Bravo.
  2. Great, I'd imagine that with the constant addition of amazing features, keeping the documentation up to date would be quite an effort.
  3. I understand the links to the wiki are there as you mention. However, for the uninitiated I wouldn't expect to have to dig through often out of date or incomplete documentation just to find out the core features of a product. From my perspective, documentation tells me how to use a product, the product website should sell me the features first. While the old site was less pretty it was quite comprehensive in explaining in relatively broad detail exactly what the product did.
  4. Is it just me or has the UNRAID website been dumbed down to the point where virtually no detailed information is given about the product? Sure the website looks great but if I was wanting to get some details of how it works I'd be leaving disappointed.
  5. I've actually got my wires crossed a bit here: my fault is not the one you linked. The issue that I have is that nginx slowly consumes all available memory over a week or so.
  6. I've got the same problem too. It seems to happen when certain Dockers are running but I'm still trying to work out which ones. I have virtually no idea how to do anything in linux so only the obvious stands out to me. It's only been happening since 6.5.0 from what I can see. I have two seperate servers running 6.5.0 and only one has the memory leakage problem. As of now I have not tried any of the 6.5.1 RC series.
  7. It's a bug. Should be fixed in the next release apparently.
  8. I'm trying to add a new(ish) disk to the array but after I've assigned it to an empty slot (disk 2 slot) and started the array it just loops and goes straight back to "click start to bring array online and pre-clear disk, etc" without the array actually starting. The disk hasn't been used on unRAID before and is freshly cleared in OS X. I recall an issue like this quite some time ago (perhaps V5 era). Diagnostics attached. Cheers tower-diagnostics-20160716-1035.zip
  9. I have a disk that has been ejected from the array and is now showing as an unassigned, unformatted disk. After starting the array in maintenance mode I've run an Fsck check with the following outcome: Will read-only check consistency of the filesystem on /dev/sdq1 Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes ########### reiserfsck --check started at Mon May 23 12:15:51 2016 ########### Replaying journal: Done. Reiserfs journal '/dev/sdq1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 740460 Internal nodes 4405 Directories 169 Other files 3080 Data block pointers 748915833 (514457 of them are zero) Safe links 0 Following that I ran fdisk -lu /dev/sdq and got the following output: WARNING: GPT (GUID Partition Table) detected on '/dev/sdq'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdq: 4000.8 GB, 4000787030016 bytes 256 heads, 63 sectors/track, 484501 cylinders, total 7814037168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdq1 1 4294967295 2147483647+ ee GPT Partition 1 does not start on physical sector boundary. From my extremely limited knowledge it looks like the data on this disk is good but something has happened to the formatting causing unRAID to think the disk is unformatted. Any help is appreciated. Diagnostic file is attached tower-diagnostics-20160523-1609.zip
  10. In my experience unRAID performance on OS X is one of the few weak links with the product. I don't know where the problem is but I frequently experience dropped shares (only a Mac reboot will reconnect) and long, long directory loading times. Neither of these things occur when using Windows machines. Using AFP changed nothing nor does the cache dir plugin improve things. In the seven years I've been using unRAID it's always been this way with no real noticeable changes. I just live with it but it can get frustrating at times.
  11. Plex runs daily library scans and scheduled tasks for backup and optimization purposes, these can interfere with your parity check. The schedule I have set for those tasks should exclude them from being a significant factor. During the parity check I was monitoring the storage throughput window on System Stats on it was rare to see reads go above 800MB/sec. Normally I would see reads well above 1GB/sec and generally around 1.25 - 1.5GB/sec. CPU usage was reasonable at around 20%. Ultimately it's not a problem, just unusual.
  12. Parity checks are glacially slow for me too. My 68TB server just took 30 hours @ 55.4MB/sec. Normally it would take around 19-20 hours @ about 80MB/sec. There was no activity on the server during the parity check. CPU is an X3470, HBA's are 2 x SASLP-MV8 and 1 x SAS2LP-MV8, motherboard a Supermicro - X8SIL. The only Docker I run is Plex, no VM's (unfortunately enabling VM features causes unRAID to randomly crash).
  13. I've recently changed the IP address on my server and need to change the settings in Margarita to reflect this. I've tried to enter the new IP address on the "Edit Server" page but the application will not accept the new address once the page is closed. All that happens is an "Error with connection" fault and the new IP address has been overwritten by the old one. I'm also using the iOS version of Margarita and have the same issue on iPad but iPhone works correctly. Any suggestions on what is going wrong?