Tons of spindown messages

I'm running RC-5.  I've been having problems with disk spindown on my server.  Basically, it has never worked with unRAID 5.  I have 8 data drives...here's the breakdown

Disk 1 - Single disk share, has data, spindown problems

Disk 2 - 1 of 2 disk share, has data, spindown problems

Disk 3 - 2 of 2 disk share, no data, spins down as expected

Disk 4 - 1 of 2 disk share, has data, spindown problems

Disk 5 - 2 of 2 disk share, no data, spins down as expected

Disk 6 - Single disk share, no data, spindown problems

Disk 7 - Single disk share, no data, spindown problems

Disk 8 - Not part of share, no data, spins down as expected

I do not have SMB enabled.  I use AFP.  I have a dedicated Mac Mini server (running Lion Server) and several networked Macs.  Spotlight indexing of the unRAID server shares is turned off on all Macs.  I'm running a few add-ons, such apcupsd, unMenu, and mail, but nothing that should be accessing disks or shares. 

The drives are connected to both the motherboard and through sas cards - no correlation there.

All drives are set to default spindown (which is 15 minutes).

Syslog attached....

Thanks,

Phil

Update: Changed icon to defect report

syslog-2012-07-15.pdf

Really?  No one else is having this problem?  Drives not spinning down when they should?...

I'm. So. Ronereeeeeeee.

Phil

Really?  No one else is having this problem?  Drives not spinning down when they should?...

 

I'm. So. Ronereeeeeeee.

 

Phil

http://lime-technology.com/forum/index.php?topic=21401.msg190179#msg190179

Joe L.

I ran the inotify tool and it found a whole bunch of AppleDouble and AppleDB writes to the drives.  Unfortunately I have no clue what that means or how to stop it.  The output is attached, if anyone can take a stab.

Big thanks to Joe L. for pointing out the utility.  Great stuff.

inotifyoutput.txt

Here's what I think I have figured out.  When Mac OS X connects to a network server via AFP, it assumes the server handles the resource fork metadata.  Netatalk (prior to 3.0) is the culprit for writing the metadata.  Netatalk 3.0 (released 9 July) handles these differently.

Here's what I don't get: why would Netatalk be writing resource fork stuff while the files are not being accessed?  It's like some kind of maintenance drill or something.

Hopefully Limetech can upgrade us to Netatalk 3.0 in the near future.

I ran the inotify tool and it found a whole bunch of AppleDouble and AppleDB writes to the drives.  Unfortunately I have no clue what that means or how to stop it.  The output is attached, if anyone can take a stab.

 

Big thanks to Joe L. for pointing out the utility.  Great stuff.

It is easy to see why your disk is not spinning down.

Joe L.

hey guys,

i now have the exact same behaviour on my disk2.

this wasnt there, when the server was fresh set up. now the server is filled and from my 2 disks (includes one parity) only disk1 is spinning down.

is there any hope to get a fix for that on 5.0rc8a?

thanks in advance for any advice.

Edit:

it looks like it was cache_dir. the default SimpleFeatueres Settings of 9999 of level depth is to high. any suggestion how to set it up right?

Abandon hope, all ye who enter here...I'm running RC8a and I still get the same thing.  Drives are spinning up on their own every twenty minutes or so, prompted by (I think) Netatalk.  The spindowns are just unRAID doing its job.  Hoping Netatalk gets updated to 3.0 in the final, and that it will finally fix the problem.  It really sucks because it heats up the drives, increases energy consumption and wears them faster than they might otherwise.  Oh well...

do you have cache_dir running?

i have and it looks like it was cache_dir. the default SimpleFeatueres Settings of 9999 of level depth is to high. any suggestion how to set it up right? i only have 2GB of ram.

i disabled cache_dir and "inotifywait -mr /mnt/disk2" stopped. now i have to do a working setting for cache_dir

I don't have a cache drive at all...so dunno if cache_dir is running - I assume it isn't.  I don't run SimpleFeatures either.

is has nothing to do with a cache drive. its a plugin either stand alone or for simplefeatures.

http://lime-technology.com/wiki/index.php/Improving_unRAID_Performance#Keep_directory_entries_cached

pretty handy but i will cut the depth size to 10 or something, not 9999

Joe L. could you please give us some advice? how long is cache_dir working to get a depth level of 5 done on a 2.6TB drive?

Abandon hope, all ye who enter here...I'm running RC8a and I still get the same thing.  Drives are spinning up on their own every twenty minutes or so, prompted by (I think) Netatalk.  The spindowns are just unRAID doing its job.  Hoping Netatalk gets updated to 3.0 in the final, and that it will finally fix the problem.  It really sucks because it heats up the drives, increases energy consumption and wears them faster than they might otherwise.  Oh well...

Phil,

I came to the same conclusion as you, that AFP related processes (netatalk) were keeping my drives spinning by doing some type of "housekeeping" in the .AppleDB folder. For example, even after disconnecting the AFP shares on my Mac, and turning the Mac off completely, the unraid server (netatalk) would regularly write updates to files within the .AppleDB folder on those shares preventing the disk from spinning down. This is even though nothing was connected to those shares at the time!

As an experiment, I moved the CNID database that netatalk uses to another drive (outside the array), using suggestions I found in another thread on this site. This allowed the array drives to spin down because now all those housekeeping writes were happening to the non-array drive. Ultimately, I abandoned the idea as I started having some weird application behaviour when accessing AFP shares and also I didn't feel comfortable having the database on an unprotected drive.

Not finding a satisfactory solution, I stopped using AFP, and went to NFS which works well for my purposes provided I stick to disk shares and not user shares (which I have witnessed acting unreliably). Fortunately, for my use, the disk shares is okay, but I can appreciate it wouldn't work for everyone. I also experimented with SMB but found poor performance with my Mac mini setup (example: with NFS reads I get about twice the speed that SMB gives me - perhaps a different Mac would fare better)

If a newer version of netatalk can fix this issue, that would be welcome.

By the way, I don't use a cache drive, or cache_dir either as suggested by the other post, nor could I find anything else that might be keeping the drives active (I used inotifywait to verify). Of course I'm open to suggestions, but for now, i have a workable solution with NFS.