On Tue, 2005-12-06 at 22:26, Graeme Stewart wrote:
> gianfranco sciacca wrote:
> > On Tue, 2005-12-06 at 17:12, Graeme Stewart wrote:
> >
> >
> >>>We also have additional storage that is nfs-mounted on the pool node,
> >>>but this does not appear neither in GStat nor in dpm-qryconf (see below
> >>>- the mount point would be pc30 /storage/atlas). I'm not sure whether
> >>>this is correct, but I think it isn't. I am also not sure permissions
> >>>are set correctly, as I don't seem to be able to dpns-rm a file that I
> >>>have just copied (this test had worked fine a few days ago).
> >>
> >>No, this isn't the right way to do things. DPM gets the size of the filesystem
> >>using statfs64(), which will never see the size of things mounted beneath
> >>that filesystem's mount point.
> >>
> >>What you should do is:
> >>
> >>1. Unmount /storage/atlas from pc30:/storage.
> >>2. Change fstab to make its mount point somewhere independent
> >>(e.g., /storage1). Re-mount it.
> >>3. Follow steps 7 and 9 of the http://wiki.gridpp.ac.uk/wiki/DPM_Disk_Pool
> >>wiki article, i.e.,
> >> pc30# chmod dpmmgr: /storage1
> >> pc55# dpm-addfs --poolname dpmPart --server pc30 --fs /storage1
> >>(You don't have to do the rest bacause pc30 already is a disk pool, you're
> >>just adding a new filesystem to this pool.)
> >>
> >>Then things should work.
> >>
> >>I assume there's no data on this filesystem....? If there is we might have to
> >>think about this quite carefully - perhaps a soft link from /storage/atlas
> >>to /storage1/atlas so that old lfns work through the "vanilla" gridftp
> >>server? Something to check.
> >
> >
> > There's indeed data on this filesystem. What's your advice then?
>
> OK, I've just checked and, as expected, the DPM gridftp is quite happy
> to follow soft links. So, my advice is pretty much the same:
>
> 1. Unmount /storage/atlas.
> 2. Modify the fstab to make a new mount point for it: /storage1 for the
> sake of argument. Mount it here.
> 3. Now make 2 subdirectories, atlas and dpmFS.
> 4. Move all the _old_ atlas data directories to /storage1/atlas.
> 5. pc30# chown dpmmgr: /storage1/dpmFS
> 6. pc30# chmod 770 /storage1/dpmFS
> 7. Make a soft link to point from /storage/atlas -> /storage1/atlas
> 8. Add the new fs:
> pc55# dpm-addfs --poolname dpmPart --server pc30 --fs /storage1/dpmFS
>
> The key point here is to ensure that the old classicSE type paths,
> /storage/atlas/blahBlah point to the new locations of the files,
> /storage1/atlas/blahBlah. We need to make the DPM fs a subdirectory of
> the root of this filesystem:
>
> 1. so that things don't get untidy ;-)
> 2. so that when DPM gets atlas files, and places them on this fs, which
> it will do in "DPM_fs_path/atlas/DATE", that it does so in
> /storage1/dpmFS/atlas, avoiding confusion with the old files in
> /storage1/atlas.
>
> I think that this will all work... Caveat emptor and unknown unknowns...
>
> Perhaps Greig or Jiri could comment - sounds feasable?
>
> Cheers
>
> Graeme
>
> PS. Check that you can get altas data out the old paths by using a
> globus-url-copy.
Hi again,
it seems as we currently have more problems that I thought. I did some
tests and I am actually not able to get data that are stored on our
former classic_SE neither with globus-url-copy nor with srmcp or lcg-cp.
File URLs or LFNs seem to be resolved to the correct files but that
transfer fails or the file is said not to exist.
gs> lcg-cp --vo atlas lfn:testFile.txt file:/tmp/testfile.txt
the server sent an error response: 550 550
/storage/atlas/generated/2005-11-14/file8dca1b10-c23a-4e17-86ba-c8510387842a: not a plain file.
lcg_cp: Invalid argument
Everything works correctly if dealing with files stored on the DPM head
node. So perhaps the migration was not entirely successful after all.
Currently investigating, any tip appreciated.
cheers,
gianfranco
|