Squid

This would do but I'm getting: rm: cannot remove '/tmp/user.scripts/tmpScripts/scrub_status_disks/log.txt': No such file or directory Not sure. It worked for me. But on a re-read of your post, its not going to do what you want anyways. I think you want to keep the log window open and have it continually update those lines. For that, you're going to have to make this html and php. Let me get back to you on that one. Good little experiment if nothing else....

You can hit the garbage can on the UI. Or for something more automated, within the script add rm /tmp/user.scripts/tmpScripts/nameOfScriptFolderOnFlashDrive/log.txt

Personally, I would get rid of the redirect to /boot/logs/scrub_cache.log. That way user scripts can display the logs. But, the output is not persistent and will be lost over reboots.

If you don't use slave mode on those mappings then the app might not be able to consistently access the data within those paths. Edit the app and on those mappings edit them and select read write slave for the mode Sent from my SM-T560NU using Tapatalk

With the extra RAM things will speed up. If the extra was 1600MHz it would speed up a hair more, but doubtful you'd really notice it unless you're trying to get 1 extra frame per second or 10 more points on a passmark

The motherboard will adjust the speed when it accesses the other sticks. But, decent motherboard manuals recommend that the same CAS timings be used on all sticks present.

Not quite following. How did you run the extended test. What log are you talking about? If its the syslog, and it crashes the system trying to display it, then run diagnostics and open the syslog from the zip file

You've got the port ranges listed twice in the run command. (Along with the volume mappings)

Thank you for the clarification, will unRAID properly detect the file system as getting full and switch over to the array or will it get confused because of the wrong size reported? Thanks. TBH, I think that it'll get messed up on the free space available. But easy work around is to set the minimum cache free space to a value that'll ensure it never attempts writes to cache enabled shares if the drives are actually full

Its not. btrfs itself reports an incorrect size. Known bug in btrfs. You only have 250GB of space available.

If you don't redirect the output, user scripts will be able to display the output from the script (ie: log) with a simple button press Search for "scripts/notify" for examples of using the notifications. There are lots. /usr/local/emhttp/plugins/dynamix/scripts/notify will bring up all the options available.

I'm as guilty as a lot of other plugin guys here. Functionality first. Help files whenever we get around to it. (truth be told I never even thought about it) After work it'll get done.

Would that still be needed for an unmounted disk? Missed in the thread where you were umounting it first. My bad...

That's something I'd like to know too. I suppose since this is Linux, you are expected to unmount the file system yourself, before detaching. And probably Linux GUI's (KDE, etc) provide a button or function that will execute the appropriate unmounts, comparable to 'safely remove'. Some googling and found this command: echo 1 > /sys/block/sdX/device/delete You can hear the disk spinning down and the log is cleaner: Jan 13 15:29:52 Tower8 kernel: sd 6:0:0:0: [sde] Synchronizing SCSI cache Jan 13 15:29:52 Tower8 kernel: sd 6:0:0:0: [sde] Stopping disk Jan 13 15:29:52 Tower8 kernel: ata6.00: disabled Should you do a sync prior to ensure everything is all written just for safety sake?

flexibility > user-friendliness Damn near impossible to create a GUI that could possibly encompass all of the options that cron has.

The reason for the seemingly quick rescan time is so that it won't have to spin up the drives. Cache-dirs attempts to keep the directory structures in memory by rescanning all the time. (Linux if the directory structure isn't used in a while will automatically drop it from memory) However, there are times where Cache Dirs will be unable to keep the entries in memory, and under those circumstances a spin up will happen (but it shouldn't happen again until those circumstances repeat themselves)

- Ability to set schedules to any arbitrary custom cron schedule. If you don't know what cron is, see here: https://en.wikipedia.org/wiki/Cron You can enter in any cron expression for the utmost in flexibility. Only enter in the expression. The command to run will automatically be added. As usual, the same flexibility in scripts apply. Namely, any interpreter is allowed. If no interpreter is specified, /bin/bash is assumed, EOL can be either Linux or Windows style.

Install Community Applications (link in sig) instead. Better way of doing things. But, you can find the repository URL to handle things the old-fashioned way here: http://lime-technology.com/forum/index.php?topic=37958.0

Testing the code tonight. So release is tonight / tomorrow. But it's a raw cron entry. No dropdowns, etc when set to custom so you have the utmost flexibility.

again?!?

Try setting static DNS addresses. We've never seen that particular error here before, but its similar to other issues that were fixed by setting static DNS in Settings - Network

Probably a rescan in FCP would have done it. Without a rescan, the same issues are still displayed until the next scheduled scan

hmm One of my machines runs that and I don't have any issues with that test. I'll check it out after work

What unRaid version? I'd have to check if there's an issue....

Either that or you can use the user scripts plugin Sent from my LG-D852 using Tapatalk