statistical-sable4195

Share configuration: Allocation method: Most Free Multiple disks with relatively even free space distribution Cache drive configured to move files to array Mover tuning plugin is NOT used. Issue During the move operation from cache to array, hardlinks are occasionally breaking. I suspect the cause is mover's behavior when allocation method wrongly picked different disks for the files sharing an inode, but different path. This is likely not limited to, but especially affecting "Most Free" allocation method where free space is evenly distributed and each file in iteration is highly likely to land on a different disk by the allocator. Observed Behavior 1. Moving File A: Jan 14 10:05:34 Tower move: move: /mnt/cache/archive/torrents/isos/linux/debian12/debian12.iso Success Allocation method selects disk1 (has most free space) Move succeeds 2. Moving File B (hardlinked to A on cache): Jan 14 10:05:34 Tower move: move: /mnt/cache/archive/data/isos/debian12/debian12.iso -> /mnt/cache/archive/torrents/isos/linux/debian12/debian12.iso Invalid cross-device link Hardlink breaks Operation fails with "Invalid cross-device link" File B remains on cache and is not moved Hypothesis: Allocation method probably advertised disk2 to mover's hardlinking operation (since disk2 now has most free space after File A moved to disk1) Bonus issue - logging inconsistency Mover's logs appear to be misleading. Log messages suggest hardlink operations are occurring on cache, regardless if they fail or succeed: Jan 14 10:05:00 Tower move: move: /mnt/cache/archive/torrents/isos/linux/debian11/debian11.iso Success Jan 14 10:05:00 Tower move: move: /mnt/cache/archive/data/isos/debian11/debian11.iso -> /mnt/cache/archive/torrents/isos/linux/debian11/debian11.iso Success However, successful hardlink preservation cases (possibly when same disk is picked by allocation method before move) still show cache paths in logs, indicating the logging doesn't reflect the actual destination paths (should be -> /mnt/diskN). Hypothesis The hardlink breaking probably occurs when: First file moves to disk1 (selected by allocation) disk1's free space decreases below disk2 Second file, which was a hardlink attempts to move to disk2 (now has most free space) Cross-device hardlink attempt fails If my hypothesis is right, mover shouldn't rely on the allocator's response when trying to hardlink a file, which I believe was the correct behavior in previos Unraid versions since this was working before and I started observing broken hardlinks in 7.0.0 Additionally. mover logs may need to be updated to show actual disk paths it's trying to use when hardlinking rather than source cache paths to better understand what's happening.