September 9, 20187 yr Hi all, Mover not moving even pressing move now. seeing this on logs: Sep 9 14:20:42 Jupiter root: Manually starting moverSep 9 14:31:01 Jupiter crond[2659]: failed parsing crontab for user root: 3:30 /usr/local/sbin/mover force 2>/dev/nullSep 9 14:39:02 Jupiter crond[2659]: failed parsing crontab for user root: 3:30 /usr/local/sbin/mover force 2>/dev/null
September 9, 20187 yr Post a screenshot of the mover tuning page. You've made a mistake in the Cron entrySent from my LG-D852 using Tapatalk
September 9, 20187 yr 15:50 isn't a valid cron expression. ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12) │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday; │ │ │ │ │ 7 is also Sunday on some systems) │ │ │ │ │ │ │ │ │ │ * * * * * command to execute You'd probably want 50 15 * * * Edited September 9, 20187 yr by Squid
September 9, 20187 yr Author Tnx, I removed it temporarily... but no vement still.. triied a couple of times... Sep 9 21:06:01 Jupiter crond[2659]: failed parsing crontab for user root: /usr/local/sbin/mover force 2>/dev/nullSep 9 21:10:01 Jupiter root: Mover already runningSep 9 21:21:38 Jupiter emhttpd: req (63): cmdStartMover=Move+now&csrf_token=****************Sep 9 21:21:38 Jupiter emhttpd: shcmd (3117): /usr/local/sbin/mover &> /dev/null &Sep 9 21:21:38 Jupiter root: Manually starting moverSep 9 21:34:46 Jupiter emhttpd: req (68): cmdStartMover=Move+now&csrf_token=****************Sep 9 21:34:46 Jupiter emhttpd: shcmd (3144): /usr/local/sbin/mover &> /dev/null &Sep 9 21:34:46 Jupiter root: Manually starting mover
September 9, 20187 yr Author hope this helps. I am sure there is a lot to move.... my 1tb cache is full jupiter-diagnostics-20180909-2153.zip
September 9, 20187 yr Author seeing new logs Sep 9 21:21:38 Jupiter emhttpd: req (63): cmdStartMover=Move+now&csrf_token=****************Sep 9 21:21:38 Jupiter emhttpd: shcmd (3117): /usr/local/sbin/mover &> /dev/null &Sep 9 21:21:38 Jupiter root: Manually starting moverSep 9 21:34:46 Jupiter emhttpd: req (68): cmdStartMover=Move+now&csrf_token=****************Sep 9 21:34:46 Jupiter emhttpd: shcmd (3144): /usr/local/sbin/mover &> /dev/null &Sep 9 21:34:46 Jupiter root: Manually starting moverSep 9 21:53:53 Jupiter kernel: blk_partition_remap: fail for partition 1Sep 9 21:53:53 Jupiter kernel: BTRFS error (device sdc1): bdev /dev/sdt1 errs: wr 221, rd 21249, flush 1, corrupt 0, gen 0Sep 9 21:55:56 Jupiter emhttpd: req (71): cmdStartMover=Move+now&csrf_token=****************Sep 9 21:55:56 Jupiter emhttpd: shcmd (3187): /usr/local/sbin/mover &> /dev/null &Sep 9 21:55:56 Jupiter root: Manually starting moverSep 9 22:00:01 Jupiter root: Starting MoverSep 9 22:00:01 Jupiter root: Mover already runningSep 9 22:12:11 Jupiter emhttpd: req (73): cmdStartMover=Move+now&csrf_token=****************Sep 9 22:12:11 Jupiter emhttpd: shcmd (3221): /usr/local/sbin/mover &> /dev/null &Sep 9 22:12:11 Jupiter root: Manually starting mover
September 9, 20187 yr Looks like you need to reseat the cabling to SK hynix SC300B SATA 512GB Sep 9 11:55:51 Jupiter kernel: ata2.00: status: { DRDY } Sep 9 11:55:51 Jupiter kernel: ata2.00: failed command: WRITE FPDMA QUEUED Sep 9 11:55:51 Jupiter kernel: ata2.00: cmd 61/a0:b0:a0:ed:1b/00:00:1a:00:00/40 tag 22 ncq dma 81920 out Sep 9 11:55:51 Jupiter kernel: res 40/00:d8:e0:ef:1b/00:00:1a:00:00/40 Emask 0x10 (ATA bus error) After that, @johnnie.black (the king of btrfs) should be able to assist with the filesystem problems Sep 9 12:24:28 Jupiter kernel: BTRFS error (device sdc1): bdev /dev/sdt1 errs: wr 221, rd 21035, flush 1, corrupt 0, gen 0 Sep 9 12:24:28 Jupiter kernel: blk_partition_remap: fail for partition 1
September 9, 20187 yr Author did a reseat.. still no movement Sep 9 22:00:01 Jupiter root: Starting MoverSep 9 22:00:01 Jupiter root: Mover already runningSep 9 22:12:11 Jupiter emhttpd: req (73): cmdStartMover=Move+now&csrf_token=****************Sep 9 22:12:11 Jupiter emhttpd: shcmd (3221): /usr/local/sbin/mover &> /dev/null &Sep 9 22:12:11 Jupiter root: Manually starting moverSep 9 22:26:06 Jupiter kernel: ata2: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozenSep 9 22:26:06 Jupiter kernel: ata2: irq_stat 0x00400040, connection status changedSep 9 22:26:06 Jupiter kernel: ata2: SError: { PHYRdyChg 10B8B DevExch }Sep 9 22:26:06 Jupiter kernel: ata2: hard resetting linkSep 9 22:26:07 Jupiter kernel: ata2: SATA link down (SStatus 0 SControl 310)Sep 9 22:26:10 Jupiter kernel: ata2: hard resetting linkSep 9 22:26:10 Jupiter kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)Sep 9 22:26:10 Jupiter kernel: ata2.00: configured for UDMA/100Sep 9 22:26:10 Jupiter kernel: ata2: EH completeSep 9 22:26:13 Jupiter kernel: ata1: exception Emask 0x10 SAct 0x0 SErr 0x4090000 action 0xe frozenSep 9 22:26:13 Jupiter kernel: ata1: irq_stat 0x00400040, connection status changedSep 9 22:26:13 Jupiter kernel: ata1: SError: { PHYRdyChg 10B8B DevExch }Sep 9 22:26:13 Jupiter kernel: ata1: hard resetting linkSep 9 22:26:14 Jupiter kernel: ata1: SATA link down (SStatus 0 SControl 300)Sep 9 22:26:14 Jupiter kernel: ata1: hard resetting linkSep 9 22:26:15 Jupiter kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)Sep 9 22:26:15 Jupiter kernel: ata1.00: configured for UDMA/133Sep 9 22:26:15 Jupiter kernel: ata1: EH completeSep 9 22:26:52 Jupiter emhttpd: req (79): cmdStartMover=Move+now&csrf_token=****************Sep 9 22:26:52 Jupiter emhttpd: shcmd (3251): /usr/local/sbin/mover &> /dev/null &Sep 9 22:26:52 Jupiter root: Manually starting mover
September 9, 20187 yr Community Expert 4 minutes ago, Squid said: After that, @johnnie.black (the king of btrfs) should be able to assist with the filesystem problems Those are write and read errors, resulting for hardware problems, check/replace cables, reset values and keep monitoring to see if they increase, to display current values and reset all errors to 0 use: btrfs dev stats -z /mnt/cache Keep monitoring after a few days with same command without -z (so they don't keep resetting), all values should be 0
September 9, 20187 yr Author 3 minutes ago, johnnie.black said: Those are write and read errors, resulting for hardware problems, check/replace cables, reset values and keep monitoring to see if they increase, to display current values and reset all errors to 0 use: btrfs dev stats -z /mnt/cache Keep monitoring after a few days with same command without -z (so they don't keep resetting), all values should be 0 will do.. but still no movement cache to magnetics
September 9, 20187 yr You can always enable Mover Logging in Settings -> schedules. (And to remove it as a variable, uninstall Mover Tuning, and reboot)
September 9, 20187 yr Community Expert 3 minutes ago, aerosmith9110 said: will do.. but still no movement cache to magnetics That's expected since the cache dropped offline, power down, replace cables, power back up and try again
September 9, 20187 yr Author will do this now.. I was actually trying not to reboot ( I kinda have high regards to linux ) unlike windows..
September 9, 20187 yr Author Just now, johnnie.black said: That's expected since the cache dropped offline, power down, replace cables, power back up and try again tnx.. doing it now
September 9, 20187 yr Community Expert 1 minute ago, aerosmith9110 said: I kinda have high regards to linux linux can't help you with hardware issues, you'll need to fix the problem or will keep having issues.
September 9, 20187 yr Author Just now, johnnie.black said: linux can't help you with hardware issues, you'll need to fix the problem or will keep having issues. I meant like a super command to reset something yeah I am a noob..
September 9, 20187 yr 5 minutes ago, aerosmith9110 said: Files are moving now.. tnx to you both Please consider posting what you did to resolve the problem it helps others who may have a similar issue, TY!
September 10, 20187 yr Author I fixed the cron schedule per Squid then rebooted device. I also reseated my cache cables to make sure and did the recommendation of johnnie.black to monitor the disk errors... Then rebooted. Now I am not sure is this speed normal? I have cache dual 512gb raid 0 so from network to the box speed is awesome I am getting about 100MBps. ( 1gbps for now I am still experimenting if unraid is for me and will upgrade to 10gbps soon as I have the hardware already ready I tried and getting about 500-600MBps ) Now the problem is from cache to magnetic.. I am only seeing speeds 26MBps write and read basically my cache getting full via 1gbps network connection ! basically the 4 disk are on an h310, the 2 parity is on another h310 both in IT mode and the cache is on the mobo sata connector. Edited September 10, 20187 yr by aerosmith9110
September 10, 20187 yr Community Expert Writes to HDD array are going to be much slower than writes to SSD cache. Of course SSD is faster, but in addition to that parity is updated in realtime with unRAID so writes to the parity array are typically about one half the speed of writes to a single HDD. The speeds you are getting are worse than that, and the reason is revealed by your screenshot. You are still building parity. So in addition to the writes to the array updating parity, the parity builds are also reading and writing, and since different sectors are involved there is also a lot of additional seeking going on.
September 10, 20187 yr Author 28 minutes ago, trurl said: Writes to HDD array are going to be much slower than writes to SSD cache. Of course SSD is faster, but in addition to that parity is updated in realtime with unRAID so writes to the parity array are typically about one half the speed of writes to a single HDD. The speeds you are getting are worse than that, and the reason is revealed by your screenshot. You are still building parity. So in addition to the writes to the array updating parity, the parity builds are also reading and writing, and since different sectors are involved there is also a lot of additional seeking going on. I disabled sync.. is parity different from sync? What speed should I be expecting for an He8 drive for this process? is my screenshot speed normal? Edited September 10, 20187 yr by aerosmith9110
September 10, 20187 yr 1 hour ago, aerosmith9110 said: I disabled sync. What, exactly, do you mean by that?
September 10, 20187 yr Community Expert Is your cache SSD? I was assuming it was but maybe not. As for your screenshot speeds, I think it would be better to do a test without the parity sync going on. I'm not entirely sure what you mean by "disabled sync". Are you saying you stopped the parity sync? I'm not entirely sure what unRAID does with parity until you have completed the parity sync. The screenshot is just indicating parity is invalid. Since I can't see the Array Operations portion of that screen I don't know whether it was actually building parity at that time or not but I assumed it must be since parity isn't valid yet. We really shouldn't even be talking about screenshots anyway when what we really have is a photo. It would be a lot cleaner if in the future you actually gave us a screenshot (screen capture). Study this. It gives a more complete explanation of how realtime parity is maintained and the 2 different methods that can be used, with their tradeoffs.
Archived
This topic is now archived and is closed to further replies.