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.
|