IZSkiSurfer
Members
-
Joined
-
Last visited
Everything posted by IZSkiSurfer
-
Every 3 seconds I see a "lsof -Fn /mnt/disk1" command running which uses a fair amount of CPU. I figured out it's triggered from within "/usr/local/emhttp/webGui/nchan/update_1". I tried to execute "lsof -Fn /mnt/disk1" as root via SSH but it exits with code 1. I don't think that's intended. If I e.g. do "lsof -Fn /mnt/disk1/appdata" it works fine. If I do "lsof -Fn /mnt/disk1/isos" it also exits with code 1 whereas if I open an mp4 via SMB it shows: p15193 n/mnt/disk1/isos/test.mp4 But the widget in the dashboard always shows 0 streams: My mounts regarding disk1 look like this: disk1 on /mnt/disk1 type zfs (rw,relatime,xattr,posixacl,casesensitive) disk1/system on /mnt/disk1/system type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/domains on /mnt/disk1/domains type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/remote on /mnt/disk1/remote type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/appdata on /mnt/disk1/appdata type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/isos on /mnt/disk1/isos type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/media on /mnt/disk1/media type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/paperless-consume on /mnt/disk1/paperless-consume type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/local on /mnt/disk1/local type zfs (rw,noatime,xattr,posixacl,casesensitive) disk1/cache on /mnt/disk1/cache type zfs (rw,noatime,xattr,posixacl,casesensitive) /mnt/disk1/system/docker/docker.img on /var/lib/docker type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/) /mnt/disk1/system/docker/docker.img on /var/lib/docker/btrfs type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/) /mnt/disk1/system/libvirt/libvirt.img on /etc/libvirt type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/) I haven't attached the diagnostics yet because I'm not sure if some credentials might be in there and atm. I'm not having the time to have a deeper look in the diags but I can provide it if needed. IMHO the $mnt_list is built wrong. It only consists of /mnt/disk1 in my case whereas it probably should be a space separated list of all folders or alternatively "/mnt/disk1/*". And even if the command would be fixed it would still not work (in my case). The lsof takes more then 3 seconds in my case (it's an NVMe so dunno why) and the timeout of 3 seconds in the exec kills the lsof before it would ever return back any data. Also if it would work there would be plenty of "streams" on appdata. In the context of the widget I would consider a "stream" being a file accessed from external via network rathen than file handles opened by unraid/docker... but I don't know if that's possible to filter or gather somehow
-
you could also use rar, rar2fs, etc. via docker just install apropriate containers and write some neat aliases for your shell
-
Have you disabled both at once or were you able to identify if it's caused by nerdtools (or the Unraid Connect)? Regarding omz/zsh I manually added the following plugin via link: https://github.com/donbuehl/oh-my-zsh/blob/main/oh-my-zsh.plg (plugin looks clean and save to me). It complained about tmux but tmux was installed anyway by other plugin so it worked all fine. RAR & vim/nano maybe more might be available via https://pkgs.org/
-
Okay I've got mine running again. What I did so far: Remove all 3 Unassigned Devices* plugins (didn't help), removed NerdTools (which isn't supported anymore due to you know ...), Unraid Connect and ZFS Master for Unraid. Rebooted and it worked. Now I reinstallled Unassigned Devices* and ZFS Master for Unraid and it still runs after a reboot. So I assume it's either related to Unraid Connect (and I also do havve had the API message...) or to NerdTools. Otherwise it might have been one of the others which was resolved by uninstalling and reinstalling them, but I doubt it. Let us know if you have either NerdTools and/or Unraid Connect installed and if uninstalling helps...
-
I'm facing exactly the same issue after the upgrade... haven't tried anything yes except for normal reboots. On the "main" page the unassigned devices is taking a fair amount of time to load.
-
I'm not at my computer at the moment but maybe it's because you have more then 10 drives. On some positions in the code jbartlett iterates from 0-9 when gathering informations. Maybe he does that on other places different so information for the 11th drive and so on are missing and you get those errors. But that's really just a guess.
-
Congrats - now it "initializes" fine THX Just the problem with the benchmark to be resolved "Scanning Disk 1 (nvme0n1) at 0 GB - 0|9999999999|0 (1)" which I mentioned here: But if I got you right you're working on that @jbartlett?
-
But be aware if you "just" loop from 0 to 9 you need to change the numbering within your loop. My first try was also to loop 0 to 9 but that results in wrong array index @ HW.A.Ports and PortNo etc.
-
Just for clearification: The Java stuff also runs out of memory nearly instant if one of those dd commands fails and spams the console buffer. @jbartlett I'll send you the requested debug log along with with my Whatsapp number via PM - feel free to message me there. I'm not checking the forum constantly.
-
Sorry but the spinup_* file(s) are still wrong... bs=512 instead of bs=4096 I double checked it's 2.9.7 and also removed the container completely and pulled fresh. Also tried to delete everything under /tmp/ and restarting the container. It's always generated with bs=512 I checked the Spinup.cfm and I think the problem could be that you loop i from 1 to 9 so you miss the first nvme which is enumerated as nvme0n1 Edit: I can confirm if you use <CFSET DeviceID="nvme#i-1#n1"> it works. The next problem is somewhere in the Benchmarking cfm files. They run the following command: dd if=/dev/nvme0n1 of=/dev/null bs=10240 skip=0 iflag=direct conv=noerror status=progress 10240 is also not working with a drive which uses 4K --> dd: error reading '/dev/nvme0n1': Invalid argument And I found a bug: If the manufacturer of a drive is not detected (= Unknown) and you head over to the image edit page there are some errors.
-
Sorry I was very busy the last days. # cat /sys/class/block/nvme0n1/queue/hw_sector_size 4096 # cat /sys/class/block/nvme0n1/queue/logical_block_size 4096 # cat /sys/class/block/nvme0n1/queue/physical_block_size 4096 Try this in your docker console: echo '' > /opt/lucee/server/lucee-server/context/password.txt
-
nvme format -lbaf=1 /dev/nvme0n1 I sideloaded the nvme binary to unraid. But take care - don't do this on a drive without a backup. It will erase the data. As far as I digged into the cfm files those are the generated spinup scripts and they clearly have bs=512 as you can see. It might be that a 1310720 blocksize is used later for the benchmark but the spinup scripts do not - at least not for me.. Any other information you need?
-
Small update: The problem seems to be the blocksize 512. I tried it on baremetal 512 won't work, 4096 will work. I switched my nvme to 4K mode for maximum performance. So I guess iflag=direct in combination with an 4K blocksize does technically not work ;). So the DiskSpeed docker should first check the blocksize being used before generating the temporary shell scripts. E.g. by using "lsblk -o MIN-IO -rdn /dev/nvme0n1"
-
Ich think the problem might be related to this: # cat /tmp/DiskSpeedTmp/spinup.sh /tmp/DiskSpeedTmp/spinup_nvme0n1.sh & /tmp/DiskSpeedTmp/spinup_sda.sh & /tmp/DiskSpeedTmp/spinup_sdb.sh & /tmp/DiskSpeedTmp/spinup_sdc.sh & # cat /tmp/DiskSpeedTmp/spinup_nvme0n1.sh dd if=/dev/nvme0n1 of=/dev/null bs=512 count=1 skip=190497 iflag=direct conv=noerror dd if=/dev/nvme0n1 of=/dev/null bs=512 count=1 skip=283361 iflag=direct conv=noerror dd if=/dev/nvme0n1 of=/dev/null bs=512 count=1 skip=309807 iflag=direct conv=noerror dd if=/dev/nvme0n1 of=/dev/null bs=512 count=1 skip=557696 iflag=direct conv=noerror dd if=/dev/nvme0n1 of=/dev/null bs=512 count=1 skip=909170 iflag=direct conv=noerror It tries to "spinup" the nvme0n1 (which exists). This drive is the only one in the array (no parity what so ever atm.) Because this takes forever I think catalina runs out of memory immediatly I'm not that into the docker architecture/unraid yet so I dunno why it can't read from the device.
-
Just want to let you know that I have the exact same error. I was bricking my array yesterday and startet a fresh array, downloaded all previous installed CA stuff and ending with exactly that same result. I created an empy password.txt but doesn't help. GUI stalls after "Spinning up hard drives" (even if I have not a single spinning rust installed :p).
