See I/O requests sent to the device I/O drivers [SOLVED]

[Juanzilla]

Hello, Im new with Unraid but not so new on the linux world. Also im from Latino America so, I want to apologize for my grammar in advance.

Back to the point.

As I say before, Im new with Unraid. Im testing it on my main hardware. The thing is that, I have 4 HDDs (1 for partity and 3 for storage). Because Im not using the server all the time I set up a spin down after 30 minutes. After some days I notice that for some reason, all the drives spin down except for the hdd2 and the parirty drive. After restart the statistics and spin down manually i could see that the read and write of this two hdds start to increace.

 

I unistall almost all of the plugins and use the cli to launch the IOSTAT command (included in the nerdpack plugin) but I can not see who is doing this I/O requests to this hdds devices.

 

How can I find the services or process that is making this I/O requests?

 

update1:

 

This is what Im seeinng:

 

 

Thanks in advance!

Juanzilla

Edited April 30, 2019 by Juanzilla

[JonathanM]

If you have the docker service enabled, whichever drive has the docker image and the parity drive will stay active.

[Juanzilla]

All my dockers and VMs are in the cache drive.

 

Maybe the question is wrong. Maybe what I need to ask is "how can I know what event its spinning up my drives?".

 

Anyone can help me?

 

Again, Thanks in advance.

Edited April 30, 2019 by Juanzilla

[JonathanM]

1 hour ago, Juanzilla said:

All my dockers and VMs are in the cache drive.

Your screenshot and description didn't say anything about a cache drive, and you didn't post diagnostics, so I had no information to go on.

[Juanzilla]

You are right. I let that info out because I did not think that was relevant. The original question was about I/O querys.

But you are right. Sorry for that. I attached the files this time:

tower-diagnostics-20190429-2209.zip

 

again, thanks for your time and patience.

 

BTW, I spin down the drives and clean the statistics for this screenshot (the original screenshot shows what I really want to show). This is just for show the chache drive.

Edited April 30, 2019 by Juanzilla

[Juanzilla]

Ok, I did some troubleshooting here. I turn on and off my dockers separately and apparently its the Nextcloud docker. I do not know why the docker do this. It's using the storage disk even if I specifically configure a share that uses the cache drive and the schedule process its setup at 3am only.   

 

any ideas?

[Juanzilla]

Ok.... after hours of fighting this thing I finally solve de issue.

 

basically the solutions was to remove the Nextcloud docker. Erase every last one of the app files using the cli. Erase the share folder also using the CLI.

 

Create a new share forcing it to use the SSd/Cache. Re-install nextcloud and do it all over again.

That solve the issue.

 

Thanks a lot everyone!

 

Juanzilla.

[JonathanM]

7 hours ago, Juanzilla said:

Create a new share forcing it to use the SSd/Cache.

If that share is cache:yes, it's going to happen again. To force data to stay on the cache and NOT move to the array, you want cache:prefer

[Juanzilla]

7 hours ago, jonathanm said:

If that share is cache:yes, it's going to happen again. To force data to stay on the cache and NOT move to the array, you want cache:prefer

Actualy, I selected the "cache:only" option. That way, the docker's files are never gonna move to the storage disk. The dropback to this is that, all the files are not going to be protected by the parity disk. To solve that I scheduled an rsync task to move the files to the /mnt/user0/backup share directory.

 

Again, thanks for your help!

 

Juanzilla.

 

 

[JonathanM]

Cache:Prefer has several advantages over cache:only.

1. If the cache drive ever drops below the free space margin defined in unraids settings, new files will be written to the array instead of failing outright.

2. any files that do exist in that share on the array will be transferred over to the cache by the mover, as long as the files aren't open.

 

Directly accessing /mnt/user0 is not recommended. A couple years ago limetech removed it, as it is no longer needed by the mover code. They put it back in after a number of people complained that they were using it for other functions. Read the section on improved mover in this post.

https://forums.unraid.net/topic/57823-unraid-os-version-640-rc-changes/?do=findComment&comment=566666

Instead of writing to /mnt/user0/backup, it is preferred to write to /mnt/user/backup, and define the backup share with the proper cache function, in your case cache:no.

 

There is no guarantee that /mnt/user0 will function the same in the future.