StorageDevices_StatusRadar.sh - logic questions

[jamo]

Hi guys

As a result of my issues with my 2nd media drive in a related thread, I got to looking at the StorageDevices_StatusRadar.sh script and I have a question-

Regarding the use of the CacheSet and CacheGet function. I see that this is used to "remember" the online flag of a storage device, the last time the script polled the devices. This makes sense because it means that the script doesn't have to query the database every time to get this value... it only has to do that the first time the script polls and there is no stored value.

However, where this logic appears to fall down is that the script will often be running on more than one machine on the LMCE network (all mediadirectors and the core) and since the scripts don't share the cached value(s), they can't know if another script has changed the flag or not because they never re-check the database. This is exactly what happened in my case- When the core started the StorageDevices_StatusRadar script, my media drive was (correctly) marked online as a local, mountable drive. The value was cached and as far as the core instance of the script was concerned it stayed that way.

Then when a media director started up, it ran the same script locally, but this time it determined that the media drive was not online because it couldn't access the samba share (another issue) so it marked the device as offline in the database.

So now there was a situation where the two scripts carried on merrily "polling" every few seconds and remembering the status of the same device differently. I'm not even sure which was right in the end because, granted, the samba share wasn't available, but the drive was still accessible-> I could still *play* the videos... I just couldn't see them in the datagrid, so as far as I was concerned it was online.

In summary-

1. "Should" the media director consider the media drive to be offline if it can't access it as a samba share?
2. Does it make sense that the script runs on each machine and "remembers" a flag for the same device that is not shared between them? What are the alternatives?

Any thoughts/ comments?

[JaseP]

I'm confused.

Does the MD create a separate database entry for the drive based on the way it accesses the drive (local versus across the network, in this case a SAMBA share), or is there one instance for each drive in the database, with each machine on the LinuxMCE system (Core or MD) having a vote as to whether it should be used or not?

If it is the latter, does the vote only count as to that device (i.e.: accessible to Core, but not that particular MD, or vice versa? via separate flags), or is it a universal flag that every machine can check and/or set?

I was also under the impression that, with the exception of boot images, all drives were mounted as network drives. I don't know why I think that...

My understanding was that the SAMBA shares were created by the Core to make all media (that the particular user is entitled to) accessible to the (particular) user, regardless of whether it was natively SAMBA, or any other network protocol ("ghosting" or translating the drive, essentially, for the benefit of machines that can only see SAMBA shares across the network). I know that each user can have private media as well as public media, but does that concept also extend to allow/exclude particular MDs from accessing certain drives as well?

[Marie.O]

Every storage device is mounted from every MD.

Example:

** HDD (sdc1) in core device id (220) is mounted**
*on core*

Code: [Select]

mount /dev/sdc1 /mnt/device/220
*on md*

Code: [Select]

mount 192.168.80.1:/mnt/device/220 on /mnt/device/220
** external Samba share (smb://10.1.2.3/junk device id 221 is mounted**
*on core*

Code: [Select]

mount -t cifs //10.1.2.3/junk /mnt/device/221
*on MD (the same way)*

Code: [Select]

mount -t cifs //10.1.2.3/junk /mnt/device/221

[tschak909]

Fantastic catch!

1. yes
2. If we intend to keep this caching mechanism, then we need to propagate this value to other media directors... perhaps this is silly, and it should just be removed...how much does this impact performance, I wonder?

-Thom

[jamo]

1. yes

OK, then, in a sense it is working because there was something that needed to be fixed-> the samba shares. When that was fixed, it all started working again. In fact, thinking through it now, if we did communicate the value across and the samba connection was problematic, then the drive would have been switched online and offline constantly while there was a samba issue - the script on the core would have kept marking it online and then the script on the MD would have been setting it offline when it couldn't access the share.

It seems to me that online/offline in this case means different things depending on your perspective! If you're on the core (or, more significantly hybrid) then the drive is, for all intents and purposes, online. However, if you're on the media director, because you can't access the samba share, it is offline. So online/offline is sort of relative to your context.

2. If we intend to keep this caching mechanism, then we need to propagate this value to other media directors... perhaps this is silly, and it should just be removed...how much does this impact performance, I wonder?

Performance-wise I would imagine it would make a difference.... how much, though, could be tricky to determine.

Ironically, despite the logic seeming flawed, the behaviour is actually doing the right thing at the moment ;-)

I'll give it some more thought, thanks for the feedback.