July 13, 201213 yr I'm not sure if this is intended behaviour or not, but when I've connected to unRAID through AFP, whichever drive I have mounting subsequently refuses to spindown until I unmount the drive from the client machine. I mounted another disk using SMB, and after an hour of idle, it went spun down. So this looks like an AFP issue. Is this intended behaviour, or should I look for processes on my mac that prevent the drive from spinning down? Thanks. --- OK used lsof to see whats holding up the drive. There are a few entries for disk1. All seem to be related to .AppleDB. So it seems that that mac wont let the drive spin down as it's accessing the db file. It seems this file contains metadata related to the current directory. And from the sounds of it this folder has to be there to use AFP. Anyone using Time Machine? If so do your drives spin down?
July 13, 201213 yr Open files don't stop a disk from spinning down. root@Othello:~# lsof /mnt/disk4 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME shfs 13597 root 19u REG 9,4 0 5099 /mnt/disk4/Movies/.AppleDB/lock shfs 13597 root 20w REG 9,4 393 5102 /mnt/disk4/Movies/.AppleDB/db_errlog shfs 13597 root 21w REG 9,4 393 5102 /mnt/disk4/Movies/.AppleDB/db_errlog shfs 13597 root 29u REG 9,4 5046272 5100 /mnt/disk4/Movies/.AppleDB/cnid2.db root@Othello:~# Disk 4 is spun down. Something is actively accessing the disk to keep it spinning. I'll check if my TimeMachine share spins down...
July 13, 201213 yr Author Interesting. Thats what i was getting in lsof. All related to /.AppleDB/ If i unmount the afp drive share, after an hour of idle it spinsdown. Really clueless as to what to do! OK I've waited an hour and heres the result of lsof root@Tower:~# lsof /mnt/disk1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME afpd 9497 nobody cwd DIR 9,1 328 2 /mnt/disk1 cnid_dbd 9502 root cwd DIR 9,1 304 18 /mnt/disk1/.AppleDB cnid_dbd 9502 root mem REG 9,1 49152 27 /mnt/disk1/.AppleDB/__db.006 cnid_dbd 9502 root mem REG 9,1 6971392 26 /mnt/disk1/.AppleDB/__db.005 cnid_dbd 9502 root mem REG 9,1 98304 25 /mnt/disk1/.AppleDB/__db.004 cnid_dbd 9502 root mem REG 9,1 10493952 24 /mnt/disk1/.AppleDB/__db.003 cnid_dbd 9502 root mem REG 9,1 2424832 23 /mnt/disk1/.AppleDB/__db.002 cnid_dbd 9502 root mem REG 9,1 24576 22 /mnt/disk1/.AppleDB/__db.001 cnid_dbd 9502 root 3uR REG 9,1 0 19 /mnt/disk1/.AppleDB/lock cnid_dbd 9502 root 5r DIR 9,1 304 18 /mnt/disk1/.AppleDB cnid_dbd 9502 root 7w REG 9,1 2178 20 /mnt/disk1/.AppleDB/db_errlog cnid_dbd 9502 root 8w REG 9,1 2178 20 /mnt/disk1/.AppleDB/db_errlog cnid_dbd 9502 root 9u REG 9,1 10485760 21 /mnt/disk1/.AppleDB/log.0000000001 cnid_dbd 9502 root 10u REG 9,1 1171456 28 /mnt/disk1/.AppleDB/cnid2.db
July 13, 201213 yr The TimeMachine share spins down as well. Even though files are open: root@rack:~# lsof /mnt/disk1 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME shfs 2071 root 4u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 5u REG 9,1 0 23 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/lock shfs 2071 root 6w REG 9,1 543902 24 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/db_errlog shfs 2071 root 7w REG 9,1 543902 24 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/db_errlog shfs 2071 root 8u REG 9,1 2424832 36642 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/__db.002 shfs 2071 root 9u REG 9,1 24576 36448 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/__db.001 shfs 2071 root 10u REG 9,1 10493952 36643 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/__db.003 shfs 2071 root 11u REG 9,1 98304 325805 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/__db.004 shfs 2071 root 12u REG 9,1 6971392 325806 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/__db.005 shfs 2071 root 13u REG 9,1 49152 644160 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/__db.006 shfs 2071 root 14u REG 9,1 10485760 942237 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/log.0000000041 shfs 2071 root 15u REG 9,1 42500096 36450 /mnt/disk1/DGA-Pro-TMBackups/.AppleDB/cnid2.db shfs 2071 root 16u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 17u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 18u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 19u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 20u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 22u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent shfs 2071 root 23u REG 9,1 741 268591 /mnt/disk1/DGA-Pro-TMBackups/DGA.sparsebundle/bands/.AppleDouble/.Parent root@rack:~# Are you certain there are not applications on the Mac accessing files?
July 13, 201213 yr Author I'm fairly certain. I only have a couple of apps open. None of them use that drive (I used a different drive to just make sure). Disk1 is not in any spanned user shares either. I've checked that spotlight is disabled on this share too. Quite a pickle. I'll have to see if there are any bash commands to see what's using the drive on mac. Lsof on the mac didn't show any listings. Could it have anything to do with my command outputting cnid_dbd whereas yours is shfs? I suppose the only other possibility is that it's snow leopard related.. I'll try in lion
July 13, 201213 yr Check spin-up groups and spin down delays. There is a global delay and specific settings for each disk,
July 13, 201213 yr Author Check spin-up groups and spin down delays. There is a global delay and specific settings for each disk, Spinup groups are set to no, and disk1 spin down delay is set to default like the other drives. Weird as they all spin down when mounted on the same mac using smb.
July 13, 201213 yr Author Ok. I think I'm getting somewhere. Ran The following in my mac sudo lsof | grep '/Volumes/disk1' which told me that mds was using the drive. Checked spotlight status on the drive mdutil '/Volumes/disk1' It confirmed indexing was disabled. But then I went into spotlight preferences and added the mount to spotlights privacy list. Re-ran lsof and the mds process was gone. Now just to wait an hour and see if the drive spins down!! ----- OK it didn't spin down. Had to force spindown from unRAID ui.. I'm out of ideas..
July 13, 201213 yr Author Determined not to give up, I did some subsequent testing. It appears there was an app scanning the share. The applications was Temperature Monitor Lite. This would explain why logging disk usage didnt show anything!
July 14, 201213 yr Determined not to give up, I did some subsequent testing. It appears there was an app scanning the share. The applications was Temperature Monitor Lite. This would explain why logging disk usage didnt show anything! To use "lsof" would require you to catch a file exactly as it was being accessed. A better technique is described here: http://lime-technology.com/forum/index.php?topic=21401.msg190179#msg190179
July 14, 201213 yr Author Wow thats brilliant. Thanks Joe, I'll have another look in the morning and double check it is definitely temperature monitor thats causing my issues. This is one of the friendliest tech forums I've found
July 14, 201213 yr If not, try setting the drive level timeout to a value other than default. I had a cache drive that wouldn't spin down in the past until I did that.
Archived
This topic is now archived and is closed to further replies.