Jump to content

JorgeB

Moderators
  • Posts

    67,582
  • Joined

  • Last visited

  • Days Won

    707

Everything posted by JorgeB

  1. That's likely the WD 3.3v SATA issue, not a reason for the failures, bad/failing molex adapter might be.
  2. Try writing to a non SMR disk, like disk6, SMR disks can have inconstant performance.
  3. There was another user that recently had a similar problem with krusader and mc, in his case it worked normally with Windows, if you a Windows desktop enable disk shares and see if it's the same with Windows, if yes grab and post diags during a copy.
  4. Can't open that file, you can display photos directly on de forum.
  5. Syslog is missing a lot of time, can't see the rebuild, disk21 needs a filesystem check, you can try that before using the old disk, but without seeing what happened with the rebuild probably best to use the old disk as there might be data corruption. You can't do that without doing a new config, if you just want to check the data in the old disk you can do that with UD, make sure the array is stopped first, you can then do the new config and re-sync parity with the old disk.
  6. Stop the docker and VM services, click on the system share and set cache to "prefer", run the mover, when done set it back to cache="only", re-start services. You can do that, but make sure you move data from disk to disk, not disk to share, e.g. move from /mnt/disk3 to /mnt/disk4
  7. Not without the diagnostics, or at least the syslog, got to the console and first try getting the syslog: cp /var/log/syslog /boot/syslog.txt Then type "diagnostics", if the diags finish successfully upload those here, if not upload the syslog.
  8. You either had to have previously created checksums or be using btrfs.
  9. Macvlan call traces are usually the result of having dockers with a custom IP address, more info below. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/
  10. As expected disks look fine, if the emulated disk is mounting and data looks correct you can rebuild on top, but also good idea to try and fix the problem or it will likely happen again, try at least to replace the cables for both disks.
  11. No, but note that it's just part of the fix, other things like the new partition alignment in v6.9 also make a difference.
  12. Actual disk will have a green ball on main page, emulated disk yellow or red. You can use -v for increased verbosity, though it doesn't make much difference.
  13. Disks 1 and 2 dropped offline at the same time (and reconnected with different identifiers), because of that SMART reports are empty, but unlikely to be a disk problem with 2 disks at the same time, most likely power/connection issue, start by checking if the disks share a power cable or splitter, then post new diags after a reboot just to check SMART.
  14. It's mostly because of the recent reflink support with xfs.
  15. It's a known issue, upgrading to v6.9 and re-formatting the SSD will decrease writes by a large factor, as much as 10x.
  16. Yes, any of the recommended controllers, the problem is the onboard SATA controller.
  17. It's again the typical AMD controller problem, if there's no newer BIOS you basically have 3 options: wait for a newer Unraid release with a newer kernel and hope it helps, use an ad-don HBA/controller or try a different board model.
  18. Your system share exists on cache and disk3, libvirt.img is likely on disk3, move everything to cache since disk3 is out of space.
×
×
  • Create New...