February 1, 201412 yr Syslog attached. I've had a problem with past few 5.0+ versions where even when all my shares are set to use the cache drive, the parity drive will spin-up. I do not use spinup groups - have it disabled. I stream files to three WDTV SMP boxes over NFS. Windows PCs access over SMB. Linux PCs over NFS/SMB. I did a clean boot - no plugins or packages - nothing. I ran through each disk and share and clicked apply on everything - keeping same settings - use cache drive on all, etc. Spun down all disks and waited. Kids started up a movie on one of the WDTV boxes and all discs associated with the shares on that box spun up since cache_dirs is not running and parity spun up as well, though not at same time. The parity disk spun up about 30 seconds after the data drives. Couple minutes after that the cache drive spun up. Data and cache drive spinning up are fine, why is parity spinning up when all exported shares are set to use the cache drive? I want parity to only spin up when the mover runs at night like it should when using a cache drive and the shares are set to use it. SMB is set to read only on all shares so my kids on the Windows boxes can't delete anything accidentally. NFS is read/write since the WDTV saves files such as when you stop a movie it will allow you to restart where it left off and is also how I transfer DVD/BR rips to the server. No passwords for SMB/NFS. Thanks for any help. syslog_Jan31.txt
February 1, 201412 yr So where do the WDTV's write these files to via NFS? If it is writing to the protected array, that's why parity is spinning up. EDIT: Duh, if cache is enabled it should be writing to the cache share. Are the WDTV's mapped to the user share or to a disk share? If they are mapped to a disk share that would obviously bypass the cache drive. EDIT2: Appears everything is mounted to user shares per the syslog. Sorry, I got nuthin' on this one.
February 1, 201412 yr Author lol, it's a good one. New update, syslog attached. Parity and a couple data drives spun down since they were not used by the first WDTV. Parity spun back up when a second WDTV player went active over NFS. Looks like NFS is not playing nice on these 5.0+ versions and is not following the parity/cache rules. syslog_Jan31-2.txt
February 1, 201412 yr The following lines from your first syslog repeat over and over and over and over... Jan 31 18:10:16 Tower emhttp: shcmd (63): :>/etc/samba/smb-shares.conf Jan 31 18:10:16 Tower emhttp: shcmd (64): cp /etc/exports- /etc/exports Jan 31 18:10:16 Tower avahi-daemon[1298]: Files changed, reloading. Jan 31 18:10:16 Tower emhttp: shcmd (65): echo '"/mnt/user/Backups" -async,no_subtree_check,fsid=106 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (66): echo '"/mnt/user/Kids_TV_Shows" -async,no_subtree_check,fsid=104 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (67): echo '"/mnt/user/Movies" -async,no_subtree_check,fsid=100 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (68): echo '"/mnt/user/Music" -async,no_subtree_check,fsid=102 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (69): echo '"/mnt/user/Pictures" -async,no_subtree_check,fsid=109 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (70): echo '"/mnt/user/Pictures_Inbound" -async,no_subtree_check,fsid=110 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (71): echo '"/mnt/user/TV_Shows" -async,no_subtree_check,fsid=101 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (72): echo '"/mnt/user/Video" -async,no_subtree_check,fsid=108 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (73): echo '"/mnt/user/Video_Inbound" -async,no_subtree_check,fsid=107 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: shcmd (74): echo '"/mnt/user/YouTube" -async,no_subtree_check,fsid=103 *(rw,insecure,anongid=100,anonuid=99,all_squash)' >>/etc/exports Jan 31 18:10:16 Tower emhttp: Restart SMB... Jan 31 18:10:16 Tower emhttp: shcmd (75): killall -HUP smbd Jan 31 18:10:16 Tower emhttp: shcmd (76): cp /etc/avahi/services/smb.service- /etc/avahi/services/smb.service Jan 31 18:10:16 Tower avahi-daemon[1298]: Files changed, reloading. Jan 31 18:10:16 Tower avahi-daemon[1298]: Service group file /services/smb.service changed, reloading. Jan 31 18:10:16 Tower emhttp: shcmd (77): ps axc | grep -q rpc.mountd Jan 31 18:10:16 Tower emhttp: Restart NFS... Jan 31 18:10:16 Tower emhttp: shcmd (78): exportfs -ra |& logger Jan 31 18:10:16 Tower emhttp: shcmd (79): /usr/local/sbin/emhttp_event svcs_restarted Jan 31 18:10:16 Tower emhttp_event: svcs_restarted Jan 31 18:10:17 Tower avahi-daemon[1298]: Service "Tower" (/services/smb.service) successfully established. I don't know why...but that can't be right...this is some sort of unending loop...
February 1, 201412 yr Author The following lines from your first syslog repeat over and over and over and over... <snip> I don't know why...but that can't be right...this is some sort of unending loop... That was where I went from disk to disk and share to share and clicked apply to all existing settings. I had read elsewhere here that when updating versions there was a case where one needed to do that even though nothing changed.
February 1, 201412 yr Only new files go to the cache drive. Editing existing files is done on the array.
February 1, 201412 yr Author Only new files go to the cache drive. Editing existing files is done on the array. Interesting thought. Was not aware of that fact with new vs updating files and parity/cache. I will disable the media library onthe WDTV (only one has it turned on so all three together don't corrupt it) and see what that does. It updates a folder in the root of each share with its sqlite database files.
February 1, 201412 yr Only new files go to the cache drive. Editing existing files is done on the array. Was unaware of that, but it totally explains the behavior seen here.
February 1, 201412 yr Author That did the trick - disabled the media library in the WDTV SMP device. Thanks guys.
Archived
This topic is now archived and is closed to further replies.