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*