Hi Henry,
When doing
srmcp file:////home/vanderaa/voms.dta
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/testoli
srm client error: number of jobs = 1 successfully completed=0
the file is registered in the dpm database
[vanderaa@gfe03 vanderaa]$ srm-get-metadata
srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/testoli
FileMetaData(srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/testoli)=
RequestFileStatus SURL
:srm://dgc-grid-34.brunel.ac.uk:8443/dpm/brunel.ac.uk/home/cms/testoli
size :15670
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 :
but does not seem to be written on the pool node. Did you check the
mapfile on the pool also ?
Cheers, Olivier.
On Thu, 6 Jul 2006, Henry Nebrensky wrote:
> On Wed, 5 Jul 2006, Graeme Stewart wrote:
>
>> On 5 Jul 2006, at 20:05, Dr D J Colling wrote:
> ...
>> Then:
>>
>> grid13:~$ edg-gridftp-ls --verbose gsiftp://dgc-grid-34.brunel.ac.uk:
>> 2811/dpm/brunel.ac.uk/home/dteam
>> ...
>> -rw-rw-r-- 1 ops013 dteam 520 Jul 05 21:14
>> gs_test_20060705
>> ...
>>
>> Note the rather odd UID mapping to ops. I also see that with your
>> test directory:
>>
>> grid13:~$ edg-gridftp-ls --verbose gsiftp://dgc-grid-34.brunel.ac.uk:
>> 2811/dpm/brunel.ac.uk/home/cms
>> drwxrwxr-x 0 ops012 cms 0 Jul 05 18:36
>> DJC_test
>>
>> Which indicates we're being rather aggressively mapped to the ops VO.
> ...
>> It's active, and seems to be ok (although 1.7GB to Brunel will take a
>> while...)
>>
>> I suspect something might be up with CMS transfers in particular. Can
>> you try a simple srmcp and check that that works. And are you mapped
>> to some odd ops person?
>>
>> Perhaps Duncan or Henry could check the DPM mapping file.
>
> Duncan's away at the moment; I don't know if this is supposed failover to
> me...
>
> 1) At least some of the CMS Heartbeat transfers [*] worked earlier "to"day
> FWIW. Except RAL, I think...
>
> 2) Looked at gridmap-file on DPM head:
>
> "/C=UK/O=eScience/OU=Imperial/L=Physics/CN=david colling" .cms
> "/C=UK/O=eScience/OU=Glasgow/L=Compserv/CN=graeme stewart" .dteam
>
> dpm/log
> 07/05 17:45:16 3252,24 dpm_srv_inc_reqctr: DP092 - inc_reqctr request by /C=UK/O=eScience/OU=Imperial/L=Physics/CN=david colling (30012,1300) from dgc-grid-34.brunel.ac.uk
>
> dpns/log:
> 07/05 17:45:16 3045,0 getidmap: Creating a new Virtual uid for /C=UK/O=eScience/OU=Imperial/L=Physics/CN=david colling
> 07/05 17:45:16 3045,0 Cns_srv_getidmap: NS092 - getidmap request by /C=UK/O=eScience/OU=Imperial/L=Physics/CN=david colling (30012,1300)...
>
> UID 30k+ is ops, gid 1300 is cms (as reported). That's my DPM knowledge
> exhausted - if someone can explain where getidmap is looking I'll try to
> have a look.
>
> 3) Elsewhere, Graeme Stewart wrote:
> ...
>> It's active, and seems to be ok (although 1.7GB to Brunel will take
>> a while...)
>>
>> Actually, it timed out. FTS doesn't like transfers which take >~3600s...
>
> 1.7GB in 1 hour = 1.7MB in 3.6s = 13.6 Mb in 3.6 s = 3.8 Mb/s.
>
> So that ought to fit into our bandwidth reservation easily. Duncan would
> know if something else needs chasing.
>
> Thanks
>
> Henry
>
> * p.s. got bored at lunchtime and checked it. Most transfers failed: same
> problems/solutions as in May, should they ask.
>
> --
> Dr. Henry Nebrensky [log in to unmask]
> http://people.brunel.ac.uk/~eesrjjn
> "The opossum is a very sophisticated animal.
> It doesn't even get up until 5 or 6 p.m."
>
|