Of course, you could argue that if the SRM has decided to replicate the
file in order to load balance the system, then there is a chance (is it
certain?) that this action was triggered by lots of members of the VO
asking for that file. So you could say that it was the VOs 'fault' that
they now have multiple copies of the file and should be charged
accordingly. Just a thought. It would be a nightmare trying to work all of
that out.
For user requested replication, the fact that there are replicas would
still not appear in the PNFS namespace of dCache. You really need a DB
query to pick out _all_ of the files.
Greig
On Thu, 28 Sep 2006, Jensen, J (Jens) wrote:
> Greig A Cowan wrote on 28 September 2006 16:20:
> > You're right that the plugin will not account for space used by file
> > replications. However, it's not clear to me what should happen in this
> > situation. If an SRM decides to replicate a file, then should the VO be
> > 'charged' for the space used?
>
> Indeed. I think we should just decide on what is most useful
> and least difficult to implement and run, and then
>
> (a) be consistent across implementations (dCache, DPM, CASTOR),
> (b) be consistent across sites (everybody with the same impl runs
> the same plugin (or at least that behave identically)),
> (c) document what it does, lest management add up the wrong numbers.
>
> For example, CASTOR doesn't immediately recycle space from deleted
> files from tape, so the space used by deleted files is neither used
> nor available, by some definition.
>
> Also, ponder Disk1Tape1. We can account for the stuff on disk
> but there may be more than one disk copy of the file - Disk1Tape1
> says that in all but disk failure cases there is at least 1.
> But available space for Disk1Tape1 is the min of available space
> on disk and tape (by some suitable definition of available).
> But available space on disk depends on how many loose copies are
> floating around, unless the system is really smart enough to
> recognise how many can be garbage collected.
> This is sort of a problem because normally avail(tape) >> avail(disk).
>
> You almost need a PhD in astrology to figure this out.
>
> Anyway, in answer to your question, people should only be
> billed for one copy unless they have explicitly requested two
> (as in Disk2Tape0), I'd have thunk.
>
> BTW, I am going to try to document some or all of this on
> https://www.gridpp.ac.uk/wiki/Storage_Monitoring_and_Accounting
> https://www.gridpp.ac.uk/wiki/RAL_Tier1_CASTOR_Accounting
> and then circulate to Jeremy's EGEE metric list for discussion.
>
> -j
>
> PS. I wanted to attach one of those Monty Python "my brain hurts"
> pictures but you know what Gumby looks like.
>
--
=======================================================================
Dr Greig A Cowan http://www.ph.ed.ac.uk/~gcowan1
School of Physics, University of Edinburgh, James Clerk Maxwell Building
TIER-2 STORAGE SUPPORT PAGES: http://wiki.gridpp.ac.uk/wiki/Grid_Storage
=======================================================================
|