-
Mover isn't moving after upgrade to 7. Not using mover tuner plugin
I used the "clean up" button and that removed the one with capitalization. Mover still didn't run, but once I stopped / started the array it now appears to be working - thank you!
-
Mover isn't moving after upgrade to 7. Not using mover tuner plugin
So it appears that the shareDisks.txt has 2 versions of a share; TimeMachine shareUseCache="yes" # Share does not exist timemachine shareUseCache="no" # Share exists on cache, disk1, disk2, disk3, disk4, disk5, disk6 Only the latter one appears in the list and I have it set to use cache (and it does), but mover doesn't move them. Can I simply remove the 1st one or will that get recreated at reboot? Or should I remove the share entirely and recreate (assuming that removing it will cause both entries to be removed?)
-
Mover isn't moving after upgrade to 7. Not using mover tuner plugin
Hey all, I successfully upgraded from 6.12.14 to 7 and all seems well. However I noticed that the cache drive is getting full and when I manually run Mover, the button immediately comes back and nothing happens. Enabling mover logging or running it manually simply comes back with: Jan 14 10:25:47 Storage move: mover: started Jan 14 10:25:47 Storage move: mover: finished I tried re-configuring the share to Array only, then back to Cache-Array, but didn't make a difference. Tried stopping all dockers - no change. I don't have the mover tuner plugin installed (never have). Logs attached for reference - thanks! storage-diagnostics-20250114-1032.zip
-
Weekly btrfs_preempt_reclaim_metadata_space appears to be crashing the cache drives since 6.12.2?
File system check did find and apparently fix issues. Will see what happens in 6 days... Thanks!
-
Weekly btrfs_preempt_reclaim_metadata_space appears to be crashing the cache drives since 6.12.2?
Been running this system for years, with a few upgrades here and there. Been very stable until recently, where every 6+ days I'd notice the Docker service was no longer running. Restarting would fix the issue until another 6+ days would pass. Finally bothered to look at the diagnostics, and the crashing seems to be related to: WARNING: CPU: 0 PID: 16956 at fs/btrfs/extent-tree.c:3061 __btrfs_free_extent+0x466/0xc02 ... Workqueue: events_unbound btrfs_preempt_reclaim_metadata_space ... BTRFS error (device sdh1): unable to find ref byte nr 2845564928 parent 0 root 5 owner 40359587 offset 0 Jul 13 07:04:47 Storage kernel: ------------[ cut here ]------------ Jul 13 07:04:47 Storage kernel: BTRFS: Transaction aborted (error -2) etc. I see this in 6.12.2 and 6.12.3 logs (attached) I'm going to try a BTRFS file system check next; the 2 SSDs that make up the cache drive are definitely old, but never had an issue until 6.12.2 Thoughts? storage-diagnostics-20230715-1605.zip storage-diagnostics-20230810-1055.zip
-
jazzysmooth started following [6.8.3] docker image huge amount of unnecessary writes on cache
-
-
Preclear.sh results - Questions about your results? Post them here.
You need to look on the label and see if it states Advanced Format Technology. I recently purchased 2 1 TB EADS drives and they have it.
jazzysmooth
Members
-
Joined
-
Last visited