Jump to content

georgez

Members
  • Posts

    81
  • Joined

  • Last visited

Posts posted by georgez

  1. Yeah that's what I do. While looking around for possible solution, I read a post which claims some combination of Seagate 8TB and LSI will lead to similar issue, the post introduced a Seagate utility and changed some HDD parameters to workaround the issue. I didn't find such a utility for Toshiba HDD, so I'm trying another way, I've ordered an Adaptec card, will see if it helps.

     

    As for the array shutdown without GUI, I've unmounted all disks manually, and used 'powerdown' to shutdown the server, not sure if it's the right way, but it seemed like working for me.

  2. I like to shutdown all idle disks to save power consumption, it's running fine until some disks started to timeout during power-up, weird things happened since then.

     

    When a disk timed out during power-up, it's usually reset automatically (I read that in dmesg and syslog) and everything's back to normal, but in some cases, the disk was (wrongly) marked as bad then disabled and moved into unassigned disks area, but in fact the disk was just fine, I assured by scanning all the sectors without any error.

     

    Along with the disk being disabled, the emhttpd daemon crashed like this:

    [Sat Oct 22 07:11:48 2022] emhttpd[4490]: segfault at 674 ip 0000000000413f90 sp 00007ffcb9077500 error 4 in emhttpd[403000+1d000]

    Since emhttpd crashed, the green dot in front of the disk was not changed, so I wouldn't even notice the disk was disabled, and I couldn't stop the array, the STOP button didn't work any more.

     

    I guess this (emhttpd crashed) is a bug, I've attached the diagnostic file for examination.

     

    But before it's fixed I'd like to know how to shutdown the array safely when the GUI's not working, please help me.

     

    Thanks for your time

    unraid-diagnostics-20221022-0721.zip

  3. 8 hours ago, JorgeB said:

    Array disk to array disk will never be fast because of parity

    That’s exactly what confuses me, I guess parity calculation is based on P+Q algorithm, since the P+Q algorithms are very fast in my case, why the parity related operations so slow?

  4. 18 minutes ago, JorgeB said:

    Read speed should be the maximum disk read speed at that point, note that disks are much faster in the outer sectors compared to the inner ones.

     

    Write speeds can be much faster, assuming no controller bottlenecks, if you use turbo write, at the expanse of all disks spinning up for writes.

    But why the speed isn't as fast as expected (up to 120MB/s) ? I've tried to transfer very large files from one disk to another, it starts at full speed (maybe because of the cache pool ?), but after a few giga bytes, it slows down to some 80MB/s.

  5. Hi,

     

    I've been using UnRAID for some years, my server contains 24 different sized HDDs, although all my HDDs can read/write sustainably at over 120MB/s, some even over 250MB/s, I have never seen the speed over 90MB/s during daily use, its usually like 50~80MB/s. The only time when the HDDs read/write at full speed is during the parity check. 

     

    While checking the system info, I've noticed the P+Q algorithm is like 19599 MB/s + 35330 MB/s, I assume there'd be no problem with the  CPU power. What is the main cause that slows down the HDDs read/write speed?

  6. On 1/20/2022 at 5:23 PM, monarc said:

    Sorry guys, but I haven't had problems with this on any other of my server. I don't know what I'm doing wrong. Would someone be so nice and could please write a step by step guide for setting up Unraid with ssh keys so login is possible without a simple password.

     

    Thanks in advance. Much appreciated.

     

    I know there are better solutions than mine, but since you ask, I'd like to share my own solution, step by step. If you want a very simple solution (with minor issue), you may skip to the end and read the P.S. section.

     

    The key point of using SSH client without a password is the file '~root/.ssh/authorized_keys', my solution is to create a folder to save it and restore it in the next boot.

     

    1. Create a folder on the UnRAID flash, I use /boot/config/misc/ssh

     

    mkdir -p /boot/config/misc/ssh

     

        I'll put the setup scripts and SSH keys in this folder.
        
    2. Copy the current client keys into the above folder:

     

    cp /root/.ssh/authorized_keys /boot/config/misc/ssh/

        
    3. Also copy the UnRAID's SSH client keys (so I can ssh from UnRAID to other servers without password), my key files have the names id_rsa, id_rsa.pub:

     

    cp /root/.ssh/id* /boot/config/misc/ssh/

        
    4. Create a script to copy these files back into root's .ssh folder in the next boot, I create a file /boot/config/misc/ssh/setup_ssh_client.sh, contents shown below:

     

    #!/bin/bash
    
    SSH_DIR=/root/.ssh
    mkdir -p ${SSH_DIR}
    chmod 750 ${SSH_DIR}
    
    cp /boot/config/misc/ssh/authorized_keys ${SSH_DIR}/
    cp /boot/config/misc/ssh/id_rsa ${SSH_DIR}/
    cp /boot/config/misc/ssh/id_rsa.pub ${SSH_DIR}/
    
    chmod 600 ${SSH_DIR}/authorized_keys
    chmod 600 ${SSH_DIR}/id_rsa

        
        The script simply creates the /root/.ssh (if it doesn't exist), and then copies all the keys I saved earlier into it.
        
    5. Now I need to find a way to let my script run during the next boot, the script '/boot/config/go' is executed at the very end of the bootstrap, so it's an ideal place to start my script, I modified it and added the following lines at the end:

     

    cp /boot/config/misc/ssh/setup_ssh_client.sh /tmp/
    chmod a+x /tmp/setup_ssh_client.sh
    /tmp/setup_ssh_client.sh

     

        Note: since the scripts on /boot can't be executed, I have to copy it to /tmp to run.

     

    5. Done.

     

    To test if the above settings work, erase current /root/.ssh folder (backup it first if you want), and then manually enter the commands in step 5 one by one, your .ssh folder should be restored, otherwise something's wrong in the above procedures.

    From now on, each time /root/.ssh/authorized_keys is changed, I need to redo step 2 to copy it back to the flash, fortunately I don't have to this often becuase the clients don't change frequently.

     

    P.S. AFAIK, there's a very simple way to accomplish 'ssh to UnRAID without password', create a folder on flash, say /boot/config/ssh_keys, then make /root/.ssh a symbolic link to the folder, that's as easy as adding a line in /boot/config/go:

     

    ln -s /boot/config/ssh_keys /root/.ssh

     

    and it's done. But it has a minor issue, when you issue rsync commands from UnRAID, you may get some errors as shown below:

     

    hostfile_replace_entries: link /root/.ssh/known_hosts to /root/.ssh/known_hosts.old: Operation not permitted
    update_known_hosts: hostfile_replace_entries failed for /root/.ssh/known_hosts: Operation not permitted

     

    the rsync will still run though. I just don't like these error messages, so I prefer my way.

  7. 11 minutes ago, JorgeB said:

    Still not the correct way of doing, you must use the md device, or parity will become out of sync, use:

     

    xfs_repair -v /dev/md2

     

     

    Thanks for the clarification. Now the disk is fixed, I'm running a parity check with 'Write the corrections to parity' option checked, I assume it's the right way because their must be some mismatch between the parity and the disk being fix, so the parity needs to be updated.

  8. Hi,

     

    I've just got a weird issue, not sure if it's ok, so I'd like to ask here to see if anyone knows it.

     

    My array has 2 parity disks (one 16TB, one 8TB), recently one of the array disks (disk9, 3TB) was broken, so I bought a new 16TB, assigned it as the parity disk (to replace the old 8TB one), and re-assigned the old 8TB parity disk as disk9. When I started the array, everything seemed ok, the array first copied the parity data from the old 8TB disk to the new 16TB disk, then the array started rebuilding disk9.

     

    But here comes a weird thing: one of my array disks (disk2) was marked as 'Unmountable: Wrong or no file system', but the array was still reading data from it to rebuild the disk9, is this even normal? Will the rebuild be good?

     

    Thanks for your time.

     

    array_screen_snapshot.thumb.jpg.50e2ec315ea59f5087c0af1ecb1bde45.jpg

    unraid-diagnostics-20220706-1744.zip

×
×
  • Create New...