On Tuesday 06 Dec 2005 16:28, gianfranco sciacca wrote:
> On Fri, 2005-12-02 at 23:42, Graeme Stewart wrote:
> > > > > Hi,
> > > > >
> > > > > I've just installed the DPN plugin by Graeme and Gstat reports only
> > > > > the capacity of the DPN head node.
>
> <snip>
>
> > > I think it's down to the fact that the names of our groups do not fully
> > > correspond to the names of the VOs, but have a 'lcg' prefix. This is
> > > because we already have an atlas group on our local cluster. I attach
> > > the requested files.
> >
> > Gianfranco, you're right. If you look at the perl you'll see that the
> > plugin looks up the GID using the VO.
> >
> > The right way around this is to get the VO storage root from the ldif
> > file, and look up the GID directly using dpns_stat(). However, that will
> > only be possible with the next DPM release and the perl API.
> >
> > For the moment, I have attached a modified version of the plugin for you
> > to use. It:
> >
> > 1. Defines a %voNameToGroup hash to hack the VO name into the correct
> > unix group name.
> > 2. Correctly parses the error if getgrnam() fails (which is that the $gid
> > variable is undefined, not that it's "").
> >
> > I think it should work, but let me know if you have problems - hopefully
> > it should tide you over till the next release.
>
> thanks Graeme,
> this works as intended. Also your new README is more clear.
Thanks.
>
> I have also set the file system on the pool node to 0 (thanks Greig - we
> had assumed it was to be set as RDONLY so that only dpmmgr would have
> write access) and now GStat sees the storage attached to the head node
> and the pool node correctly.
Yes - again the plugin only reports what DPM tells it in the
CAPACITY XXX FREE YYY
line, and at the moment both of these are counted as 0 for any RDONLY
filesystem (I think an argument could be made that capacity should be
reported for the size of the fs and that only free space should drop to zero
- but anyway, that's the way it behaves right now...).
>
> 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.
In summary, DPM wants all it's storage given to it in filesystem mountpoint
chunks!
>
> cheers and thanks for helping,
No problem.
Cheers
Graeme
--
--------------------------------------------------------------------
Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
GridPP DM Wiki http://wiki.gridpp.ac.uk/wiki/Data_Management
|