LHC Computer Grid - Rollout
> [mailto:[log in to unmask]] On Behalf Of Gonzalo Merino
said:
> What I do not understand is why for castorsrm.pic.es the
> lcg-cr was not
> working, if we were publishing the same SARoot=dteam:dteam and
> CESEBindAccessPoint=/castor/pic.es/grid.
>
> Anyhow, following Maarten advice, after changing the SARoot into
> dteam:/castor/pic.es/grid, now it works, but I was trying to
> understand
> what is different between a classic SE and an SRM in the
> format in which
> these attributes must be published... anybody knows?
For a classic SE the SURL and TURL are identical, apart from a different
scheme (sfn: vs. gsiftp:). In that case the published path (access point
+ saroot) is the real storage path on the SE disk.
For an SRM the SURL and TURL can potentially be completely different,
and indeed you could get a different TURL for the same file at different
times. The TURL doesn't come from the information system at all, you
have to ask the SRM to translate an SURL into a TURL (e.g. as with
lcg-gt). The AccessPoint is supposed to be a real NFS mount point for
the "file" protocol, although LCG doesn't support it at the moment, and
hence it has to relate to the TURL and not the SURL.
However, that still leaves the question of how you form the SURL. For
an SRM the SAroot is used as a prefix for SURLs, and the access point
isn't used. What you need depends on the SRM implementation and
configuration. It may be that there is no prefix; the old WP5 SE just
had / as the saroot because it would decide internally where to put the
files, and an SURL like srm://se.rl.ac.uk/xxxx was perfectly valid.
However, presumably a castor SRM does want an SURL prefix which
corresponds to the file name in castor:
lcg-cr --vo dteam -d castorsrm.pic.es file:/etc/group
guid:ed31d864-5be0-41eb-85aa-ed791d2ad4ba
lcg-lr --vo dteam guid:ed31d864-5be0-41eb-85aa-ed791d2ad4ba
srm://castorsrm.pic.es/castor/pic.es/grid/dteam/generated/2005-09-07/fil
e22aceca3-a621-49f1-9e89-3ec75ffa0ae7
I didn't specify an SURL at all there. The generated/... part is
autogenerated by the lcg-cr code, but obviously it has to get the first
part from the information system. (I'm actually a little unsure where
the "dteam" part of the path comes from, I guess it's hardwired in
lcg-cr.) If I try to set the SURL explicitly without the prefix I get:
lcg-cr --vo dteam -d srm://castorsrm.pic.es/qqqtest file:/etc/group
initFileStatuses: cannot create path /qqqtest: BAD ERROR NUMBER: 0
and:
lcg-cr --vo dteam -d srm://castorsrm.pic.es/castor/pic.es/grid/qqqtest
file:/etc/group
lcg_cr: Permission denied
lcg-cr --vo dteam -d
srm://castorsrm.pic.es/castor/pic.es/grid/atlas/qqqtest file:/etc/group
lcg_cr: Permission denied
lcg-cr --vo dteam -d
srm://castorsrm.pic.es/castor/pic.es/grid/dteam/qqqtest file:/etc/group
guid:2f87b7fa-987f-450e-8205-f1f33d72374b
Stephen
|