-
Mover issue after upgrading to v7
Haven't had time yet to do more tests but all my shares, and pool names, don't have any spaces in them. I did try invoking '/usr/local/sbin/mover start' manually, that worked. The "move now" button does not, same as the scheduled run. Still need to test removing the plugin.
-
MightyT started following Mover issue after upgrading to v7
-
Mover issue after upgrading to v7
Same issue here, moving from btrfs pool to array. TurboWrite should be enabled for mover via mover tuning plugin, I didn't see a separate plugin, here's the relevant bit of log: Jan 11 00:35:01 UNRAID root: Forcing turbo write on Jan 11 00:35:01 UNRAID kernel: mdcmd (36): set md_write_method 1 Jan 11 00:35:01 UNRAID kernel: Jan 11 00:35:01 UNRAID root: ionice -c 2 -n 0 nice -n 0 /usr/local/emhttp/plugins/ca.mover.tuning/age_mover start 0 0 0 '' '' "/tmp/mover_start" "/tmp/mover_stop" '' '' '' '' 0 Jan 11 00:35:09 UNRAID root: Restoring original turbo write mode Jan 11 00:35:09 UNRAID kernel: mdcmd (37): set md_write_method 1 Jan 11 00:35:09 UNRAID kernel: Next time around I'll try turning "Force turbo write on during mover" in mover tuning off. Also Disks settings has "reconstruct write" set as default, and in the log it returns to "1", so I guess that mover settings is not needed.
-
-
[Support] ich777 - Application Dockers
Ok, thanks. Anyway I'm not complaining at all, just looking for an explanation. Like I said, I didn't lose any important data and will do the mounting differently in the future.
-
[Support] ich777 - Application Dockers
Yeah, I directly mounted it to /firefox/Downloads. So I'm guessing it just got overwritten on the update, which usually doesn't happen when the container is updated offline because the the folders are not "mounted" ?
-
[Support] ich777 - Application Dockers
@ich777 Since I didn't find a separete thread, I got a question / potential problem with your firefox docker: I had my regular download/temp user share mounted to the Downloads folder inside the firefox appdata, this morning the whole share was emptied (nothing that I couldn't recover but still..). And I noticed the time of the last change was pretty much exactly the time the firefox container got started this mornging (on a schedule via a userscript). And I also noticed that the automatic updater must have run since the vnc password I set was reset. Any chance the automatic update just deleted all of my share's content? I only had a quick look at the github repo and didn't see anything about the container updating itself. Like I said, didn't lose any critical data, but imagine any other docker container acted like that, i.e. your regular plex container just deleting all your media..
-
MightyT started following [Plugin] Swapfile for 6.9.1
-
Spin up script not working since update 6.9
Yeah, I forgot about that. Still that would bring the max only up to 100kb, still ok, I might just turn it down more.
-
Spin up script not working since update 6.9
exactly Yeah, I figured I wouldn't want to do that every 15 minutes, but just spreading out the potential blocks so I got a chance of reading something that isn't cached seems to work consistently. And now I'm only reading 5 blocks of max. 2kb per disk, I think that is negligible.
-
Spin up script not working since update 6.9
Has been working just fine all week. I'd change the size of the skip parameter, to only skip half the amount of blocks, at the most, and then just add a line per disk inside the loop, like this: #!/bin/bash for ((N=0; N<5; N++)) do dd if=/dev/sdc of=/dev/null skip=$(($RANDOM % 2*1024*1024*1024)) bs=$((1024 + $RANDOM % 1024)) count=10 &> /dev/null dd if=/dev/sde of=/dev/null skip=$(($RANDOM % 2*1024*1024*1024)) bs=$((1024 + $RANDOM % 1024)) count=10 &> /dev/null done
-
Spin up script not working since update 6.9
Alright, yesterday's version was a bit overkill, I turned it down a little and ended up with this: #!/bin/bash for ((N=0; N<5; N++)) do dd if=/dev/sdc of=/dev/null skip=$(($RANDOM % 4*1024*1024*1024)) bs=$((1024 + $RANDOM % 1024)) count=10 &> /dev/null dd if=/dev/sde of=/dev/null skip=$(($RANDOM % 4*1024*1024*1024)) bs=$((1024 + $RANDOM % 1024)) count=10 &> /dev/null done So 5 rounds (per disk) of reading 10 random blocks of a size between 1 and 2 kb, skipping up to 4*2^9 blocks, so that should if I'm not mistaken cover the first 8tb of my 10tb disks, way too much to be cached, with relatively little read activity. Works perfectly fine so far.
-
Spin up script not working since update 6.9
So just outputting the same file is not working because of caching, also it should be echo not cat. But, like doron suggested I just ended up with this: #!/bin/bash #disk1 = sdc #disk2 = sde for ((N=1; N<20; N++)) do dd if=/dev/sdc of=/dev/null skip=$(($RANDOM % 1024*1024)) bs=$((1024 + $RANDOM % 2048)) count=$((N*10)) &> /dev/null dd if=/dev/sde of=/dev/null skip=$(($RANDOM % 1024*1024)) bs=$((1024 + $RANDOM % 2048)) count=$((N*10)) &> /dev/null done So a few relatively random reads, a first try with smaller/fewer block didn't work because of caching and I hadn't thought of dropping the cache. Unsure if I want to with the Folder Caching plugin, let's see how that goes
-
Spin up script not working since update 6.9
My script now looks like this: #!/bin/bash cat /mnt/user/<share>/<file>; With 1 line per disk, that just outputs the file to the console, or in that case the log. So same as before, script as cronjob for the time that you want them to keep spinning, spindown settings for the rest of the time. Yeah, that remains to be seen, my script will start soon and I'll report back if it kept working through the evening. Still this is a clunky workaround, there has got to be something lke the old version with 'sdspin'
-
Spin up script not working since update 6.9
For now I just 'cat' a small txt file for each disk, that wakes the disks up and refreshes the status, I'm hoping this keeps them spinning since there is no read caching that I'm aware of. Use case is, like coblck said, keeping the disks spun during a certain time of day while having relatively strict spindown settings at other times. For me it is too noisy while I'm working (and rarely accessing anything), and then in the evening and on the weekends I just want to keep them spinning since I'm not in the room aynway, to reduce spinup/spindown cycles.
-
Spin up script not working since update 6.9
And it's not working anymore in 6.9.1, well sort of. It works but not only doesn't get the status reported with 'smartctl -A', the disk log even shows spinning down despite the script keeping them running. Any ideas anyone?
-
Spin up script not working since update 6.9
According to their spindown schedule, yes.
-
Spin up script not working since update 6.9
replace it and add the two lines per drive, that's what I'm using to keep two drives spinning: #!/bin/bash /usr/local/sbin/sdspin /dev/sdc up; /usr/local/sbin/sdspin /dev/sde up; /usr/sbin/smartctl -A /dev/sdc; /usr/sbin/smartctl -A /dev/sde;
MightyT
Members
-
Joined