Jump to content

JorgeB

Moderators
  • Posts

    67,760
  • Joined

  • Last visited

  • Days Won

    708

Everything posted by JorgeB

  1. Scrub no, balance only if there's a device added or removed. Balance is usually not needed, except in some particular use cases, running a scrub once a month or so it's not a bad idea, especially if the pool is not monitored for errors.
  2. Disk dropping offline it's not usually a disk problem, but if you already swapped cables and controller it might be.
  3. You don't need to erase anything to update an existing firmware, and at least the erase BIOS command doesn't work with Linux, didn't test others, and if you don't erase no need to reprogram the SAS address.
  4. This means data corruption was detected, you can run a scrub and then check the syslog for a list of the corrupt files, these need to be deleted/restored from backups hen run the balance.
  5. Shares are just all top level folders, if a share with that name didn't exist before a new one will be created, with default settings.
  6. You need to do a new config to add array drives while keeping their data.
  7. No LSI HBA is being detected, make sure it's well seated, or try a different PCIe slot if available.
  8. Both pools have single and raid1 data profiles in use, this will happen when they are mounted with a missing device, run a balance to raid1 to fix it, you can prevent this issue by disabling array auto start, at least when making config changes, and making sure everything is there before starting it
  9. This is done on purpose, so if for example something is incorrectly passed-through to a VM (or it is after a config change) you have the chance to correct after disabling array auto-start, if not array might be inaccessible after that VM starts.
  10. Correct, so if parity is slow as writes will be slow, but if that's not a problem...
  11. Enable the syslog server and post that after a crash.
  12. This deletes the filesystem superblock on the device(s), you might be able to recover with: btrfs-select-super -s 1 /dev/sdX1 replace X with correct device, don't forget the 1 in the end, do this for both devices and if the command is successful add them to a new pool and post diags after arrays start.
  13. Could be a Linux issue with that board/device combo.
  14. UDMA CRC errors are a connection problem, they don't reset but as long as they are not increasing there's no problem, if they are still increasing start by replacing the SATA cable.
  15. Also upgrading to v6.10 and switching to ipvlan might fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right))
  16. I if you write more than 2Kb it will go to data blocks, not metadata, so yes if it's raid0 it will stripe writes to all drives, you could use single profile but data will still be distributed by all poo drives in 1GiB chunks, according to available space, it will allocated the next chunk to the drive with most space available.
  17. Feb 19 17:59:48 DroidUnRaid kernel: ata1.01: HPA detected: current 976771055, native 976773168
  18. SMR drives can get quite slow writing, no experience with that specific model but I do have some Toshiba P300 SMR and those can get as slow as 5MB/s for a few minutes, so keep that in mind.
  19. The pool is completely full, this is what btrfs is reporting, and it will be correct: Pool: cache Used: 931.00GiB Free (estimated): 2.84MiB (min: 2.84MiB) Free (statfs, df): 0.00B Something is using that space, as for the mover not working shares use cache setting might not be correctly configured, or there could be other issues, you can take a look here for some common ones, but until you free up some space pool won't work.
×
×
  • Create New...