Slightly altered StorageDevices_Radar.sh Need testers, thanks.

[l3mce]

So... currently we have to mount the drive momentarily to extract its size. I figured out a trick to get around that, and as always... I need testers. This change will not break anything, and is less invasive than the current method. If it didn't work, it would simply not report the size, or not report it correctly.

That is another thing. I am reporting ACTUAL size... so do not be confused if your 2TB drive shows up as 1.82 TB... for example.

Just backup your current /usr/pluto/bin/StorageDevices_Radar.sh, and replace it with this
http://svn.linuxmce.org/trac.cgi/export/26267/people/l3mce/StorageDevices_Radar.sh

Then either plug in some drives, or remove known drives from your system and let it detect them.

This should work for physical devices you attach to the system (hard drives, usb drives, sd drives, software raids etc), not network devices.
Thank you in advance.
 

[Armor Gnome]

Worked fine for me this morning.  I tested it using a small 8G thumb, and a WD Passport 500G.  On the Passport it detected it as two 250G drives because I have it petitioned for use as backup image storage.

I planned on pulling that box out of the wall for maintenance later this week so will pull a few internal drives and see how it handles missing drives that were detected and mounted prior to your new radar.sh.

[l3mce]

Thank you armorgnome!

For the other 75 people who looked at this thread... 1 tester (other than myself) isn't enough. It will only take you a couple of minutes, literally.

Thanks again in advance!

[PlatypusPedersen]

For the other 75 people who looked at this thread... 1 tester (other than myself) isn't enough.

What happened to rule #1? :p
I intend to test it, but my house is a mess after I have been battling with some hardware issues this week...

[Armor Gnome]

Updated information on your radar.  It took me a while to realize that this was my culprit but I believe I verified it with a few different restore points and step retracing.

Peek-a-boo internal drives:

Beyond orbiter notification that drives were "re-"discovered and ready to use that has been a mild annoyance for a while and partially resolved with changing the onscreen orbiter notification to "important."  This issue is actually the disconnecting of internal drives routinely and quite often.  While working with files using the media sync area of the admin page, entire drives black out and become unselectable.  Leaving that area and returning finds the drive again or shows another drive black.

While on KDE desktop, all of my sata drives "flicker."  Of my 4 drives, dolphin will show 1, then blink and show 3, then blink and show 2, etc.  This "flickering" or rediscovery of drives happens I would say every 1-2 seconds.  I dont know the frequency of your radar doing its sweep but thought that timing may be important for you somehow. 

General system info:
Hybrid, 4 internal sata drives ( .16T install, .25T storage, .25T storage, 1T storage)
10.04 DVD latest install, frequent updates (typically pulling the latest from sqlCVS and update/upgrade every 2-3 days)
Last clone point where problem did not exist was the 23rd of June.  Looks like I ran your patch on the morning of the 25th.

[tschak909]

Believe it or not, the drives mounting/unmounting is the correct behaviour.

This is caused by the fact that we use autofs to automatically mount each disk as needed. This is done with a script (/etc/auto.plutoStorageDevices), which does a database query to determine if a disk is remote or local, and executing the appropriate mount command. When a disk is not used for more than 5 seconds, the disk is umounted.

-Thom

[mathieu]

More or less related,
Im keen on having a system that is low on energie usage.
With THE system constantly looking for new media files, disks are constantly spinning.
Is this assumption correct?
If so, is it possible to have the disks only spinning when reading media files or when doing a manual sync of media files.

Br Mathieu

[tschak909]

You can uncheck the Update Media Daemon while using Media/Files Sync in the web admin, but you will have to manually sync the files each time you add them. Honestly, I think this is insanely retarded, and I think you're being silly for wanting to keep the disks down for what amounts to a negligable energy decrease (you'd do far better just making sure your light bulbs in the house are migrated to something more energy efficient), but hey, that's just me, what the hell do I know? I mean, I've only been working in this field for 20 years....

-Thom

[JaseP]

To follow up on what Thom is saying,... Z-wave dimmers, in addition to alternative lighting,  can also allow you to save energy with incandescents. There's a negligible difference between an incandescent bulb at 75% of capacity and 100% capacity in terms of light output, but that in of itself yields a 25% savings on the electricity that bulb uses. And 50% provides plenty of light with a 60W bulb, if you're not reading or otherwise need more light. Plus the system can automatically control them... Similarly with thermostats...

Of course, various countries are trying to outlaw incandescent bulbs. It seems they think mercury is better for the environment (not to mention our health) than burning a little more fossil fuel...

[tschak909]

Well, this is why I have become a huge champion for LED bulbs...They dim much better, last longer, and no mercury.

-Thom

[JaseP]

I was an early adopter, buying 3 or 4 LED lights, and they all burned out on me in less then 3 mos. I don't want to spend the $$$ until I'm positive the dimmable LEDs have improved.

[Armor Gnome]

. When a disk is not used for more than 5 seconds, the disk is umounted.

-Thom

Thank you for this simple explanation Thom.  I am thinking now of pulling my smaller 250G drives until I fill up my 1T.  This would stop the onscreen notices for them and as the rest of the conversation goes, save a little energy.

[l3mce]

Updated information on your radar.  It took me a while to realize that this was my culprit but I believe I verified it with a few different restore points and step retracing.

Peek-a-boo internal drives:

Beyond orbiter notification that drives were "re-"discovered and ready to use that has been a mild annoyance for a while and partially resolved with changing the onscreen orbiter notification to "important."  This issue is actually the disconnecting of internal drives routinely and quite often.  While working with files using the media sync area of the admin page, entire drives black out and become unselectable.  Leaving that area and returning finds the drive again or shows another drive black.

While on KDE desktop, all of my sata drives "flicker."  Of my 4 drives, dolphin will show 1, then blink and show 3, then blink and show 2, etc.  This "flickering" or rediscovery of drives happens I would say every 1-2 seconds.  I dont know the frequency of your radar doing its sweep but thought that timing may be important for you somehow. 

General system info:
Hybrid, 4 internal sata drives ( .16T install, .25T storage, .25T storage, 1T storage)
10.04 DVD latest install, frequent updates (typically pulling the latest from sqlCVS and update/upgrade every 2-3 days)
Last clone point where problem did not exist was the 23rd of June.  Looks like I ran your patch on the morning of the 25th.

The entire idea behind this new radar was to eliminate ANY mounting/unmounting during the process. This will not be at fault for any such behavior. As Thom explained, this is due to autofs and is the correct behavior. What the radar does, in brief, is make a list of drives, those that are mounted, it ignores. I originally rewrote this because that was not occurring due to an incompatability with the depreciated and dying HAL. We now use udev.
So, finding unmounted drives, they are checked against the database to see if anything has been told to be ignored. If devices, unmounted, not ignored still exist... it should say I found this thing, these are the details of this thing... do you want to use it? Part of that detail is it's size. The only way known by the original folks to cleanly get the size of the device, was to mount it read only and du -h (parsing fdisk is ugly). I discovered a deeper level of udevadm info which exposes this information in an uncomfortable way, and then I convert it a couple of times to make it human readable. This is all I really want to test... that it reports the ACCURATE human readable size. I could have made it report what people want to see... but... I have a penchant for truth in advertizing.

So to sum up... I am curious if this causes problems I cannot foresee, or does not report size on something in some way I did not foresee. I am pretty sure this works as expected.

[l3mce]

Thank you for this simple explanation Thom.  I am thinking now of pulling my smaller 250G drives until I fill up my 1T.  This would stop the onscreen notices for them and as the rest of the conversation goes, save a little energy.

Because they are not mounted does not mean they are not spinning. Yes, pulling them will be the only way to reduce overhead... however they should not continually notify you unless you say "Not now" when asked. If you tell it never to notify you again, it should not... until you unlock it from known devices.

[coley]

I've had it installed for about a week and have no issues with (dis/re)appearing drives.
Been through router reloads and core restarts and drives I expect to appear do so.

-Coley.