File Activity Plugin - How can I figure out what keeps spinning up my disks?


dlandon

206 posts in this topic Last Reply

Recommended Posts

I am trying to solve a maddening disk spin up issue and I keep getting pointed to this. I installed it and it seems to run with no errors but it never sees any file activity. I ran mover to copy some files over in both directions and I still never see anything in the file activity page. I know I am setting something up wrong but I cannot figure out what. Eventually file activity stops and I get the inotify upper limit reached error so I get that part but I should see something prior to that correct? I have attached my diagnostics. 

 

Thanks

tower-diagnostics-20200923-1947.zip

Link to post
  • Replies 205
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

This is a plugin that shows the file and directory activity on the array by disk.  This includes read and write activity on the array.  Read activity can cause disk spin ups.  It is recommended that y

Ok, i was going through my syslog, and found it by accident.   So if anyone else wants to write this to share for any reason, you can use this very basic script: (via custom scripts daily or

There is no correct value.  Just set it to whatever works.  Try to double it to start.

Posted Images

11 minutes ago, trurl said:

Your appdata has files on the array.

yeah, it was just a bunch of empty folders and a random image or two that I never got around to deleting. I did that but the server is still refusing to keep drives spun down and the activity light is still going nuts. But at least this showed some of the activity I did so I guess I don't need any support for this plugin lol. Thanks!

Link to post
  • 4 weeks later...
On 9/19/2020 at 1:26 PM, icemansid said:

/var/log/file.activity.log

wow, great. thanks!

I want to copy the file daily.

Is there a command in can run, to reset this log every day after a copied it?

so a copy a file.activity_DATE.log file, and after that, reset the file with a command

Link to post
On 10/22/2020 at 9:42 AM, LSL1337 said:

wow, great. thanks!

I want to copy the file daily.

Is there a command in can run, to reset this log every day after a copied it?

so a copy a file.activity_DATE.log file, and after that, reset the file with a command

 

 

Ok, i was going through my syslog, and found it by accident.

 

So if anyone else wants to write this to share for any reason, you can use this very basic script: (via custom scripts daily or whatever)

 

##copy to user share
cp /var/log/file.activity.log /mnt/user/backup/logs/FA/$(date +"%Y-%m-%d__%H-%M")__File_Activity.log
##clear the log
/usr/local/emhttp/plugins/file.activity/scripts/rc.file.activity 'clear' 

## remove logs older than 180 days
find /mnt/user/backup/logs/FA/ -name '*.log' -type f -mtime +180 -exec rm -f {} \; 

 

Edited by LSL1337
Link to post
  • 2 weeks later...

I am re-evaluating my development efforts with Unraid and need to cut back on some plugins that are not providing core functionality in Unraid.  This plugin will be deprecated starting with Unraid 6.9.  This plugin does not provide enough of an enhancement to the Unraid OS and I don't have the time to continue development efforts.  If it's deemed to be a necessary part of Unraid, LT should include the functionality.

Link to post
2 hours ago, dlandon said:

I am re-evaluating my development efforts with Unraid and need to cut back on some plugins that are not providing core functionality in Unraid.  This plugin will be deprecated starting with Unraid 6.9.  This plugin does not provide enough of an enhancement to the Unraid OS and I don't have the time to continue development efforts.  If it's deemed to be a necessary part of Unraid, LT should include the functionality.

does it work in it's current form on 6.9?

Link to post

I've been debugging for hours now. It very much looks like the disk spin up is caused by docker. Disabling docker completely seems to solve the issue. Now the question is if it is docker itself or some container. The weird thing is that even if I start some containers, see the problem, then stop all containers, the problem does not go away. However, if I disable and then enable docker without starting any containers, the problem is not there.

 

Anyway, I do suspect one particular container: Minio. With that container started, I cannot get the array to spin down even though there should be no activity. But as mentioned above, it's quite confusing what's causing the problem. I'm still on a trial version so I have experimented a lot. That also makes it difficult to figure out what changes cause the issue.

Link to post
57 minutes ago, pervel said:

disk spin up is caused by docker

That was my first suspicion, but I checked your appdata, system shares are all on cache, and docker.img is in system share.

 

1 hour ago, pervel said:

I do suspect one particular container: Minio. With that container started, I cannot get the array to spin down

If docker is enabled but that container is NOT started, does it spin down?

 

Post your docker run for that container as explained at this very first link in Docker FAQ:

 

Link to post
8 minutes ago, trurl said:

If docker is enabled but that container is NOT started, does it spin down?

Yes, it seems so. But I have to wait a few minutes after stopping it before spin down will work.

 

9 minutes ago, trurl said:

Post your docker run for that container as explained at this very first link in Docker FAQ:

This is the run command (secret key replaced with stars):

root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='Minio' --net='bridge' -e TZ="Europe/Paris" -e HOST_OS="Unraid" -e 'MINIO_ACCESS_KEY'='minio' -e 'MINIO_SECRET_KEY'='*********' -p '9768:9000/tcp' -v '/mnt/user/minio/':'/data':'rw' -v '/mnt/user/appdata/minio':'/root/.minio':'rw' 'minio/minio' server /data
687af9711f4163ed72f99c5c5f8357d385f40b0a5edbb693a52dfe4c3a53ea84

I do wonder if maybe the answer is just to never spin down the disks. That seems to be what some people recommend anyway.

Link to post
  • 1 month later...
On 11/14/2020 at 10:42 AM, LSL1337 said:

does it work in it's current form on 6.9?

The only incompatibility I can see is it can't track activity on alternate pools. I thought enabling cache might pick it up but no. Otherwise, works just as in 6.8.3.

Link to post
23 minutes ago, CS01-HS said:

The only incompatibility I can see is it can't track activity on alternate pools. I thought enabling cache might pick it up but no. Otherwise, works just as in 6.8.3.

Correct, it only works currently on cache.  It will need to be upgraded and I'll have a look at that.

Link to post

My File Activity plugin on 6.9-beta25 has just recently stopped working, though I'm not sure it's *entirely* File Activity's fault.  When I try to start File Activity, it fails with the following error:

inotifywait[9438]: Couldn't watch /mnt/disk2: No such file or directory

Which is fairly unsurprising because I don't *have* a disk2 so I'm not expecting a /mnt/disk2.  However /usr/local/emhttpd/state/disks.ini does contain this entry:

["disk2"]
idx="2"
name="disk2"
device=""
id=""
size="0"
status="DISK_NP"
rotational=""
format="-"
temp="*"
numReads="0"
numWrites="0"
numErrors="0"
type="Data"
color="grey-off"
spindownDelay="-1"
spinupGroup=""
smType=""
deviceSb=""
idSb=""
sizeSb="0"
luksState="0"
comment=""
floor="0"
exportable="no"
fsType="auto"
fsStatus="-"
fsColor="grey-off"
fsSize="0"
fsFree="0"

 

It's not totally clear to me yet where this entry came from (or how to make it go away), but if this is expected Unraid behavior, File Activity should maybe ignore (or gracefully fail to watch) disks in this state.

Would love any pointers anyone has on how to get rid of this weird phantom disk, or why it's here in the first place :P

Link to post
1 hour ago, Sammy1Am said:

My File Activity plugin on 6.9-beta25 has just recently stopped working, though I'm not sure it's *entirely* File Activity's fault.  When I try to start File Activity, it fails with the following error:


inotifywait[9438]: Couldn't watch /mnt/disk2: No such file or directory

Which is fairly unsurprising because I don't *have* a disk2 so I'm not expecting a /mnt/disk2.  However /usr/local/emhttpd/state/disks.ini does contain this entry:


["disk2"]
idx="2"
name="disk2"
device=""
id=""
size="0"
status="DISK_NP"
rotational=""
format="-"
temp="*"
numReads="0"
numWrites="0"
numErrors="0"
type="Data"
color="grey-off"
spindownDelay="-1"
spinupGroup=""
smType=""
deviceSb=""
idSb=""
sizeSb="0"
luksState="0"
comment=""
floor="0"
exportable="no"
fsType="auto"
fsStatus="-"
fsColor="grey-off"
fsSize="0"
fsFree="0"

 

It's not totally clear to me yet where this entry came from (or how to make it go away), but if this is expected Unraid behavior, File Activity should maybe ignore (or gracefully fail to watch) disks in this state.

Would love any pointers anyone has on how to get rid of this weird phantom disk, or why it's here in the first place :P

It's an unassigned slot in the array.  I've made an update that will ignore a non-existent disk.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.