Hi,
Seems to me the concept of 'close' SE has been problematic since the BOG
(Beginning Of Grid). If we ever agree on a definition of 'close' -- and
I doubt it, just try discussing what a 'dataset' is with somebody --
then we could use it.
Given that 'close SE' comes out of the BOG epoch and is still poorly
defined, I think it's best to ask: "what problem is it that having a
'close SE' is supposed to solve?"
I can think of only two:
- posix file access to that SE
- fast network to that SE
I suspect the first point is no longer a valid one, since 'posix file'
used to mean 'NFS mount' which is why the SE had to be 'close'. Now
that we have e.g. gsirfio, I could have a "close SE" in Chicago.
So I would be in favor of reporting the protocols (we do this already)
and also specifying a site-default SE, with the *option* of specifying a
different one per VO.
I still hope we will have user-space remote mounting someday, so I could
e.g. mount the grid file system with root /grid/atlas/rome05/bbar/ivov
as /gmount/ivovdata in user space ... solves a lot of problems.
J "this is only one cup of coffee" T
Maarten Litmaath, CERN wrote:
> On Thu, 7 Jul 2005, Kyriakos G. Ginis wrote:
>
>
>>On Thu, Jul 07, 2005 at 12:10:43PM +0200, Maarten Litmaath, CERN wrote:
>>
>>>On Mon, 4 Jul 2005, Rod Walker wrote:
>>>
>>>
>>>>The situation is that SFU has significant disk and tape storage, running
>>>>dcache, and very good network to TRIUMF and WestGrid cpu. Previously it
>>>>was published via the TRIUMF-GC-LCG2 site giis, but this was for
>>>>convenience, and in order to isolate it from maintenance and problems at
>>>>TRIUMF it would make sense to have a seperate site(giis).
>>>
>>>OK. Any site that is "close" to SFU can publish the SE as a close SE.
>>
>>Hello,
>>
>>Regarding this 'close SE' issue: If a site 'A' publishes a SE 'B' as a
>>close SE, are the WNs of site 'A' expected to have rfio access to the SE
>>'B'?
>
>
> You raise an interesting point. First of all, not all SEs support RFIO:
> a dCache SE has "gsidcap" instead. A user application may be able to deal
> with both protocols, though, e.g. by using GFAL. If the SE advertizes any
> such POSIX-like access protocol, one would indeed expect to be able to use
> the protocol from any CE (WN) that is "close" to the SE, but I do not know
> if such is required according to some official document at this time.
>
> In the case of SFU there need not be a problem, as it simply could abstain
> from publishing "gsidcap", but when an SE is accessible from the local CE
> through a POSIX-like protocol, a remote site should no longer declare it
> as a close SE, even when it is physically close and preferred...
> The remote site could still declare it to be the default SE, though.
> Comments?
|