> Anyone monitoing storage usage on GridPP might have noticed that the CMS
> usage at RALPP jumped from < 1TB to ~10TB in about 5 minutes last week.
> That wasn't a result of some really big new network pipe but my
> rewriting the collector for the the T1 dCache accounting script to get
> past the NFSv2 limitation on seeing files over 2 Gigs.
>
> The new version works if you have one database for each VO, it
> automounts all the pools, queries the size of each file in the pool and
> assigns it to a VO by the first four digits of the PNFSid, then wirtes
> the totals to the used-space.dat file the T1 info provider plugin uses.
> You still have to compile the available-space.dat file by hand (though
> I've got some ideas about querying the admin interface to get pool to
> pool-group mappings and the pool config files to get sizes).
>
> I could put the code up somewhere if anyone wants it though it's messy,
> uncommented and mixed up with the code that publishes the info into
> ganglia.
Definitely put it up on the wiki. You should add in a new section or page
here:
http://www.gridpp.ac.uk/wiki/GridPP_dCache_GIP_plugin
Sounds like a decent solution you have there. How long does it take to
run?
You probably don't have to use the pool config files to get the available
space. If you're being brave enough to deal with the admin interface to
get pool to pool-group mappings then you can get the pool size from there
as well.
However, an alternative would be to use the pool to pool-group mappings
that are in the PoolManager.conf file. As long as you've entered 'save'
then this file will correctly represent the dCache pool setup. This would
also prevent you having to deal with the admin interface and since you are
mounting the pools anyway, you could easily parse for the pool size in the
pool config file.
Cheers,
Greig
|