CMS Site Log for PHOENIX Cluster
Go to
previous page /
next page of CMS site log
10. 2. 2007 Cleaning of data sets from SE
I cleaned several data sets from our DPM, since no more space was left (one shared pool from LHCb which we had opened to all
had never been used. Seems to be a DPM problem). A number of production jobs had failed in writing to our storage, but the problem was only detected
when the production team ran the merge jobs. The files exist in the nameserver of DPM, but there are no connected SFNs for them. They can be
detected easily, since they show up as files with 0 bytes file length on commands like
edg-gridftp-ls --verbose
or
rfdir
.
Gave this feedback to Alexander Flossdorf from DESY.
12. 2. 2007 Test of PhEDEx 2_5_0_1
Tested Dev instance of new PhEDEx distribution. Subscribed to
/phedex/monarctest_CERN/1
data set The files were
routed from PIC and the FTS at FZK seemed to work fine.
After half of the files had completed, there was again the typical error for many transfers.
Failed Transfer failed. ERROR the server sent an error response: 425 425 Can't open data connection. timed out() failed.
The PhEDEx monitoring page showed, that T1_PIC transfers to a whole number of other sites also were problematic. But I found for every other site a different
error.
Since we are currently busy getting the new
dCache SE up and our old DPM SE has not much space available, I just started the PhEDEx Prod instance, but did not subscribe to new data right now.
20. 2. 2007 started Cycle-1 / Week-2 exercise
Following the plan laid out in
Daniele Bonacorsi's pages I signed up T2_CSCS for a number of
MONARC test samples in the
Dev instance, after making sure that FZK had the same subscriptions (FZK had no subscriptions in Prod, so I chose Dev). After fixing a trivial error due to myproxy, we began to get the files at almost 30 MB/s from
IN2P3.
21./22. 2. 2007 myproxy renewal problem / no source files from IN2P3
Due to a myproxy renewal problem on our side the transfers of last night failed. There have been multiple attempts to transfer from FZK.
All the following routings picked
IN2P3 as a source, even though the requested files had already been erased there (so there was an inconsistency in TMDB and what the center had on disk). The problem was corrected the following day. I cancelled all subscriptions in the Dev instance and
subscribed to a new set of monarc test files in the Prod instance.
These graphs show load generated by transfers from FNAL:
Go to
previous page /
next page of CMS site log
--
DerekFeichtinger - 20 Feb 2007