boomam

Re: docker-socket-proxy Container template needs updating to include `--tmpfs /run Not having this causes the container to immediately crash upon start with - mkdir: can't create directory '/run/haproxy': Read-only file system /docker-entrypoint.sh: line 11: can't create /run/haproxy/haproxy.cfg: nonexistent directory [NOTICE] (1) : haproxy version is 3.0.10-346eb4f [ALERT] (1) : config : Cannot open configuration file/directory /run/haproxy/haproxy.cfg : No such file or directory This is outlined on the LSIO doc page, here as being required to run (it's in each example, and defined in the parameters list too). I have opened a PR (#253) to update the template accordingly.

Any particular model, or just Supermicro cables in general?

Hi, Does anyone have any recommendations for some high quality SFF-8087 SATA cables? I'm currently using the ones that came with my controller, here, but one of my drives keeps getting CRC errors every few months, and for the cost of replacing the cables with something decent, it'd rather take the cables out of the equation as being at fault. Thanks in advance!

Having this issue too, on 6.12.2 - ZFS Master doesn't exist for me, (it did a few weeks ago as i wanted to check it out though). There's nothing actually on the array either, other than my media. Everything 'active' is on a ZFS pool, and the only thing that can access the media is Jellyfin, which is off right now. Seemed fine on 6.12.1

No worries, I can wait on the final fix and then test that if you want? I'm in no rush to apply the quota. 🙂

Thanks. Attempted to put in 1T as a test on a dataset, but it doesnt want to apply. Unable to update dataset Output: 'cannot set property for '\''storage/dataset-test'\'': '\''compression'\'' must be one of '\''on | off | lzjb | gzip | gzip-[1-9] | zle | lz4 | zstd | zstd-[1-19] | zstd-fast | zstd-fast-[1-10,20,30,40,50,60,70,80,90,100,500,1000]'\''' Tested with various settings, and not touching them beyond what shows up in the popup. Always some variant of the above. As an example with the following settings - Compression - Inherit Quota - 1 T Record Size - Inherit Access Time - Off Extended Attributes - On Primary Cache - Inherit Read Only - Off Sync - Standard (Default) Unable to update dataset Output: 'cannot unmount '\''/mnt/storage/dataset-test'\'': pool or dataset is busy'

Thanks for clarifying. As a question, the quota's on the datasets shows a default of 'B', so I assume bytes, but the maximum I can put in is 10000 B? Is this a known thing?

If you know the command you want to run to achieve that as a 'one off', you can just use User Scripts to schedule it with Cron.

Probably a silly question, as ZFS is ZFS, but is there any negative impact to the usage of this plugin or ZFS features, considering they are not exposed in Unraid itself nativly? For example, if i create sub-datasets and/or snapshots, then Unraid 6.13 adds support for managing that in the GUI, i assume it'll just work?

Re-tested after the 6.12.2 update today, same error persists, same workaround resolves.

Morning all, Has anyone noticed a bug that prevents virtiofs share passthroughs working with VMs, where the share is set as exclusive access? Specifically this GUI error when starting the VM: internal error: virtiofsd died unexpectedly And this log error: libvirt: error : libvirtd quit during handshake: Input/output error Workaround is to do something to turn off exclusive shares, such as enabling NFS, but its a weird bug. Anyone else come across this? Thanks!

Decades of working with storage arrays at various levels of enterprise, along with building lots of home-grown solutions based on anything from Unraid, to True(Free)NAS and their contemporaries. In a normalized setup, the difference is not a consideration factor whatsoever. That's true of anything though, no? The devil's in the detail, in this case, BTRFS being the likely culprit, with a close second being FUSE. My moneys on BTRFS...shudder...how its considered stable in this industry is beyond me. True, however you are missing one of the major advantages of jumbo frames - dramatically less overhead. If a given implementation does not support NIC offloading, then its the CPU that deals with it - even with modern CPUs, it doesn't take much for Jumbo frames to become a factor. Equally, retries due to misconfiguration at the network level, add up too. I see your point for diagnostic purposes, but for anything close to day-to-day, or 'production', a single block device is not a great idea. One suggestion here, would be to perhaps look into zvols to serve the function of the block device, thus kinda giving the advantages of both data redundancy and psudo-block-level access - assuming ZFS is in use of course.

The issue here is that not everyone is comfortable with Cloudflare tunnels - Some prefer traditional VPN, some Tailscale, etc. Equally, in order for the tunnel software to remain compatible, regular updates are needed. Unraid just isnt updated often enough for that to be possible. It would make more sense imo, to decouple the docker daemon running from the array. As an example, I run my docker images from a dedicated cache drive. For stateless containers like Cloudflared, it does not need or use storage beyond the image to start from - there is no need for the array in this case. Decoupling as such gives that flexibility for truly stateless containers to run without the array, without forcing a specific ongoing "feature" requirement on the Unraid dev team.

The difference here should be minimal/as-good-as-zero. Using an image for iSCSI storage is a very common way for iSCSI to be deployed across a variety of different platforms, be them Linux based, BSD or Windows. The question I would be curious to know, is 'what' is expected to cause the large overhead @BeliefanX is seeing - something Unraid specific, something to do with his general config, etc. - as that would be a great indicator of both resolution and possible workaround. Without some context from diag's, etc. - my first thought would be to check the common iSCSI perf issues causes - Block size on the disk, jumbo frames implementation, RSS queuing, pathing, etc. If all of those are taken out of the equation, then the target medium (in this case, Unraid/this plugin) becomes a consideration. Most of the time, its not the target at fault though. iSCSI is hard to mess up at that level. 😛

Well corrected. Regardless - We're still looking at 4 GB/s throughput on a 4x electrical connection - If you are assuming a fully loaded 9207-8i card, 8 drives, 500-550Mb/s throughput, the 4x connector is not going to limit said throughput as you are at the theoretical max, or as good as, of a SATA connector. If using SAS though, perhaps.