Jump to content

JorgeB

Moderators
 View Profile  See their activity

  • Posts

    67,565

  • Joined

  • Last visited

  • Days Won

    707

 Content Type 

Everything posted by JorgeB

  1. JorgeB
    Yes, and if it asks for it use -L.
  2. JorgeB
    Yes, you manually need to select the fs to use the GUI ( or run xfs_repair in the console).
  3. JorgeB
    Try without /z
  4. JorgeB
    I've used robocopy before with no issues, what is the command line you're using?
  5. JorgeB
    Check filesystem on disk6: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui
  6. JorgeB
    -Tools -> New Config -> Retain current configuration: All -> Apply -Unassign all the SAS disks -Assign the new SATA disks -Start array to begin parity sync (new disks will need to be formatted) -Once the sync finishes try to copy the data from the old disks.
  7. JorgeB
    That means parity wasn't 100% valid, please post diags.
  8. JorgeB
    There's no SMART for one them, the other two don't look very good, and it's not cable related. You can always do a new config with the new SATA drives, re-sync parity, then try to copy the data from the SAS drives using UD.
  9. JorgeB
    That is odd.
  10. JorgeB
    Could be some plugin, try booting in safe mode.
  11. JorgeB
    This starts before the disks are mounted: Dec 23 14:24:08 Hal-9000 emhttpd: error: get_filesystem_status, 6618: Operation not supported (95): getxattr: /mnt/user/# Backups - Rob Does it ring any bells? If not try booting in safe mode.
  12. JorgeB
    Please post the diagnostics: Tools -> Diagnostics (before rebooting).
  13. JorgeB
    There are only two ways of shrinking an array, both are described here.
  14. JorgeB
    That should do it.
  15. JorgeB
    Don't see any issues in the snippets posted, or in the syslog.
  16. JorgeB
    Should work.
  17. JorgeB
    There are some recovery options here.
  18. JorgeB
    Looks like a connection problem, replace cables, power and SATA.
  19. JorgeB
    Try writing to disk1 exclusively, since it's the only non SMR data drive.
  20. JorgeB
    Looks like it did, you can confirm by running an extended SMART test.
  21. JorgeB
    Turbo write has nothing to do with disk size, it parity check is failing and the server locking up there are other issues.
  22. JorgeB
    It is but it's normal with current xfs.
  23. JorgeB
    Yes, that's a strong possibility, also note that disks 2 and 3 are SMR, and you can be hitting the SMR wall.
  24. JorgeB
    Stop/start array should fix it, if not reboot.
  25. JorgeB
    The only possibility now is using a file recovery util, like UFS explorer.
×
×
  • Create New...