georgez

Members
  • Posts

    81
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

georgez's Achievements

Rookie

Rookie (2/14)

7

Reputation

  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. Thank you for this info! Now I know it's not my hardware issue (I've replace all my RAID cards and cables without luck). My question is: is there any way to tune up the Toshiba HDDs? My Toshiba 8TB disks also have this issue.
  3. 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
  4. Thank you! It’s very informative. Sent from my iPhone using Tapatalk
  5. 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?
  6. 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.
  7. 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?
  8. 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.
  9. Now I see how those device names work. Unfortunately I already did the xfs_repair on /dev/sdn1, hence have to do a parity-check. Thank you all for your help! You guys are awesome!
  10. 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.
  11. Ah I get your point! I need to scan 1st partition (/dev/sdn1) instead of the whole disk (/dev/sdn). I restarted the xfs_repair, this time it ends quickly with some kind of issue (shown in screenshot), I guess the next step is to re-run the xfs_repair to fix that?
  12. What do you mean that's not the correct device, the /dev/sdn is the disk that's not mountable.
  13. Ok, the rebuild has been complete, I've restarted the array in maintenance mode, use xfs_repair to scan the disk2 (sdn), xfs_repair is now looking hard for the superblock, will report when it's done.
  14. 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. unraid-diagnostics-20220706-1744.zip
  15. Array rebuilt successfully, thank you for your help! Sent from my iPhone using Tapatalk