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.

So you basically need 3x PCI-E 16x slots, with two running at 8x so your two HBAs can run at max speed? Note, the 9207's are PCI-E x4 cards.... The issue you are going to have is that desktop CPUs have a limit amount of PCI-E lanes to go around. Almost everything on the board will use a lane in some capacity. So you're gonna need to find a board that has the PCI-E/M.2 layout you have, whilst sacrificing other features, like Wi-Fi. Finding one with just the right combo will likely be an exercise in reading spec sheets and block diagrams. A quick cursory search on PCPartPicker shows that the "ASRock X670E PG Lightning" could be worth looking at perhaps. 2.5Gbps networking 3x PCI-E x16 slots 1 that runs at 16x 1 that runs at 4x 1 that runs at 1x 2x m.2 slots, that aren't listed as overlapping with the lanes elseware. Overall that gives you the ability to have 2x 9207 HBAs running, a spare 1x slot and 3x m.2s. Would need to check the block diagram to be 100% sure, but sounds like it could work, perhaps.

That's a shame. If you dont mind me asking, and it is slightly off-topic, but why Victoria and not Influx/Telegraf ?

Old thread, but any chance we can get this JSON sanitized and pushed to the Grafana library? Would allow others to easily use the template without having to hack away at it for their own purposes.

A little more testing, running 'pwmconfig' on the CLI and selecting 'manual mode' and the fans jump to life, just at full speed. Removing some of the dynamix plugins (system temperature) and rebooting however doesn't appear to resolve it, either. # EDIT More testing - Booting to BIOS and flipping the fan controls from DC to PWM, appears to resolve the issue, even after a re-install of Dynamix System Temperature....touch wood. 😛 Will monitor over the next few days.

Old (ish) thread, and separate poster, but i see this with 6.12-rc6, didn't see it with 6.11, and interestingly, I'm not on an Asus board, but an Asrock. The workaround, assuming i applied it correctly however, doesn't work for me.

What motherboard & CPU do you have? May help us shed a light on some recommendations for you.

Thanks. Currently on a Plus license, which allows me upto 12 devices. Based on my plan, I would be at 13 devices. However, I can short term remove the USB log data drive to get me 'in spec', medium-term i may just remove the dedicated docker dir SSDs, too.

Good morning everyone! In preparation for 6.12 and official ZFS support, I am mere minutes away from pressing 'buy' on some parts to finally realize my long-term goal with my system, all SSD. However, I could do with some last minute advice. What I am looking for is some advice & views, as the impact of ZFS and the new pools/cache/array layout for 6.12 isn't clear to me, at least in how it impacts what I want to do. My plan is to upgrade my current system - Ryzen 5700G 32Gb RAM (4x 8Gb) Asrock X570M Pro (no PCI-E slots or M.2's currently in use) 3x 4Tb SATA HDD's (Array) 2x 1Tb SATA SSD's (Cache) 2x 256Gb SATA SSD's (Docker Dir) 1x 512Gb USB SSD (Log data) To add - 1x LSI 9207-8i PCI-E x8 HBA 4x 1Tb SATA MX500 SSDs (matching the two existing 1Tb drives that I have) The HBA would go in my secondary PCI-E x16 slot, which is electrically 8x. Doing this would retain the PCI-E x1 slot for future uses, and would change the config of the main PCI-Ex16 to be 8x too, which would do for a 2x m.2/10G card if needed. Software configuration wise - My ideal plan, based on if I've understood the ZFS support correctly, is a disk layout of 1x ZFS Primary Storage, Z1, 6x 1Tb MX500's as my main storage 1x 'Traditional' Array, 3x HDDs as archive storage - ideally this would almost never spin up. 1x Docker Dir Cache, 256Gb Drives Overall, the plan would be to install the hardware, configure the ZFS pool, change the shares to use the ZFS as the primary storage, run mover, done. However, I am unsure on - If this configuration (share/setup wise) would work - clarity needed on ZFS implementation/share usage. What the Unraid license considers to be a attached drive when it comes to ZFS - I dont think it counts the 'unattached' drive I'm using for logging for example If the LSI 9207-8i is a decent choice, as the performance numbers here, suggests 500-600 MB/s performance, which isn't clear if that's per-drive, or for every drive attached. I did a quick google for some perf numbers, seems to scale well to the max of the PCI-E interface. Questions remain on if its any good though, as in, compatibility issues with Unraid, etc. Thanks in advance for your views and for reading this wall of text. 😛

Not a bad idea, but I'd still need to know the method in Unraid to disable local logging to disk, in favor of relying on remote syslog only. + for the rsyslog, it looks like there's a reasonable amount of custom unraid related code/notes in it - do we know if its been documented anywhere as to what's what and why in it? I assume its not arbitrary?

Hi, I'm attempting to solve a few inherent issues with Unraid in one hit, all revolving around syslogs. It's long annoyed me the reasoning why logs are lost on reboot (due to sitting in RAM), and the lack of reasonable way to make sure logs are getting captured for analysis. Note: I understand the reasoning, wear leveling, etc. but its side stepping the issue somewhat by just not having some sort of persistent log. My solution, is to use a 'remote' syslog server, in this case, Graylog, running on a separate system. Specifically for Graylog, my issue is that I'm finding that Unraid is sending the syslog message with incorrect timestamps (4 hours in the past), which when ingested into GrayLog means that 'recent queries', or anything that relies on them, are next to useless. The timezone is set correctly at both ends, too. The workaround is to flip the input type from Syslog/UDP to RAW UDP, not ideal, as you lose some of the automatic parsing being done. Question: How do we adjust the variables in Unraid for syslog events? Things like RFC formats, etc? and have it persist between reboots? Next, I have set my important containers to ship their logs directly into GrayLog, (works fine as Syslog/UDP too!), but I want to ensure that nothing is getting written locally, log wise, to the array, cache, anywhere. Question: Is there a global setting, that persists between reboots, to allow this? The key is persists between reboots for both of these, as whilst im aware of potential methods to achieve both of these questions, the way Unraid works in regards to reboots/run from RAM, makes them somewhat of an unknown. Thanks in advance for your help with this! Cheers.