Jump to content

JorgeB

Moderators
 View Profile  See their activity

  • Posts

    67,386

  • Joined

  • Last visited

  • Days Won

    705

 Content Type 

Everything posted by JorgeB

  1. JorgeB
    Just for reference that would also be OK, parity is updated when a disk is formatted.
  2. JorgeB
    It should work after a reboot, you'll need to format one more time.
  3. JorgeB
    This is a known btrfs issue when using different size devices, usable size will be 240GB. Also because of this bug your cache in not redundant, there are instructions to fix it in that report.
  4. JorgeB
    Dec 11 00:18:05 Tower unassigned.devices: Error: shell_exec(/sbin/mount -t btrfs -o auto,async,noatime,nodiratime '/dev/sdo1' '/mnt/disks/downloads' 2>&1) took longer than 20s! Dec 11 00:18:05 Tower unassigned.devices: Mount of '/dev/sdo1' failed. Error message: command timed out It looks like a UD problem, mount is timing out, btrfs filesystem can take a few seconds to mount, certainly more than 20 if there are many files, you should post on the UD support threads, include diags.
  5. JorgeB
    reiserfsck --check /dev/sdX1 Replace X with correct letter, keep the 1 in the end.
  6. JorgeB
    Yes, if all goes well then you just need to do a standard replacement.
  7. JorgeB
    It would be my recommendation. In this case you wouldn't be replacing any drives, you'd be using all current data disks (including the old disk4) as they are and re-sync parity, to do that you need to: -Tools -> New Config -> Retain current configuration: All -> Apply -re-assign old disk4 if needed -start array to begin pariyy sync, all data should be available immediately, if any disk is unmountable post new diags.
  8. JorgeB
    Usually yes, some time these can be false positives, you'll know after the parity check finishes, if there are any errors on the main GUI page for these disks they need replacing, you'll also get notified, if system notifications were configured, and it's highly recommended to do so.
  9. JorgeB
    I suspected it could be that, but it looks different from what I remember, you should definitely remove it from Unraid 6.
  10. JorgeB
    SMART errors or read errors? Some SMART warnings can be unrelated to disk health, e.g. UDMA CRC errors, you can post the diagnostics if you want (tools -> diagnostics) so we can take a look.
  11. JorgeB
    You can wait but it will likely have the same result as before, i.e., no superblock found. Emulated disk isn't mounting, with UD you'd be using the old disk, emulated disk can only be used in the array.
  12. JorgeB
    Parity check/sync will be slower, writes with normal writing mode will likely be a little slower, if using turbo write difference will be bigger, but also depends on the rest of the hardware and what model are the 6TB disks, mainly how many platters they have.
  13. JorgeB
    You can format now, it will take several minutes with v6.7.2, much faster if using v6.8rc. You can also use the array during the parity sync but is not recommended since both the sync itself and the data transfer will be slower than normal, though data transfer should be better with v6.8, sacrificing the sync.
  14. JorgeB
    Array looks normal to me, where's this from? It's not stock Unraid. It's saying parity doesn't have a filesystem, as it shouldn't, same for a floppy device. If something isn't working correctly please post the diagnostics: Tools -> Diagnostics
  15. JorgeB
    In normal mode there's a mount attempt and it warns of xfs corruption, but then xfs_repair can't find the superblock, very weird, it would suggest there's a serious problem with the file system on the emulated disk, possibly parity wasn't 100% in sync. Try to mount the old disk with UD, if it mounts correctly and since the disk looks healthy it's best to do a new config and re-sync parity, note that if there's any data written to that disk after it got disable will be lost.
  16. JorgeB
    Stop the array, start in maintenance mode, and on the console (or putty) type: xfs_repair -v /dev/md4 And see if it repairs or not.
  17. JorgeB
    Stop array, start array in normal mode and post new diags.
  18. JorgeB
    It does look fine, recommend replacing/swapping cables before rebuilding to rule them out if it fails again.
  19. JorgeB
    That's very strange, it's like it's not finding a valid filesystem, please reboot, start the array and get new diags.
  20. JorgeB
    You need a cache pool with one or more fast NVMe devices or a SATA SSD pool with multiple devices, for example my cache pool is a raid5 btrfs pool with 6 SSDs, on my desktop I'm using dual NVMe devices in raid1.
  21. JorgeB
    Disk dropped offline, hence why no SMART, check connections and post new diags after rebooting.
  22. JorgeB
    UDMA CRC errors are a connection problem, not a disk problem, 9 times out of 10 a bad SATA cable, though a single error like the one on the bottom disk is nothing to worry about, also they don't reset, as long as it's not increasing you're fine, if still increasing replace the cable.
  23. JorgeB
    Forum goes down every day for a couple of minutes at 8AM my time (12AM PST) Is this known and expected, like it does a daily reboot or something?
  24. JorgeB
    But it's still likely the problem, I would expect the Asmedia controller used on that board to support trim, but since the board is quite old it might be using an earlier revision, you can easily test by connecting the SSD to one of the Intel ports, and issue is definitely not UD related so you should post on the general support forum instead if more help is needed.
  25. JorgeB
    Since cache is btrfs you can do an online replacement/upgrade, as long as you have an extra port to have both connected at the same time, more info here, see part in bold about single device: https://forums.unraid.net/topic/46802-faq-for-unraid-v6/?do=findComment&comment=480419
×
×
  • Create New...