ihansen

Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by ihansen

  1. Thanks! Makes so much sense 😄
  2. Hi, I had a disabled disk (disk5) and bought a new disk to replace this. To futureproof the drive, i bought my first 16TB disk, and my plan is to replace one of the parity disks with the 16TB disk, then use the old 8TB parity drive in the pool. But, the parity rebuild is taking forever. Is the different parity drive sizes an issue? I have searched the forums for tips, but I am not able to translate those answers to my situation and logs. That might be due to lack of understanding 🙂 Please see the attached diag if you have the time and knowledge to help me diagnose this. Maybe you can see why drive 5 has been disabled also? 🙂 Thanksfor your help! enterprise-diagnostics-20221230-1030.zip
  3. Thanks again Jorge! Worked like a charm.
  4. Hi, I updated to 6.11.5 yesterday, and also added a new disk. When starting the array, the GUI does not quite follow, and shows the array as not started. But, it is started, as docker containers are running as normal. I did try a reboot, but that did not help. Any ideas? enterprise-diagnostics-20221202-1759.zip
  5. For me, this is the one feature that's missing to make Unraid my ultimate homelab server. Snapshots is essential when debugging and testing different setups, and i would love to see this integrated in the webui!
  6. Wow - thanks @JorgeB for the quick reply and the pointer to the thread regarding Ryzen and RAM issues. I did not find any references to C-states in the BIOS (will google some more to identify this), but i have corrected the memory speeds now to 1866 MT/s as recommended. The BIOS was misleading me here, as it listed the setting as 1866 MHz, but it was actually referring to 1866 MT/s. I have an active spare in my server, so will try to copy the data and reformat the disk. I found this witch looks like the best guide to follow for this operation. Thanks again!
  7. Hi, I've been using unraid for several years now, but due to a massive disk crash not to long ago, I reinstalled the server and changed my disks to BTRFS to get snapshot and versions of files. Things have been smooth sailing, but this week my docker containers suddenly were unresponsive. I tried all the tricks i could find on the forums, but the docker daemon and containers were all loced up. By chance I noticed some errors in the log when writing to some of my shares (but not all), that stated that the write operation stopped, because it was a read only filesystem, but the mount command shows no information about this. As far as i can se, the dashboard does not show this information either. My server is just now finishing a parity check after a reboot (only way to fix the docker issue) What should be the first step after that finishes? As BTRFS is quite new to me, I'm reluctant to keep poking around, and would really appreciate if someone with a better understanding then myself would lend their eyes on my logfiles and help me understand what has happened. Shows filesystem as read only: root@Enterprise:~# root@Enterprise:~# touch /mnt/disk1 helloforums root@Enterprise:~# touch /mnt/disk2 helloforums touch: setting times of '/mnt/disk2': Read-only file system root@Enterprise:~# touch /mnt/disk3 helloforums root@Enterprise:~# touch /mnt/disk4 helloforums root@Enterprise:~# But mount does not show as read only: root@Enterprise:~# mount proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) tmpfs on /var/log type tmpfs (rw,size=128m,mode=0755) /dev/sdb1 on /boot type vfat (rw,noatime,nodiratime,flush,dmask=77,fmask=177,shortname=mixed) /boot/bzmodules on /lib/modules type squashfs (ro) /boot/bzfirmware on /lib/firmware type squashfs (ro) hugetlbfs on /hugetlbfs type hugetlbfs (rw) overlay on /lib/modules type overlay (rw,lowerdir=/lib/modules,upperdir=/var/local/overlay/lib/modules,workdir=/var/local/overlay-work/lib/modules) overlay on /lib/firmware type overlay (rw,lowerdir=/lib/firmware,upperdir=/var/local/overlay/lib/firmware,workdir=/var/local/overlay-work/lib/firmware) /mnt on /mnt type none (rw,bind) /dev/md1 on /mnt/disk1 type btrfs (rw,noatime,space_cache=v2) /dev/md2 on /mnt/disk2 type btrfs (rw,noatime,space_cache=v2) /dev/md3 on /mnt/disk3 type btrfs (rw,noatime,space_cache=v2) /dev/md4 on /mnt/disk4 type btrfs (rw,noatime,space_cache=v2) /dev/sdp1 on /mnt/cache type btrfs (rw,noatime,space_cache=v2) /dev/sda1 on /mnt/tempdata type btrfs (rw,noatime,space_cache=v2) shfs on /mnt/user0 type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) shfs on /mnt/user type fuse.shfs (rw,nosuid,nodev,noatime,allow_other) /mnt/cache/system/docker/docker.img on /var/lib/docker type btrfs (rw,noatime,space_cache=v2) /mnt/cache/system/libvirt/libvirt.img on /etc/libvirt type btrfs (rw,noatime,space_cache=v2) gdrive_crypt: on /mnt/user/mount_rclone/gdrive_crypt type fuse.rclone (rw,nosuid,nodev,allow_other) rclone_upload/gdrive_crypt:mount_rclone/gdrive_crypt on /mnt/user/mount_mergerfs/gdrive_crypt type fuse.mergerfs (rw,nosuid,nodev,allow_other,default_permissions) root@Enterprise:~# enterprise-diagnostics-20220119-1039.zip
  8. Hi - Sorry to reply to this old thread, but this script seems to be doing exactly what I'm looking for. Have you done any interesting observations or changes using this script that might be useful for me to know before implementing it? Any insight appreciated! Br. Thomas