KyleS

So you can very clearly see from shfs that it's ignoring long paths, regardless if you manually create a share config in /boot. ``` Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: / fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /old fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /old fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: / fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /old fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_statfs: pid: 3194 path: /old Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: / fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /old fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getxattr: pid: 3194 path: /old name: system.LOCATIONS size: 4096 Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: / fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /pvc-3af861ae-2ebb-4536-9005-f95a13b49bfb_long_share-config fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /pvc-3af861ae-2ebb-4536-9005-f95a13b49bfb_long_share-config fi: (nil) Feb 14 20:31:27 FileServer shfs: debug: shfs_getattr: pid: 3194 path: / fi: (nil) Feb 14 20:31:28 FileServer shfs: debug: shfs_getattr: pid: 3194 path: /pvc-3d4684fc-058b-4fcd-b855-8883ea64e4dd_other_long_data fi: (nil) ```

https://kubernetes.io/ @limetech is there an ETA on this.

OK so this is indeed a straight bug in either emhttpd and shfs (I'm going to respect the license and not disassemble them, noting that disassembly is permitted to fix issues such as this by the DMCA)... The dynamix php edit page is hard coded to a length of 40. Some shitty application is writing shares.ini every single second, which is where the bug appears to be.

What on earth are you talking about. There's nothing in there. `cd /mnt/user` `mkdir pvc-13cc4602-1b86-40a0-bbf3-76baedabf2ff_unraid_config` Does that share show up in the WebUI. This was provided very clearly in the first post. it looks like there's some dumb name length limit in the WebUI that skips these.

Sorry, you've tried this with the exact same folder name and you're not seeing the same behaviour with the WebUI?

Of course. It's a straight up bug.

Yeah, I have a couple war games apps to keep the logic sane, but they never went quite right after hacking on them for a couple hours. I'm still on the road for the holidays, so haven't spent the time to sit down and finish them properly. Really pisses me off that Unraid is this closed paid product that doesn't even get the basics correct.

Certainly doesn't fill the most empty disk.

Yeah - none of this reasonable. Here's a real solution. What a complete piss-off.

As Unraid continues to be completely worthless at managing data, I've gone back to the roots which is mergerfs. Thankfully, there's a modicum of thought, and they have a balance utility. Spinning a container and running balance still maintains the data consistency rules of shfs, and automates splitting as appropriate. It's completely unbelievable how terrible mover is, and how it ignores all placement rules. Of course the container needs to be privileged, with /mnt passed to the container, and /dev/fuse passed as a device. Cheers. FROM alpine:3.17 RUN apk add --no-cache curl && \ curl -L https://github.com/trapexit/mergerfs-tools/archive/master.tar.gz -o /tmp/mergerfs-tools.tar.gz && \ tar xvf /tmp/mergerfs-tools.tar.gz mergerfs-tools-master/src/ -C /usr/local/bin --strip-components=2 && \ chmod +x /usr/local/bin/mergerfs.* && \ rm -rf /tmp/mergerfs-tools.tar.gz && echo "@testing https://dl-cdn.alpinelinux.org/alpine/edge/testing" | tee -a /etc/apk/repositories && apk add --no-cache mergerfs@testing bash python3 rsync CMD ["/bin/ash", "-c", "/bin/mkdir /tmp/balance && /bin/mount -t mergerfs '/mnt/disk[0-9]*' /tmp/balance && /usr/local/bin/mergerfs.balance /tmp/balance"]

Simply not correct. The disks aren't even included in the share and mover fills those disks anyway.

Unraid doesn't seem to have any real thought put into it. Mover continues to move to full disks and ignores quota assignments. Disk splitting continues to just fill full disks (500G is reserved, which I find to be ridiculous that this is ignored and disks fill to 64KB). Does anyone actually use this seriously? Besides shfs everything else seems to be completely worthless. What am I missing?

Yeah - that's definitely not how it works with Mover. It just picks the first disk and loads it up. It's super silly and has been causing me nothing but pain. Unless if I'm missing something, this is no where near production ready (realizing, that yes, it's been around for many many years).

/dev/mapper/md*

Doesn't work at all with encryption (can't find the disks). - just needs a minor change to your "regex". Do you have a layout defragger as well?

Likely the most impactful change for 6.11. Thanks much.

Thank you very much - I've only just started testing but the tests I'm expecting to work are passing.

Understood. I'm ready to test an eBPF version when it's ready.

Partially. I also need the settings here: https://docs.cilium.io/en/v1.11/operations/system_requirements/#base-requirements CONFIG_BPF=y CONFIG_BPF_EVENTS=y CONFIG_BPF_JIT=y CONFIG_BPF_SYSCALL=y CONFIG_CGROUPS=y CONFIG_CGROUP_BPF=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_USER_API_HASH=y CONFIG_HAVE_BPF_JIT=y CONFIG_HAVE_EBPF_JIT=y CONFIG_IKHEADERS=y CONFIG_NET_ACT_BPF=m CONFIG_NET_CLS_BPF=m CONFIG_NET_SCH_INGRESS=y Quick test is here: mount bpffs /sys/fs/bpf -t bpf As an aside (if you're already in there) I also need saa7164 (it's in tree as well) - module is fine. CONFIG_VIDEO_SAA7164=m

@limetech any update on this one? It's pretty critical for newer networking applications.

nah, it looks like @limetech is paying attention now. Still disappointing there's countless reports for this closed product and still no fix.