Hi,
For the sound of that, is it actually a bug?
If the free space in a pool is less than the reserved space in that pool,
then surely all the remaining "free" space is actually reserved and no-one
without a reservation should be able to write to it otherwise the storage
risks not being able to honour it's reservations - of course once you reduce
a pool in size then you run that risk anyway but by blocking transfers into
non reserved space it's at least doing it's best.
Or is it doing this even if the free space is more than the reserved space?
Yours,
Chris.
> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> [log in to unmask]] On Behalf Of Ewan MacMahon
> Sent: 21 February 2012 11:22
> To: [log in to unmask]
> Subject: Re: Ticket summary - 20th Feb 12
>
> > -----Original Message-----
> > From: Testbed Support for GridPP member institutes [mailto:TB-
> > [log in to unmask]] On Behalf Of John Gordon
> >
> > If this has been a long-standing DPM issue then I will ask to have
> > this test (SRMput ?) removed from the SRMV2 set of tests so that it
> > isn't included in availability. If it turns out that sites are being
> > asked to make space available exclusively for OPS (Does Stephen's
> > suggestion work?) then we should have that out in the open.
> >
> I'm not sure that's the correct approach - the test is giving a real
> result. AIUI (and I've just tested this with a dteam proxy) it's not
> possible for anyone to use the 'other VOs' space when it is in this
> state - it's not that the ops jobs are enforcing an extra check, it's
> that it actually doesn't work unless you have access to a space token
> reservation. If I'm understanding this correctly then no-one except
> ATLAS can write new files to the Manchester SE, so for everyone that's
> not ATLAS it really is unavailable.
>
> There's clearly the free space actually there, but if you can't write
> to it thanks to the DPM bug, it's not of much practical use.
>
> Ewan
|