kadajawi

So basically they have started to crack down on us, is it? They are trying to figure out if BB is running on a NAS and then block it. Even if we find another way to circumvent the block, they'll just close that loophole I suppose. Oh well, it's been good while it lasted. Any alternatives? Also, has someone talked to them about a refund yet? My 2 year plan was just renewed a few months ago. Their unannounced change makes the system useless for me (as well as users of Veracrypt etc., who may also have paid for something they won't be able to use anymore).

Thank you, that was it. It's resilvering now :)

Thanks, did that. Here's the new diags. kadanas-diagnostics-20250905-1226.zip

Thanks, here's the diagnostics. I also received the following: pool: zfs state: DEGRADED status: One or more devices could not be used because the label is missing or invalid. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Replace the device using 'zpool replace'. see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-4J scan: resilvered 0B in 11:09:36 with 0 errors on Thu Sep 4 18:03:56 2025 config: NAME STATE READ WRITE CKSUM zfs DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 /dev/sdn1 ONLINE 0 0 0 /dev/sdt1 ONLINE 0 0 0 /dev/sdp1 ONLINE 0 0 0 11954385431251436667 UNAVAIL 0 0 0 was /dev/sdj1 /dev/sdu1 ONLINE 0 0 0 errors: No known data errors I wonder if I should just do the zpool replace, or if I should fix the order of the drives first, ... kadanas-diagnostics-20250905-1119.zip

I have a ZFS array that was created manually before Unraid supported ZFS. 5 drives, RAIDZ1. During a scrub errors were detected, which led to the defective drive to be deactivated. I then tried to use my unraid parity drive (the data isn't as crucial and losing one of the drives isn't that big of a deal, bad, but not catastrophic) to replace the defective drive in the array while waiting for the new drive to arrive (I need to preclear it, check for errors, ... that's going to take quite a while). In the process of getting the drive ready to be used in the ZFS I had stopped and then started all arrays (is there no option of starting / stopping individual arrays? That would be useful...). As a result, Unraid started resilvering the defective drive. According to the FAQ the order of the drives should match the result of zpool status... it didn't. But I couldn't find a proper guide, only the information that I should stop the array, remove the drives, export the array, start it, stop it and then reattach the drives in the right order. That did not work, because once the drives are removed, the array wouldn't start. Also, export doesn't find an array to export. Changing the order of drives doesn't work either, as it rightfully detects the order to be wrong. Is this even necessary? Now to the actual problem: I stopped the array, selected the new drive (after removing the partition and quick formatting it) instead of the defective one and started the array again. Now it is saying resilvering, however the starting time seems to be the starting time from the first attempt (where ZFS wanted to resilver the defective drive). It doesn't seem to be accessing the "new" drive at all. That drive has gone to sleep. # zpool status pool: zfs state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scan: resilver in progress since Thu Sep 4 06:54:20 2025 12.3T / 81.0T scanned at 1.50G/s, 245G / 69.2T issued at 29.9M/s 0B resilvered, 0.35% done, no estimated completion time config: NAME STATE READ WRITE CKSUM zfs DEGRADED 0 0 0 raidz1-0 DEGRADED 0 0 0 sdn ONLINE 0 0 0 sdt ONLINE 0 0 0 sdp ONLINE 0 0 0 11954385431251436667 UNAVAIL 0 0 0 was /dev/sdj1 sdu ONLINE 0 0 0 errors: No known data errorsThe remaining drives are moving at a leisurely pace, which has me worried. This doesn't seem right, and what use is resilvering if it doesn't write anything to the new drive? Is this expected / wanted behavior, did something go wrong? If so, what can I do? At this pace, with this amount of data, I'm expecting more drives to die before everything is done. A lot can happen in several months.

The day I wrote that it's stable it stopped being stable again. Can't find files and folders that are too long though. Oh well. It seems to be a different problem though, as rebooting will solve the issue, rather than shutting down and starting up again.

That was the solution for me. Now it's running stable.

Sounds like my problem. It could actually be long file names... the virtual drive most affected does have some excessively long names... and there's lots of files. Also I'm on 248... there's no newer version?

That's a bit too risky for me. Usually I wait a couple of releases after a major release, if possible. I think I had the same issues before, but I can't remember how I managed to fix it. I think it depends on how many files are accessed? Then some process crashes... but memory consumption stays reasonable in Windows. Interestingly, rebooting doesn't help. I need to shut down and then start the VM again, only then does the mount come back. The particular folder / drive has a ton of files...

Sadly, after a while it still crashes... drives disappear. Despite following your guide. Any idea what could cause it?

Thanks. Your initial guide on page 11 helped, after I figured out what needs to be entered in the bash file. For now it is stable. #!/bin/bash eval exec /usr/bin/virtiofsd $(/usr/local/emhttp/plugins/dynamix.vm.manager/scripts/virtiofsd.php "$@")

Can someone please point me in the right direction? Using the latest rust version 1.11 and the latest Virtio driver (248) in Windows 10 worked well. It was stable and all. Then I wanted to add another folder... did it, and at that point it just kept crashing. Removed it, still, crashing all the time. Perhaps it is also another change that I did... I increased the amount of RAM around that time, as it kept filling up. But I have also reduced the RAM of the VM... What is happening is that during backup one of the drives disappears. I can't mount it again either, so unless I reboot Windows, it is gone The crash happens quite fast, after a few GB have been backed up. What settings do you load virtiofsd with? Ok, so I found the guide by mackid1993, but you're referring to a bash file by SimonF that I just am too blind to find...

For me besides the memory leak which I can live with if I must I also have the issue that just specific "drives" crash when Backblaze is trying to access too many files from it (it seems). Like, the drive gives me I/O errors. Any idea where that may come from? I'm using the rust version 1.7.0 (want to update to 1.8.0 when I find the time). Removing <memoryBacking> <nosharepages/> <source type='memfd'/> <access mode='shared'/> </memoryBacking> won't work as Unraid will complain then. I was able to fix this with updating the Virtio drivers and WinFSP.

According to that Github page, "--inode-file-handles=mandatory" should work. I'd like to try, but I just don't know how to enter it in the XML...

I have one that worked well for me for a couple of months. I had repasted the heatsink and had a 120mm fan in the side panel slowly blow air towards it. My system started to give me some trouble though (seems like a faulty HDMI cable was at least part of the problem), and while trying to figure out what was wrong I ran the system for a couple of minutes without heatsink. I got the buzzer, but not knowing what was happening I failed to turn it off immediately. This happened twice. Now the system boots fine, unless I have the card installed. Then I'm getting "Controller failed to load utility. Press any key to Exit." With drives connected I get a couple of error messages (BlockIO-Command Failed and LBA out of range), but I can't get into the BIOS for example where I could tell it to work in HBA mode. The system stops booting at this point. (Also without drives connected, just without the error messages). I can't enter the BIOS. Next up I'll try the card in another system, but I suppose it's gone. I can only say, keep it cool. And that means plenty of airflow. It gets really hot. (Any alternatives that support 16 drives or more and won't bankrupt me?)