dikkiedirk: Slow starts and stops, repetitive umounts, cache_dirs? Was:

I updated to 6 beta 10ayesterday and after reboot I noticed a longer time for the shares to show up than on earlier betas. I also many repetitive umount, rmdir and no such file or directory commands in the syslog.

Can someone explain why this happening? Or is it expected, normal behavior?

syslog is attached.

syslog-2014-10-05.zip

I also many repetitive umount, rmdir and no such file or directory commands in the syslog.

 

Can someone explain why this happening? Or is it expected, normal behavior?

These were being repeated as when trying to stop the array something was keeping disk9 active, and on retries the array stop logic does not appear to check whether a particular disk has already been successfully stopped - all disks are tried again.  I guess it would be sensible if the umouny + rmdir for each disk was protected by a test to see if it was necessary as it would keep the syslog tidier..

I updated to 6 beta 10ayesterday and after reboot I noticed a longer time for the shares to show up than on earlier betas. I also many repetitive umount, rmdir and no such file or directory commands in the syslog.

 

Can someone explain why this happening? Or is it expected, normal behavior?

 

syslog is attached.

There is something wrong in a plugin.

I updated to 6 beta 10ayesterday and after reboot I noticed a longer time for the shares to show up than on earlier betas. I also many repetitive umount, rmdir and no such file or directory commands in the syslog.

 

Can someone explain why this happening? Or is it expected, normal behavior?

 

syslog is attached.

 

There is something wrong in a plugin.

Can cache_dirs be the cause?

I am at the moment in the process of moving my disks to XFS format, so I frequently have to stop the array and change the format of a disk to XFS, start the array and format the disk. But stopping the array is a real PITA at the moment because I see the "retry unmounting disk" message far too often, even when nothing is accessing the server. I also see the entire server dropping of the network when stopping the array. I can still access it in putty, but in the Windows browser the server is gone. Do you have a remedy for this?

Can cache_dirs be the cause?

 

 

I am at the moment in the process of moving my disks to XFS format, so I frequently have to stop the array and change the format of a disk to XFS, start the array and format the disk. But stopping the array is a real PITA at the moment because I see the "retry unmounting disk" message far too often, even when nothing is accessing the server. I also see the entire server dropping of the network when stopping the array. I can still access it in putty, but in the Windows browser the server is gone. Do you have a remedy for this?

cache_dirs is the cause of the "retry" message when unmounting disks. It spawns a few "find" background sessions which are accessing the drives on a constant bases and it takes a few seconds for the script to realize that the server is going offline and to self-terminate.

I have recently been getting the following syslog Messages:

 

Oct  5 07:18:19 Tower emhttp: get_filesystem_status: statfs: /mnt/user/UpsStats app data No such file or directory
Oct  5 07:18:19 Tower emhttp: get_filesystem_status: statfs: /mnt/user/domains No such file or directory
Oct  5 07:18:21 Tower emhttp: get_filesystem_status: statfs: /mnt/user/UpsStats app data No such file or directory
Oct  5 07:18:21 Tower emhttp: get_filesystem_status: statfs: /mnt/user/domains No such file or directory
Oct  5 07:18:24 Tower emhttp: get_filesystem_status: statfs: /mnt/user/UpsStats app data No such file or directory
Oct  5 07:18:24 Tower emhttp: get_filesystem_status: statfs: /mnt/user/domains No such file or directory

 

I have experimented with Docker but I am not currently running any containers (Crashplan and Couchpotato containers installed but not running.)  When I installed the CrashPlan and Couchpotato containers, I created cache directories called Couch app data and Crash app data to store configuration data.  I also tried to install the Docker container  UpsBoard which installation hung and I aborted. I believe I also may have created a cache directory for this container's config data (UpsBoard app data) which I subsequently deleted after the aborted installation. 

 

I am running a XEN VM on my cache drive, the VM image is located on my cache drive in a directory called VM.  I recently deleted an old VM image on a cache directory called domains, which directory I also deleted (left over from an earlier installation of a Ubuntu VM posted a while ago in this thread announcing beta 4 on March 28, 2014) I have subsequently rebooted the server.  Any suggestions as to theses error messages?? 

 

syslog is attached.

* The syslog you attached only covers Oct 1 and Oct 2, and the lines in the syslog extract above are not in it, so my comments only apply to the attached syslog.

* Disk 1 has Reiser file system corruption, which caused it to be changed to Read Only.  This appears to have caused /mnt/user0 to be changed to Read Only too, and is the cause for most of the errors logged.  See Check Disk File systems.

* UnMENU crashed on load, and was then restarted.  Unknown as to why, but possibly an older version?  Check for update of UnMENU.  If this doesn't fix, then request support in UnMENU thread.

* Please update Powerdown to the latest.

I updated to 6 beta 10ayesterday and after reboot I noticed a longer time for the shares to show up than on earlier betas. I also many repetitive umount, rmdir and no such file or directory commands in the syslog.

 

Can someone explain why this happening? Or is it expected, normal behavior?

 

syslog is attached.

There are 2 array starts, and they seem normal to me, with 18 drives, lots of User Shares, and a few plugins.  There is only one array stop, so a little hard to draw conclusions, but the only delay with it was something keeping Disk 9 busy for an additional minute and a half, didn't see any other issues.  There are no clues as to what is keeping Disk 9 busy, but could be the CacheDirs mentioned by others, but I would expect that the other slow stoppages you have seen would show random drives keeping it busy, not just Disk 9.  Is it always Disk 9?  If so, then you have something using Disk 9 that is slow to give it up.  The only way it would always be CacheDirs and Disk 9 is if you have a *huge* number of files and folders on Disk 9, in which case you should probably limit the depth of caching (you currently have it set to unlimited).  A depth of 4 is satisfactory for many users.

These were being repeated as when trying to stop the array something was keeping disk9 active, and on retries the array stop logic does not appear to check whether a particular disk has already been successfully stopped - all disks are tried again.  I guess it would be sensible if the umount + rmdir for each disk was protected by a test to see if it was necessary as it would keep the syslog tidier..

Yes, please please!

I updated to 6 beta 10ayesterday and after reboot I noticed a longer time for the shares to show up than on earlier betas. I also many repetitive umount, rmdir and no such file or directory commands in the syslog.

 

Can someone explain why this happening? Or is it expected, normal behavior?

 

syslog is attached.

There are 2 array starts, and they seem normal to me, with 18 drives, lots of User Shares, and a few plugins.  There is only one array stop, so a little hard to draw conclusions, but the only delay with it was something keeping Disk 9 busy for an additional minute and a half, didn't see any other issues.  There are no clues as to what is keeping Disk 9 busy, but could be the CacheDirs mentioned by others, but I would expect that the other slow stoppages you have seen would show random drives keeping it busy, not just Disk 9.  Is it always Disk 9?  If so, then you have something using Disk 9 that is slow to give it up.  The only way it would always be CacheDirs and Disk 9 is if you have a *huge* number of files and folders on Disk 9, in which case you should probably limit the depth of caching (you currently have it set to unlimited).  A depth of 4 is satisfactory for many users.

 

These were being repeated as when trying to stop the array something was keeping disk9 active, and on retries the array stop logic does not appear to check whether a particular disk has already been successfully stopped - all disks are tried again.  I guess it would be sensible if the umount + rmdir for each disk was protected by a test to see if it was necessary as it would keep the syslog tidier..

Yes, please please!

Thanks for your remarks. What do you consider lots of user shares?

I quit cache_dirs for the moment. See how it behaves now. Currently copying data to a XFS disk. Takes some time till the next array stop.

Thanks for your remarks. What do you consider lots of user shares?

I cannot see your Share settings, but it looks like there are 3 shares fully configured, Media, Movies2, and videos.  However, CacheDirs is seeing a lot more (I believe UnRAID sees them as unconfigured shares):

Oct  4 22:29:50 Tower1 cache_dirs: ============================================== initial array start

Oct  4 22:29:50 Tower1 cache_dirs: command-args=-w

Oct  4 22:29:50 Tower1 cache_dirs: vfs_cache_pressure=10

Oct  4 22:29:50 Tower1 cache_dirs: max_seconds=10, min_seconds=1

Oct  4 22:29:50 Tower1 cache_dirs: max_depth=9999

Oct  4 22:29:50 Tower1 cache_dirs: command=find -noleaf

Oct  4 22:29:50 Tower1 cache_dirs: version=1.6.9

Oct  4 22:29:50 Tower1 cache_dirs: ---------- caching directories ---------------

Oct  4 22:29:50 Tower1 cache_dirs: BitTorrent

Oct  4 22:29:50 Tower1 cache_dirs: Epub op achternaam 6465 nederlandse EPUB boeken (zelfde als starterskit)

Oct  4 22:29:50 Tower1 cache_dirs: Epub op achternaam nederlands december 315 boeken (zelfde als starterskit)

Oct  4 22:29:50 Tower1 cache_dirs: Laptop backup

Oct  4 22:29:50 Tower1 cache_dirs: Media

Oct  4 22:29:50 Tower1 cache_dirs: Movies2

Oct  4 22:29:50 Tower1 cache_dirs: Music

Oct  4 22:29:50 Tower1 cache_dirs: downloads

Oct  4 22:29:50 Tower1 cache_dirs: newsleecher

Oct  4 22:29:50 Tower1 cache_dirs: nzb

Oct  4 22:29:50 Tower1 cache_dirs: nzbget

Oct  4 22:29:50 Tower1 cache_dirs: qnap

Oct  4 22:29:50 Tower1 cache_dirs: qnapesata

Oct  4 22:29:50 Tower1 cache_dirs: videos

Oct  4 22:29:50 Tower1 cache_dirs: ----------------------------------------------

Oct  4 22:36:00 Tower1 cache_dirs: ==============================================  second array start

Oct  4 22:36:00 Tower1 cache_dirs: command-args=-w -m 1 -M 10 -d 9999 -p 10 -U 50000 -B -a -noleaf

Oct  4 22:36:00 Tower1 cache_dirs: vfs_cache_pressure=10

Oct  4 22:36:00 Tower1 cache_dirs: max_seconds=10, min_seconds=1

Oct  4 22:36:00 Tower1 cache_dirs: max_depth=9999

Oct  4 22:36:00 Tower1 cache_dirs: command=find -noleaf

Oct  4 22:36:00 Tower1 cache_dirs: version=1.6.9

Oct  4 22:36:00 Tower1 cache_dirs: ---------- caching directories ---------------

Oct  4 22:36:00 Tower1 cache_dirs: .apps

Oct  4 22:36:00 Tower1 cache_dirs: .minidlna

Oct  4 22:36:00 Tower1 cache_dirs: .nzbget

Oct  4 22:36:00 Tower1 cache_dirs: .sabnzb

Oct  4 22:36:00 Tower1 cache_dirs: .sickbeard

Oct  4 22:36:00 Tower1 cache_dirs: BitTorrent

Oct  4 22:36:00 Tower1 cache_dirs: Epub op achternaam 6465 nederlandse EPUB boeken (zelfde als starterskit)

Oct  4 22:36:00 Tower1 cache_dirs: Epub op achternaam nederlands december 315 boeken (zelfde als starterskit)

Oct  4 22:36:00 Tower1 cache_dirs: Laptop backup

Oct  4 22:36:00 Tower1 cache_dirs: Media

Oct  4 22:36:00 Tower1 cache_dirs: Movies2

Oct  4 22:36:00 Tower1 cache_dirs: Music

Oct  4 22:36:00 Tower1 cache_dirs: apps

Oct  4 22:36:00 Tower1 cache_dirs: docker

Oct  4 22:36:00 Tower1 cache_dirs: downloads

Oct  4 22:36:00 Tower1 cache_dirs: newsleecher

Oct  4 22:36:00 Tower1 cache_dirs: nzb

Oct  4 22:36:00 Tower1 cache_dirs: nzbget

Oct  4 22:36:00 Tower1 cache_dirs: qnap

Oct  4 22:36:00 Tower1 cache_dirs: qnapesata

Oct  4 22:36:00 Tower1 cache_dirs: videos

Oct  4 22:36:00 Tower1 cache_dirs: webvirtmgr

Oct  4 22:36:00 Tower1 cache_dirs: ----------------------------------------------

I suspect you haven't configured CacheDirs yet.  Use the CacheDirs -i parameter to include only those folders you want cached, otherwise it caches everything.  See Caching Directories intro and CacheDirs instructions.

Since this is normal support and off-topic for the announcement thread, shortly I'm going to move all of this to the General Support board for v6.

True, I just started cache_dirs with cache_dirs -w in the go script. Don't use the plugin just yet.

Might try it as it seems to make configuring cache_dirs easier. And booting unraid in safe mode disables it.

Disabling it in the go script and rebooting the server works great and makes stopping the array a matter of seconds. I leave it disabled for now while I am in the process of converting my disks to XFS.