On Tuesday 20 Sep 2005 18:17, Rod Walker wrote:
> Hi,
> I don`t think anyone answered this. I thought the move from classic SE to
> DPM allowed the files to stay(unlike for dcache). I heard this somewhere
> but can`t find it written down now.
IT-GD are working on a script, which they are testing. We in GridPP storage
support are trying to get a copy so that we can use it to help our T2s
migrate without affecting experiment's data, but we haven't got it yet.
Perhaps someone from the DPM developers could comment on timescales?
Unfortunately for small sites scheduling effort means that there can be small
windows for doing significant service migrations, like deploying SRM storage.
On Tuesday 20 Sep 2005 18:26, Burke, S (Stephen) wrote:
> LHC Computer Grid - Rollout
>
> > [mailto:[log in to unmask]] On Behalf Of Rod Walker
>
> > If the paths and hostname will stay the same, i.e. the sfn's are
> > unchanged, then you don`t need to do anything.
>
> The sfns might stay the same but the SURLs can't, at the least the
> scheme changes from sfn: to srm:. Also I think ownership and/or
> permissions have to change. There have been repeated requests from the
> UK for many months for a migration strategy, but as far as I know
> nothing has emerged so far.
The proposed migration script would ensure that the old sfn: catalog entries
remain valid, by getting the DPM to publish itself as a classic SE as well as
an SRM (c.f. Stephen's later comments on the schema). But it's all a bit
putative and we need to test and debug the process.
There are certain "irreversible" changes to metadata (migrating this from the
filesystem into the DPM names), so they script definitely has to be well
tested and robust.
On Tuesday 20 Sep 2005 18:52, Rod Walker wrote:
> Hi,
> For moderate amounts of data there is a safe, if dull, procedure,
> providing only one site does it at a time.
> 1) Remove files with replicas elsewhere
> 2) replicate loners to local T1
> 3) repeat
>
It's a bit tedious, but yes possible, _except_, that a site administrator with
a dteam certificate will not be able to modify entries in the atlas catalogs,
right? (Or are you very liberal..?)
There is a clear need for sites to have some kind of procedure for dealing
with VOs files stored at their site. It's not at all clear how sites contact
experiments in this case (data-manager@atlas?). Even if we do deal with the
migration to SRM in an ad hoc sort of way there's the obvious scenario where
data is lost through hardware failure and catalog entries need to be removed.
Again, there's no operational procedure I'm aware of to deal with this.
(Clearly using EGEE broadcast has not worked!)
> Please don`t delete the data, despite the tardy response from Atlas.
I'll speak to Mark and we'll try and come up with a plan...
Cheers
Graeme
--
--------------------------------------------------------------------
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
GridPP DM Wiki http://wiki.gridpp.ac.uk/wiki/Data_Management
|