On Friday 08 July 2005 00:39, Philip Clark wrote:
> "Gordon, JC (John)" <[log in to unmask]> writes:
> > Maybe I am nitpicking Greg, but just to spell it out for the others: dpm
> > DOESN'T need the data migrating, just metadata adding (allegedly).
> > dCache DOES needs data migration as its data is stored in its own
> > format.
> The documentation on this point is quite vague.
It states that IT-GD "will provide a script in the very near future".
Having looked at the tables that DPNS (the DPM name server) users it's easy
enough to see how this can be
done (it's probably the case that it can be done trivially for any given T2 -
the hard bit will be ensuring that the script is robust enough to cope with
all eventualities). It's not true that no changes take place on the old disk
- all the physical files have to be chowned to the non-privileged dpm user
and all the ownership metadata transfered into DPNS database. However, if DPM
can see the files within one of its pools (and this can probably even be an
nfs mount) then the physical data does not need to be copied.
However, as Henry says, unless you migrate the hostname of the old classic SE
to the new DPM SE then the SURLS will change, at minimum the hostname will be
different (unlike dCache you can probably keep the path unaltered). Presumably
this involves some element of risk as one is betting the farm on the
transition being smooth.
At Glasgow we've decided to setup an new SRM SE (probably DPM) and make our
old SE read only (the WNs will be told that the new SE is "close").
Then we will discuss with VOs (actually, that's just Atlas)
how to transfer their data across and ensure that appropriate file catalogs
are updated. This will mean copying the data, but then at least we have a
situation we can roll back from easily is something does go wrong. For other
T2s this is of course predicated on having enough disk to be able to migrate
in this way.
> We really should only be
> considering at this point volatile files at tier2's, but this may
> change. Otherwise we end up stuck with old MC production files that were
> already copied elsewhere and lie dormant. The srm management is
> something we really want to encourage and gsiftp, discouraged.
Do any of the SRMv1 clients support pinning? DPM has a default pin time on
volatile storage, but the expts really have to be able to manipulate this.
Can they, I wonder?
Dr Graeme Stewart http://www.astro.gla.ac.uk/users/graeme/
Department of Physics and Astronomy, University of Glasgow, Scotland