Hi
This is the problem that we also had at Glasgow with our lost files -
the problem seems to be specifically the DESTINATION OVERWRITE, as
Alessandra has noted - the issue is that FTS can't *delete* the
"existing" copy of the file (from the disabled/lost filesystem), and
so the transfer fails (even though you'd hope that the new copy would
be assigned somewhere else...
Sam
On 26 November 2014 at 09:40, Alessandra Forti <[log in to unmask]> wrote:
> It is part of the lot of machines that I cannot empty because of the
> migration to rucio.
>
>
> On 26/11/2014 09:39, Alessandra Forti wrote:
>>
>> The machine is DISABLED, but even if it was in RDONLY if DPM didn't handle
>> that well we would know by now.
>>
>> It is more likely that the problem lies with the new destination overwrite
>> which I was actually a bit worried about.
>>
>> The machine has been disabled for several weeks now and there is plenty of
>> space for a test on other machines to be successful.
>>
>> cheers
>> alessandra
>>
>>
>> On 26/11/2014 09:34, [log in to unmask] wrote:
>>>
>>> Hi,
>>> I would assume that FTS asks DPM head node for a TURL in the prepareToPut
>>> phase ; DPM head node then is return a TURL on machine
>>> se08.tier2.hep.manchester.ac.uk. Maybe DPM isn't handling the READONLY
>>> properly? ( Just a hypothesis..)
>>> Brian
>>>
>>>
>>> -----Original Message-----
>>> From: Alessandra Forti [mailto:[log in to unmask]]
>>> Sent: 26 November 2014 09:12
>>> To: [log in to unmask]
>>> Subject: FTS3 accessing a disabled machine in DPM
>>>
>>> Hi,
>>>
>>> does anybody know how that is possible? Is it DPM or is it FTS3? leaning
>>> on the latter but I ask before closing the ticket we got
>>>
>>> https://ggus.eu/index.php?mode=ticket_info&ticket_id=110366
>>>
>>> thanks
>>>
>>> cheers
>>> alessandra
>>>
>>> --
>>> Respect is a rational process.
>>
>>
>
> --
> Respect is a rational process.
|