Jump to content

JorgeB

Moderators
  • Posts

    67,416
  • Joined

  • Last visited

  • Days Won

    706

Everything posted by JorgeB

  1. Turbo write doesn't affect cache pool, also good idea to run an iperf test to check lan speed.
  2. Depends if there is parity or not, currently Unraid doesn't touch any array assigned disk, if there's no parity it will just show "unmountable: invalid partition", if the disk is formatted by the user, then yes it will be re-partitioned and formatted, but if a disk is added to an array with parity it will need to be cleared first, but again the user needs to initiate the clearing.
  3. Backup current flash drive, recreate it then restore only super.dat and the key, both on the config folder.
  4. You still need to find what was writing to the disks, did you stop all dockers?
  5. Possible probably, but easiest way is to boot with a DOS flash drive, or install the controller in a Windows desktop.
  6. You could use the parity swap procedure, you could even do both at the same time, though with increased risk if you don't have backups.
  7. Like already mentioned this a general support issue, please start a thread on the general support forum.
  8. No problem, going to mark this solved if you don't mind.
  9. So just checked this and SMART works normally for ATA devices, even if SAS devices are present (SMART tests still don't work for SAS but that's normal), can you check if it still works for the SSDs connected on the onboard SATA ports? If yes you should try updating the both LSI controllers firmware, since they are on a very old one.
  10. Depends on how the appdata share is configured, you can see that on the GUI by clicking on Shares, you can also click on "compute" to confirm where it currently resides.
  11. JorgeB

    Newbie

    Best bet is probably to ask for help in that docker's support thread, you can find it by clicking on the docker icon:
  12. This topic is about the MX500 which has a known issue with an appearing and disappearing pending sector, your issue is different, those are actual SMART warnings, though the CRC error is a connection issue, usually a cable problem, but you can acknowledged both by clicking on the thumbs down icon on the dashboard.
  13. Diags are after rebooting, so we can't see what happened, but the disk looks fine so likely a connection/power issue. That's normal, once a disk gets disabled it needs to be rebuilt.
  14. eth0 is currently a Realtek NIC, Mellanox is eth1, change it to eth0 on Settings -> Network Settings -> Interface Rules (reboot required after). If that doesn't work rename/delete network.cfg and network-rules.cfg (both on boot/config), reboot and reconfigure your LAN, initially you can boot with GUI mode if needed.
  15. There's corruption on the cache filesystem, possibly from all the crashing. Macvlan call traces are usually caused by dockers with a custom IP address, more info here.
  16. No, it went form 4.19 to 5.3 (and then back to 4.19), and v6.6.6 would be an older kernel, IIRC 4.18 something.
  17. Not necessarily, if you do sustained random writes then yes, you'll hit the SMR wall after a few GBs, for sequential writes you can write TBs without slowing down, I did that several times with some of my SMR disks.
  18. Also you can see real-time read/write speeds on the GUI, toggle is on the right upper corner:
  19. Very high CPU/system load for those transfers, try with a different protocol, your just SMB.
  20. Could also be transfer protocol (ftp) related, especially is it's a secure connection, ssh overhead is high, try netcat (nc), if it's a secure LAN.
  21. It shouldn't, but it might be related, let me run some tests on my test server, but likely not before tomorrow.
×
×
  • Create New...