Computron
Members
-
Joined
-
Last visited
Everything posted by Computron
-
I've been having this issue for the past while and finally making a post on it. This is what I am doing and this is what I observe: There will be cases when Unraid is low on free memory such as spinning up a VM copying a lot of files from VM to host via SFTP which caches files in RAM Docker containers temporarily needing to use a lot of RAM for certain operations In these cases, when Unraid reaches this "close to out of memory" scenario, it will: Cause significant read activity on the USB with significant IOWait as a symptom If I can use the shell, I can see on inotifywait that bzfirmware is being accessed The UI is generally inaccessible during this time, nor any of the docker containers. Even the User Scripts plugin cannot trigger my 1-min interval cronjob that pushes to an Uptime Kuma instance If I can use the shell, manually dropping caches by the below command resolves the issue echo 3 > /proc/sys/vm/drop_caches Below is the read bandwidth of my boot USB during one of these scenarios, averaging around 8 MB/s. So it seems like instead of caches being evicted from RAM, the OS is being evicted (disclaimer I'm no Linux expert). I have also attached diagnostics below. Thanks! osiris-diagnostics-20241129-2227.zip
-
Also chiming in here and had the same issue with my ASUS B660M-A D4. Weirdly this doesn't happen on a Gigabyte Z690 motherboard. Adding this to improve search: asus usb boot must change port every time unraid
-
Thanks LimeTech for being on the ball and responding quickly to this. A good lesson learned about keeping things away from production I guess when changes are not ready to be announced. I'll be waiting to see what the actual terms are and I genuinely hope more people will start to use Unraid with the starter tier. One thing I don't think was addressed in the blog post was maybe a potential upgrade from Starter -> Unleashed or any of the tiers to Lifetime. Might be too early to address but hopefully those options will be available.
-
For shares we can specify a subset of disks that can be used by the share. Under the assumption that the drives are always spinning, is there a performance benefit to using the "Included Disks" feature? According to some older discussion, if the file does not reside on the in-memory disk cache or disk tree, it would need to search the directory hierarchy to find the file: To me I am interpreting this as a linear search through the drives to find the file. Does the "Included Disks" feature impact this search at all? i.e. If I had specified that a share can only use drive 5 and I ran stat on a file on /mnt/user, it would skip scanning the first 4 disks for existence file (again assuming the file is not cached in memory or in the disk tree). Or, is it simply a constraint given to the Mover? Obviously, simply giving an application the path /mnt/disk5 or whatever would be more performant than giving /mnt/user, but I would like writes to be SSD-cached. Thanks!
-
As of Unraid 6.12 the drive path is of the form mdXpY. I think for most cases Y=1 (i.e mdXp1) but in case it's not I've added a new regex match. The modified HDD finding code looks like this: # parse /etc/mtab and check rotational status declare -a mtab while IFS= read -r -d '' line; do disk_id_regex="^/dev/md([0-9]+)p([0-9]+)" if [[ "$line" =~ $disk_id_regex ]]; then disk_id=${BASH_REMATCH[1]} part_id=${BASH_REMATCH[2]} rotational=$(cat /sys/block/md${disk_id}p${part_id}/queue/rotational) if [[ "$rotational" == "1" ]]; then mtab+=("$line") echo "Found HDD with id md${disk_id}p${part_id} (added)" continue fi echo "Found SSD with id md${disk_id}p${part_id} (skipped)" fi done < <(cat /etc/mtab | grep -E '^/dev/md' | tr '\n' '\0')
