> -----Original Message-----
> From: Testbed Support for GridPP member institutes [mailto:TB-
> On Mon, 15 Jun 2009, Ewan MacMahon wrote:
>
> > Surely the correct and simple solution to this (in principle - I'm
> > not aware of any SRM implementation that does this) is to use a
single
> > pool account mapping for a given user[1] across a whole site, so
both
> > running jobs and storage access happen with the same mapped account.
>
> I agree that this is probably the "correct" route, but it would have
to
> be the same mapping across the site - including multiple CEs and SEs -
>
Sites with redundant CEs already have to have uniform mappings across
them,
usually managed by NFS mounting a common gridmapdir, and the forthcoming
SCAS service that glexec will use exists to provide site-wide mappings.
> AND it would have to be permanent (otherwise you won't be able to
access
> your file when you come back and get mapped to a different pool
account).
>
That's true, but not difficult. Nor (AIUI) is it rare at the moment.
> On top of that you still need some way to ensure that whatever was
just
> written still gets correctly registered in the SE and so on, though,
so
> I don't think this is really a simple solution.
>
'Registered in the SE' in what sense? If the SE is just a thin layer
over
the filesystem, then it wouldn't need to store anything over and above
what the filesystem already stores.
> OTOH from the little I've misunderstood about workflows, I don't think
> a read-only file:// protocol is a huge hardship - simulation already
> works without it, and any use case that requires random read/write
> access to files already on the SE is probably a Bad Idea anyway.
>
Surely a job that generates large output would want to write it directly
to
the SE over a local access protocol (either file:// or rfio://) rather
than
be limited to the size of file that it can create on local worker-node
disk
then lcg-cr from there?
Ewan
|