Hi Graeme, Matt, Stephen and everybody else,
Thanks for your help on this so far...
I have been doing some more testing and don't understand the results ... I
am sure that people who understand storage will say "of course it is like
that because..." and I apologise if I am asking numpty questions.
OK... so first I try to srmcp a small file
srmcp file:////`pwd`/tt
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test_tt
works like a dream...
[phedex@gw36 phedex]$ srm-get-metadata
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test_tt
FileMetaData(srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test_tt)=
RequestFileStatus SURL
:srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test_tt
size :195
owner
:/C=UK/O=eScience/OU=Imperial/L=Physics/CN=david colling
group :cms
permMode :33204
checksumType :null
checksumValue :null
isPinned :false
isPermanent :true
isCached :true
state :
fileId :0
TURL :
estSecondsToStart :0
sourceFilename :
destFilename :
queueOrder :0
So then I try the original file pair ...
srmcp
srm://dcache.gridpp.rl.ac.uk:8443/srm/managerv1?SFN=/pnfs/gridpp.rl.ac.uk/data/cms/phedex_loadtest/LoadTest_T1_RAL_030
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test
It just sit there hanging ... I go for lunch ... come back... have a
coffee ... and it is still hanging. Neither edg-gridftp-ls or
srm-get-metadata seem to have any knowledge of the destination file.
So I kill it.
So I consider that 1.5GB maybe optimistic to Brunel (even given Henry's
reassurance) so I think that I will use the same small file as I
transferred to Brunel initially with srmcp glite-transfer-submit. As I
could not glite-transfer-submit to accept a file://// (why the 4 slashes?)
type I first copy the file from Brunel using
glite-transfer-submit -p mypass -f tt1
where tt1 =
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test_tt
srm://gfe02.hep.ph.ic.ac.uk:8443/pnfs/hep.ph.ic.ac.uk/data/cms/tt
works like a dream...
[phedex@gw36 phedex]$ srm-get-metadata
srm://gfe02.hep.ph.ic.ac.uk:8443/pnfs/hep.ph.ic.ac.uk/data/cms/tt
FileMetaData(srm://gfe02.hep.ph.ic.ac.uk:8443/pnfs/hep.ph.ic.ac.uk/data/cms/tt)=
RequestFileStatus SURL
:srm://gfe02.hep.ph.ic.ac.uk:8443/pnfs/hep.ph.ic.ac.uk/data/cms/tt
size :195
owner :11410
group :1399
permMode :420
checksumType :
checksumValue :
isPinned :false
isPermanent :true
isCached :true
state :
fileId :0
TURL :
estSecondsToStart :0
sourceFilename :
destFilename :
queueOrder :0
However, when I try copying it back I find with glite-transfer submit I
find
[phedex@gw36 phedex]$ glite-transfer-status -l
e75cc281-0ced-11db-b679-e8890ecfc30e
Failed
Source:
srm://gfe02.hep.ph.ic.ac.uk:8443/pnfs/hep.ph.ic.ac.uk/data/cms/tt
Destination:
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/DJC_test/test_tt_2
State: Failed
Retries: 1
Reason: No Channel found or VO not authorized for transferring
between UKI-LT2-IC-HEP and UKI-LT2-BRUNEL
Duration: 0
I guess that this means that there is no channel between Brunel and IC ...
but in that case how did it manage to copy it the other way? Was it using
the STAR-UKILT2ICHEP channel and there isn't STAR-UKILT2BRUNEL channel?
If this is the reason then please could we have a STAR-UKILT2BRUNEL
channel setup.
Any help in understanding this would be most welcome ...
Why cannot everything be a intuitive as workload management ;-)
All the best,
david
|