Faceman

yep, extremely bad luck on that one. in my ~15 years running home servers i've only ever had one disk go nuclear like that, and one other was DOA. most of the time I'm only replacing disks due to their age, even though they still test fine.

the worrying lines are : 5 Reallocated_Sector_Ct PO--CK 093 093 010 - 17272 187 Reported_Uncorrect -O--CK 001 001 000 - 5725 197 Current_Pending_Sector -O--C- 098 097 000 - 1448 198 Offline_Uncorrectable ----C- 098 097 000 - 1448 They should all be 0 shame to see a drive die at only 30k hours, but she's well cooked mate. stop trying to rebuild onto a broken drive, throw a new one in and rebuild onto that.

This is where I'm heading with my setup, currently have the main array as a big archive, but there are two ZFS pools, one is a mirror of M.2 disks, the other a Raidz1 of SataSSDs which is my main working cache.., different shares go to different primary pools, and in Unraid 7 I can have shares move from pool to pool, or pool to array, with the primary/secondary options. However, there is no easy way to have a third tier, like SSDZFS>HDDZFS>ARRAY.

just a reminder/heads up to people trying to upgrade the FW on the 9300-16i, it has 2 separate SAS3008 controllers on board so you need to flash both of them! if that is the only card in the system you can use sas3flash -o -fwall SAS9300-16i_IT.bin to flash each controller, there is also a command to update certain controllers but this is easier if its the only card you have.

I'd be happy to wait until the next LTS, which is expected to be 6.12 due around mid november or so, call it mid december for release once all packages are up to scratch. OpenZFS 2.2.7 commits are already hard at work on 6.11 compatibility, since 6.10 is only a couple of weeks from EOL at this point. 2.2.8 should then be 6.12 compatable before the end of the year.

I think it should be calling /usr/local/sbin/mover not /usr/local/sbin/move I assume you could probably fix it by dropping a good copy of the mover script into the sbin folder There is also mover.old which has the original mover script backed up. My "mover" script looks like this, and once that fires it calls /usr/local/emhttp/plugins/ca.mover.tuning/age_mover script that does the real job. #!/bin/bash PPPID=`ps h -o ppid= $PPID 2>/dev/null` P_COMMAND=`ps h -o %c $PPPID 2>/dev/null` /usr/local/emhttp/plugins/ca.mover.tuning/mover.php $P_COMMAND $1

I just did a test run with the settings adjusted to 5% below my current actual fill level and it worked. So something seems screwy if some people have it working and others dont, we will have to wait for @Reynald to return.

Was just a guess, something to test

I've been seeing that as well. I've also noticed it seemingly ignoring my fill settings, moving files when the pool is only at 20% full, when I have the move threshold set at 70%

You may have to re-do those settings if they were configured before installing the plugin. If unsure, use the test mode dry run and check the logs to see if it does what you expect, then run it for real and monitor it for a few runs.

should the empty folder cleanup really be trying to clean up folders in shares that are set to only reside on the cache and have no secondary location? or do I need to manually add them to the exceptions? I'm not sure how and why but I just let it run out of test mode and it removed a huge number of what seemed to be empty directories in my docker share, they seem to have all been empty but it still caused some weirdness with losing my docker folder icons and such. I think they were leftover from when I was running a docker folder rather than currently back to using an image, but it shouldn't been removing things in shares that the mover should ignore. It might have been unrelated since it fixed itself after some time, but still I think it should ignore cache only shares by default

Ahh that makes sense. Neat

Still mainly waiting for OpenZFS to officially support newer Kernels, unraid 7 is on 6.8.x, OpenZFS officially supports up to 6.9.x now, but 6.8 and 6.9 are officially EOL so we need to move to 6.10+ Technically we could see a move to 6.9.x for another U7 beta, since OpenZFS 2.2.5 only just came out with support for that, but it is still EOL so 6.10+ is better, but I think it's just going to be a while of waiting before a proper release. on the upside, a longer beta period means a more stable release!

If I enable Rebalance Shares my log gets spammed (to the point of filling the entire log FS) with Rsync throwing errors for files that obviously don't exist. not sure what the normal operation of that function looks like, but it seems like its just trying to move every file from cache to array, whether it actually exists or not. I have also seen it trying to move files from a share on my secondary cache pool that shouldn't (and doesn't) even exist on that pool. I have mover logging disabled, but the rsync commands are very spammy. I'm not sure what the /./ directory means in this case? e.g. Aug 12 12:55:26 Morpheus root: Moving "/mnt/cache_sata/./Media/Music/John Coltrane/A Love Supreme/A Love Supreme.jpg" to /mnt/user0/ Aug 12 12:55:26 Morpheus root: rsync: [sender] link_stat "/mnt/cache_sata/Media/Music/John Coltrane/A Love Supreme/A Love Supreme.jpg" failed: No such file or directory (2) Aug 12 12:55:26 Morpheus root: rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1338) [sender=3.3.0] and I have hundred of megs of it generated every move.

I know they need to be carefully handled in bash scripts, but they've been fine for about 10 years so something has changed recently that doesn't like them. I'm renaming them as I go anyway.

I'm seeing some minor errors in the logs related to files with a $ in the filename, which is usually a valid symbol, but perhaps something isn't being escaped or parsed properly somewhere. for example : stat: cannot statx '/mnt/disk7/Media/Music/Metallica/1987 - The .98 E.P.-Garage Days Re-Revisited/Art/Front.jpg Theres meant to be a $5 in there and it's getting messed up, lots of other examples too.

and a more streamlined and stable base OS for the average user that doesn't need every possible bell and whistle.

Just gotta say, Love the rapid development going on here, massive improvements in functionality and usability.

Mover tuning plug-in can also do moves based on disk fill % so you can use it to have the mover only fire when it absolutely needs to if you want to keep your array spun down more often. and you can do per-share tuning for it too, still all run from the one scheduler though so you cant have one share move nightly, one move weekly and another only move when SSD is full for example. Things like that are why I would like more mover controls built into the OS and not rely on layers of plug-ins and custom scripts to do these more complex setups. now that we have the ability to do multiple pools and eventually multiple arrays it will have to get more complex and configurable at some point.

I also mentioned the need for a third tier option in the mover settings now that we have complete freedom with how our pools are configured. at the moment i have 2 pools (an NVME ZFS pool and a Sata SSD ZFS pool) and the array with some shares hitting one or the other first, and one share that never touches the array and is moved from one pool to the other but I would love the ability to control multiple tiers built into the mover.

Are you already using the popular Mover Tuning Plugin to do this? I use mover tuning with two separate caches and have difference settings per share, mover runs hourly in my case but only moves files that are 2 weeks old or if the pool gets full. the only thing it cant do at the moment is move data in chunks when full, it can only trigger a full dump move at a certain threshold. I'd like to have more of a constant rotation, keeping it filled to a certain set percentage automatically and moving to the array as needed. some features I'd like to see on top of that being integrated would be multiple tiers, for fast cache (NVME pool for example), storage (e.g. ZFS HDD array) then an archive of spun down HDDs in an unraid array. And some kind of read caching, even a simple folder preload script, for example, you read a file from the HDD array and it automatically copies the rest of that folder up a tier to the SSDs, up to a certain threshold and automatically clears it if not used within a set time frame for example.

I think it would only have to be an extension on the top licence tier. HDDs are available in such large sizes now that the vast majority of home NAS users can get by with 4-6 HDDs, and still have ~100TB of useable space in many cases. it's only the absolute top end power users that would run multiple arrays, with multiple multi-disk pools on top of that. so maybe the tiers should be 6 drives, 12 drives and unlimited drives ? Edit: I'm out of date, the updated tiers are 6 and unlimited already.

As much as I'd also like to see multiple arrays and a new webui, I would really like to see a smarter and more customisable mover mechanism, expanding on the popular mover tuning plug-in to make better use of the cache instead of just filling it up then dumping it all. With multiple pools now functional in 7.x and multiple unraid arrays a likely addition further down the line, better control over the mover and caching is getting more important for setting up smarter tier based systems. I'd like to (for example) have a 3 tier caching mover setup, rather than just a primary and secondary. You could have for example a fast but small NVME pool ontop of a larger ZFS HDD or sata SSD pool, but all of that gets a weekly dump to a large unraid archive of spun down, mixed capacity disks. Currently this is mostly possible with NVME as primary, SATA as secondary now that the mover supports pool to pool directions, rather than just from a pool to the array like the old days. Then you currently need a manual script to handle the archival to the array, but having that handled by a more advanced mover logic (like the mover tuning plugin) would allow for files to stay on the middle tier as long as there is space available.

just tried to re-install this after rebuilding my docker image.. endless port allocation errors.. no port conflict as far as I can see. Not a permissions issue as I nuked the appdata too. Will go back to my windows VM version for now. Edit.. I seem to have fixed it with some permissions tweaks as per https://github.com/Banh-Canh/docker-FMD2/issues/13 Well. some of the text and icons are missing still, so somethings weird but it's "working"

Mate, this looks excellent. Cheers.