I think Lancaster might be working.... I can write into our Space
Managed srm with or without defining a space token, with srmv1 or v2
tools. If someone can try to see if it works for them too that would
be grand.

What I did differently was go all out on my linkGroups, leaving no
link ungrouped, and make sure to copy the modified dCacheSetup to my
pnfs node. Then after restarting it all leave it a small amount of
time, as it takes a while for the SrmSpaceManager to count up how much
space is free and during this time it reports 0 space. The trick is to
wait till a "ls link groups" in the SrmSpaceManager cell reports
non-zero free space for all linkGroups. Thanks to Dmitry for that and
all the other help he's given me in getting this up and running.

Let's hope we're fixed so I can go whip myself up a victory cocktail.

cheers,
Matt

On 08/02/2008, Brew, CAJ (Chris) <[log in to unmask]> wrote:
> Hi Greig,
>
> At the moment all the head nodes services are on a single node with only
> pool, GridFTP, gsidcap and xrootd running on the pool nodes.
>
> diff dCacheSetup dCacheSetup.new
> 245c245
> < srmSpaceManagerEnabled=no
> ---
> > #srmSpaceManagerEnabled=no
> 250c250
> < #srmSpaceManagerEnabled=yes
> ---
> > srmSpaceManagerEnabled=yes
> 252,256c252,256
> < #srmImplicitSpaceManagerEnabled=yes
> < #SpaceManagerDefaultRetentionPolicy=REPLICA
> < #SpaceManagerDefaultAccessLatency=ONLINE
> < #SpaceManagerReserveSpaceForNonSRMTransfers=true
> <
> #SpaceManagerLinkGroupAuthorizationFileName=/opt/d-cache/etc/LinkGroupAu
> thorization.conf
> ---
> > srmImplicitSpaceManagerEnabled=yes
> > SpaceManagerDefaultRetentionPolicy=REPLICA
> > SpaceManagerDefaultAccessLatency=ONLINE
> > SpaceManagerReserveSpaceForNonSRMTransfers=true
> >
> SpaceManagerLinkGroupAuthorizationFileName=/opt/d-cache/etc/LinkGroupAut
> horization.conf
>
> For the PoolManager.conf file I comment or uncomment a section like:
>
> #psu create linkGroup lhcb-link-group
> #psu addto linkGroup lhcb-link-group lhcb-link
> #psu set linkGroup custodialAllowed lhcb-link-group false
> #psu set linkGroup outputAllowed lhcb-link-group false
> #psu set linkGroup replicaAllowed lhcb-link-group true
> #psu set linkGroup onlineAllowed lhcb-link-group true
> #psu set linkGroup nearlineAllowed lhcb-link-group false
>
> for each VO
>
> In the LinkGroupAuthorisation.conf I currently have a section like:
>
> LinkGroup atlas-link-group
> /atlas/Role=*
> atlas001/Role=*
>
> for each VO.
>
> I think I'll just have to give myself a good long downtime next week and
> really play with it.
>
> Thanks for the help,
> Chris.
>
> > -----Original Message-----
> > From: Greig Alan Cowan [mailto:[log in to unmask]]
> > Sent: 08 February 2008 18:52
> > To: Brew, CAJ (Chris)
> > Cc: [log in to unmask]
> > Subject: Re: Help
> >
> > Hi Chris,
> >
> > How are your dCache services spread among your available nodes?
> >
> > I seem to be able to copy files into the system - but I
> > assume this is
> > because you have reverted back to a non-spacemanager configuration?
> >
> > How does the PoolManager.conf and dCacheSetup differ between the two
> > configurations? What is contained in your LinkGroupAuthorisation.conf
> > file (not that it should matter in this case since it
> > controls who can
> > make reservations).
> >
> > Cheers,
> > Greig
> >
> >
> >
> > On 08/02/08 18:17, Brew, CAJ (Chris) wrote:
> > > Hi,
> > >
> > >> -----Original Message-----
> > >> From: Greig Alan Cowan [mailto:[log in to unmask]]
> > >> Sent: 08 February 2008 18:15
> > >> To: Brew, CAJ (Chris)
> > >> Cc: [log in to unmask]
> > >> Subject: Re: Help
> > >>
> > >> Hi Chris,
> > >>
> > >> I know this is very annoying, but keep perservering, you're
> > >> almost there!
> > >>
> > >> Did you make the change to the srm.batch file and restart the SRM?
> > >>
> > >> set context -c SpaceManagerDefaultRetentionPolicy REPLICA
> > >> set context -c SpaceManagerDefaultAccessLatency ONLINE
> > >
> > > Yes
> > >
> > >> Also, just to confirm, you have
> > >>
> > >> srmSpaceManagerEnabled=yes
> > >>
> > >> on the doors?
> > >
> > > and yes.
> > >
> > >> What error message are you getting when you try to copy a
> > >> file into the
> > >> dCache? Is it a no-space-available, or no-write-pool-selected ?
> > >
> > > No - No Write Pool configured
> > >
> > > heplnx108 - ~ $ lcg-cr -v --vo cms -d heplnx204.pp.rl.ac.uk
> > > file:/opt/ppd/scratch/brew/LoadTestSeed
> > > Using grid catalog type: lfc
> > > Using grid catalog : prod-lfc-cms-central.cern.ch
> > > Using LFN :
> > >
> > /grid/cms/generated/2008-02-08/file-26a0ea5f-3d85-465f-aee5-38
> > 37c7421a10
> > > Using SURL :
> > >
> > srm://heplnx204.pp.rl.ac.uk/pnfs/pp.rl.ac.uk/data/cms/generate
> > d/2008-02-
> > > 08/fileb25528c9-f146-4ab9-93a2-0a24cfd75ace
> > > Alias registered in Catalog:
> > >
> > lfn:/grid/cms/generated/2008-02-08/file-26a0ea5f-3d85-465f-aee
> > 5-3837c742
> > > 1a10
> > > Source URL: file:/opt/ppd/scratch/brew/LoadTestSeed
> > > File size: 2747015459
> > > VO name: cms
> > > Destination specified: heplnx204.pp.rl.ac.uk
> > > Destination URL for copy:
> > >
> > gsiftp://heplnx172.pp.rl.ac.uk:2811//pnfs/pp.rl.ac.uk/data/cms
> > /generated
> > > /2008-02-08/fileb25528c9-f146-4ab9-93a2-0a24cfd75ace
> > > # streams: 1
> > > # set timeout to 0 seconds
> > >             0 bytes      0.00 KB/sec avg      0.00 KB/sec
> > > instglobus_ftp_client: the server responded with an error
> > > 451 Operation failed: Non-null return code from
> > >
> > [>PoolManager@dCacheDomain:*@dCacheDomain:SrmSpaceManager@srmD
> > omain:*@sr
> > > mDomain:*@dCacheDomain] with error No write pools configured for
> > > <cms:cms@osm>
> > >
> > > Chris.
> > >
> > >> Cheers,
> > >> Greig
> > >>
> > >>
> > >> On 08/02/08 18:05, Brew, CAJ (Chris) wrote:
> > >>> Hi Greig,
> > >>>
> > >>> No luck for me I'm afraid.
> > >>>
> > >>> Though I suspect I'm doing something very stupid somewhere
> > >> since what
> > >>> you are saying fits with what I thought I had working for BaBar
> > >>> yesterday, i.e. that it worked if I set the directory tags
> > >> explicitly.
> > >>> But the after I ran a script* to walk the directory tree
> > >> and then tried
> > >>> to replicate the babar config to everyone else it stopped
> > >> working. I was
> > >>> beginning to think I was mistaken and hadn't actually got
> > the space
> > >>> manager switch on at that point
> > >>>
> > >>> Well here's my dCacheSetup file, PoolManager.conf and the
> > >> script I used
> > >>> incase someone can spot the daft mistake I've made.
> > >>>
> > >>> Chris.
> > >>> (going home to forget about srm!)
> > >>>
> > >>> *
> > >>> for group in `ls /pnfs/pp.rl.ac.uk/data`; do echo $group;
> > for dir in
> > >>> `find /pnfs/pp.rl.ac.uk/data/${group} -type d -print`; do
> > >> cd $dir;echo
> > >>> "ONLINE" > ".(tag)(AccessLatency)"; echo  "REPLICA" >
> > >>> ".(tag)(RetentionPolicy)"; done; done
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: GRIDPP2: Deployment and support of SRM and local
> > >>>> storage management [mailto:[log in to unmask]] On
> > >>>> Behalf Of Greig Alan Cowan
> > >>>> Sent: 08 February 2008 17:13
> > >>>> To: [log in to unmask]
> > >>>> Subject: Re: Help
> > >>>>
> > >>>> Hi Matt,
> > >>>>
> > >>>> How's it going? After I set up the pnfs tags, I've found
> > >> that I could
> > >>>> get the Space manager working without too many problems. My
> > >>>> PoolManager
> > >>>> and dCacheSetup are attached.
> > >>>>
> > >>>> For the reservation I did something like this:
> > >>>>
> > >>>> reserve -vog=/lhcb -vor=lhcbprd -acclat=ONLINE -retpol=REPLICA
> > >>>> -desc=LHCb_DST -lg=lhcb-linkGroup 24993207653 "-1"
> > >>>>
> > >>>> Note that there is a problem with (I think) gPlazma in
> > >> that it caches
> > >>>> user DNs for a short period. This means that if you try to
> > >> transfer a
> > >>>> file when belonging to one VO and then switch proxies to
> > >> another, you
> > >>>> are likely to get a permission denied error. Someone is
> > working on
> > >>>> fixing this.
> > >>>>
> > >>>> Cheers,
> > >>>> Greig
> > >>>>
> > >>>> On 08/02/08 15:19, Matt Doidge wrote:
> > >>>>> Helps if I attach the bloomin script doesn't it!
> > >>>>>
> > >>>>> Got that Friday feeling...
> > >>>>>
> > >>>>> Matt
> > >>>>>
> > >>>>> On 08/02/2008, Matt Doidge <[log in to unmask]> wrote:
> > >>>>>> Heya guys,
> > >>>>>>
> > >>>>>> Here's the python script that I was given by Dmitri
> > Litvinse that
> > >>>>>> recursively sets the AccessLatency and RetentionPolicy
> > >>>> tags in pnfs to
> > >>>>>> ONLINE and REPLICA. Usage is:
> > >>>>>>
> > >>>>>> set_tag.py --dir=/pnfs/wherever/data/vo/foo
> > >>>>>>
> > >>>>>> or to be careful about it cd to the directory and
> > >>>>>> /pathtoscript/set_tag.py --dir=`pwd`
> > >>>>>>
> > >>>>>> This took nearly 3 hours for my admittedly gargantuan
> > >>>> atlas directory,
> > >>>>>> so you're best off doing it in chunks. Oh and as a
> > >> disclaimer this
> > >>>>>> script comes with no gurantees, it was written for us as
> > >> a favour.
> > >>>>>> However doing this doesn't seem to have fixed our
> > troubles, srmv2
> > >>>>>> writes still work if you specify the space token but fail
> > >>>> if you don't
> > >>>>>> for dteam. I don't know about other VOs, as none of my
> > >>>> collegues seem
> > >>>>>> to be able to get a proxy today. I might have to fiddle with
> > >>>>>> permissions and pretend to be in other VOs to test.
> > >>>>>>
> > >>>>>> cheers,
> > >>>>>> Matt
> > >>>>>>
> > >>>>>> On 08/02/2008, Greig Alan Cowan <[log in to unmask]> wrote:
> > >>>>>>> Hi Matt,
> > >>>>>>>
> > >>>>>>> Yep, you are bang on. I just set the PNFS tags to
> > >>>> REPLICA-ONLINE and now
> > >>>>>>> it's all working. Seems to me that things have really
> > >>>> been setup to work
> > >>>>>>> for dCache's with HSM backends and not thinking about the
> > >>>> little guys.
> > >>>>>>> I'll report this in the deployment meeting that's
> > starting soon.
> > >>>>>>>
> > >>>>>>> $ echo ONLINE > ".(tag)(AccessLatency)"
> > >>>>>>> $ echo REPLICA > ".(tag)(RetentionPolicy)"
> > >>>>>>>
> > >>>>>>> Can you send round that script?
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>> Greig
> > >>>>>>>
> > >>>>>>> On 08/02/08 14:46, Matt Doidge wrote:
> > >>>>>>>> Heya guys,
> > >>>>>>>>
> > >>>>>>>> I've had similar experiances playing with Lancaster's
> > >>>> dcache- I can
> > >>>>>>>> get writes to work only if  I specify the token to write
> > >>>> into, if I
> > >>>>>>>> leave it unpsecified or try to use srmv1 I get "No Space
> > >>>> Available.
> > >>>>>>>> >From the logs of our experiments Dimitri and Timur have
> > >>>> concluded that
> > >>>>>>>> there's some confusion involving default space
> > >> settings. Despite
> > >>>>>>>> having set us to "REPLICA" and "ONLINE" in the
> > >>>> dCacheSetup writes into
> > >>>>>>>> our dcache with no write policies set (i.e. no token
> > >>>> specified) are
> > >>>>>>>> being made to look for a space which is "NEARLINE" and
> > >>>> "CUSTODIAL".
> > >>>>>>>> One fix suggested is to edit the srm.batch with:
> > >>>>>>>> set context -c SpaceManagerDefaultRetentionPolicy REPLICA
> > >>>>>>>> set context -c SpaceManagerDefaultAccessLatency ONLINE
> > >>>>>>>> (these were set wrong for us)
> > >>>>>>>>
> > >>>>>>>> And also Dmitri advised setting the policy tags in the pnfs
> > >>>>>>>> directories. Dmitri wrote a nice little python script to
> > >>>> do that, I
> > >>>>>>>> can forward it if you want, but be warned it took nearly
> > >>>> 3 hours for
> > >>>>>>>> it to get through our existing atlas directory. Luckily
> > >>>> it should only
> > >>>>>>>> ever have to be run once.
> > >>>>>>>>
> > >>>>>>>> I've set things up and am about to have a go at
> > >>>> switching the Space
> > >>>>>>>> Manager on without breaking our srm. Wish me luck.
> > >>>>>>>>
> > >>>>>>>> cheers,
> > >>>>>>>> Matt
> > >>>>>>>>
> > >>>>>>>> On 08/02/2008, Greig Alan Cowan <[log in to unmask]> wrote:
> > >>>>>>>>> Hi Chris, all,
> > >>>>>>>>>
> > >>>>>>>>> I've got the SRM2.2 transfers into a reserved space
> > >>>> working for the
> > >>>>>>>>> Edinburgh dCache.
> > >>>>>>>>>
> > >>>>>>>>> All I did was add a section to my PoolManager.conf file
> > >>>> that created a
> > >>>>>>>>> link group and added an existing dteam link to it, i.e.,
> > >>>>>>>>>
> > >>>>>>>>> psu create linkGroup dteam-linkGroup
> > >>>>>>>>> psu set linkGroup custodialAllowed dteam-linkGroup false
> > >>>>>>>>> psu set linkGroup replicaAllowed dteam-linkGroup true
> > >>>>>>>>> psu set linkGroup nearlineAllowed dteam-linkGroup false
> > >>>>>>>>> psu set linkGroup outputAllowed dteam-linkGroup false
> > >>>>>>>>> psu set linkGroup onlineAllowed dteam-linkGroup true
> > >>>>>>>>> psu addto linkGroup dteam-linkGroup dteam-link
> > >>>>>>>>>
> > >>>>>>>>> Nothing elsed changed in PoolManager.conf. In
> > >>>> dCacheSetup on the SRM
> > >>>>>>>>> node, I have
> > >>>>>>>>>
> > >>>>>>>>> srmSpaceManagerEnabled=yes
> > >>>>>>>>> srmImplicitSpaceManagerEnabled=yes
> > >>>>>>>>> SpaceManagerDefaultRetentionPolicy=REPLICA
> > >>>>>>>>> SpaceManagerDefaultAccessLatency=ONLINE
> > >>>>>>>>> SpaceManagerReserveSpaceForNonSRMTransfers=true
> > >>>>>>>>>
> > >>>> SpaceManagerLinkGroupAuthorizationFileName=/opt/d-cache/etc/Li
> > >>>> nkGroupAuthorization.conf
> > >>>>>>>>> It is also essential to have
> > >>>>>>>>>
> > >>>>>>>>> srmSpaceManagerEnabled=yes
> > >>>>>>>>>
> > >>>>>>>>> on all *door* nodes.
> > >>>>>>>>>
> > >>>>>>>>> I could then reserve a space in the newly created link
> > >>>> group using the
> > >>>>>>>>> "reserve" command line tool in the srmSpaceManager
> > >>>> cell. You can then
> > >>>>>>>>> test this with the latest dCache srmclient by doing
> > >>>> something like:
> > >>>>>>>>> srmcp -2 -debug file:////etc/group
> > >>>>>>>>>
> > >>>> srm://srm.epcc.ed.ac.uk:8443/pnfs/epcc.ed.ac.uk/data/dteam/gre
> > >>>> ig_test_dir/`date
> > >>>>>>>>> +%s` -space_token=1
> > >>>>>>>>>
> > >>>>>>>>> Where space_token=1 is the numerical value of the
> > space token
> > >>>>>>>>> reservation that you made.
> > >>>>>>>>>
> > >>>>>>>>> Transfers using SRMv1 are still returning that there
> > >> is no space
> > >>>>>>>>> available. I need to investigate further why this is.
> > >>>> I'll be in touch.
> > >>>>>>>>> Cheers,
> > >>>>>>>>> Greig
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On 07/02/08 17:41, Brew, CAJ (Chris) wrote:
> > >>>>>>>>>> (I'm guessing jiscmail should be up now)
> > >>>>>>>>>>
> > >>>>>>>>>> Are there any sites without a MSS backend that have
> > >>>> got this working?
> > >>>>>>>>>> Chris.
> > >>>>>>>>>>
> > >>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>> From: Greig Alan Cowan [mailto:[log in to unmask]]
> > >>>>>>>>>>> Sent: 07 February 2008 17:33
> > >>>>>>>>>>> To: [log in to unmask]
> > >>>>>>>>>>> Cc: cajbrew
> > >>>>>>>>>>> Subject: Re: Help
> > >>>>>>>>>>>
> > >>>>>>>>>>> Hi Guys,
> > >>>>>>>>>>>
> > >>>>>>>>>>> Sorry for my silence this afternoon, I've been at
> > >>>> CERN all week and
> > >>>>>>>>>>> that's me just back home now. I've got a working
> > >>>>>>>>>>> PoolManager.conf from
> > >>>>>>>>>>> FZK which I'm scrutinising. I'll be in touch
> > later/tomorrow
> > >>>>>>>>>>> in order to
> > >>>>>>>>>>> get you both up and running in SRM2.2 mode.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Cheers,
> > >>>>>>>>>>> Greig
> > >>>>>>>>>>>
> > >>>>>>>>>>> On 07/02/08 17:15, [log in to unmask] wrote:
> > >>>>>>>>>>>> It's a pain in the arse, I'm managing to get
> > some results,
> > >>>>>>>>>>> but writes
> > >>>>>>>>>>>> only work when the space token is implicity set in the
> > >>>>>>>>>>> srmPut and they
> > >>>>>>>>>>>> fail in every other case. And for some reason even if I
> > >>>>>>>>>>> only set up a
> > >>>>>>>>>>>> linkGroup for dteam I still seem to affect all
> > other VOs as
> > >>>>>>>>>>> soon as I
> > >>>>>>>>>>>> throw the SpaceManager on, and they get the "No
> > >>>> Space Availiable"
> > >>>>>>>>>>>> error.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> At least I'm seeing some progress I suppose- I can
> > >>>> technically get
> > >>>>>>>>>>>> SpaceTokens to work. It just means nothing else will.....
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Oh, and your cutdown arcane ritual does indeed seem
> > >>>> to work wonders-
> > >>>>>>>>>>>> but according to the dcache bods a restart of
> > >>>> doornodes (with the
> > >>>>>>>>>>>> edits to dCacheSetup on board) is advisable after
> > >>>> each change,
> > >>>>>>>>>>>> something to do with the door processes retaining
> > >>>>>>>>>>> infomation about the
> > >>>>>>>>>>>> SpaceManager stuff (to use the technical terms).
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> cheers,
> > >>>>>>>>>>>> Matt
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On 07/02/2008, cajbrew <[log in to unmask]> wrote:
> > >>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks I'm back up now.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> OK, my arcane ritual was a bit short than yours so
> > >>>> I'll share it:
> > >>>>>>>>>>>>> In dCacheSetup on the head node
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Reset
> > >>>>>>>>>>>>> srmSpaceManagerEnabled=no
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> and comment out:
> > >>>>>>>>>>>>> #srmImplicitSpaceManagerEnabled=yes
> > >>>>>>>>>>>>> #SpaceManagerDefaultRetentionPolicy=REPLICA
> > >>>>>>>>>>>>> #SpaceManagerDefaultAccessLatency=ONLINE
> > >>>>>>>>>>>>> #SpaceManagerReserveSpaceForNonSRMTransfers=true
> > >>>>>>>>>>>>>
> > >> #SpaceManagerLinkGroupAuthorizationFileName=/opt/d-cache/etc/L
> > >>>>>>>>>>> inkGroupAuthor
> > >>>>>>>>>>>>> ization.conf
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> In Poolmanager.conf file comment out all the LinkGroup
> > >>>>>>>>>>> configuration.
> > >>>>>>>>>>>>> Restart the dcache-core service on the head node.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I thought I had SrmSpaceManager working for a while.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I seemed to have a setup where it worked for babar but I
> > >>>>>>>>>>> could only write to
> > >>>>>>>>>>>>> directories where I had explicitly set the AccessLatency
> > >>>>>>>>>>> and RetentionPolicy
> > >>>>>>>>>>>>> using:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> echo  "ONLINE" > ".(tag)(AccessLatency)"; echo
> > >> "REPLICA" >
> > >>>>>>>>>>>>> ".(tag)(RetentionPolicy)"
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> But when I restarted to rty to replicate the
> > config to CMS
> > >>>>>>>>>>> and test it from
> > >>>>>>>>>>>>> there it stopped working even for BaBar. Now whatever I
> > >>>>>>>>>>> try I cannot get
> > >>>>>>>>>>>>> writes working with SrmSpaceManager enabled.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> The trouble is we cannot test this without taking dCache
> > >>>>>>>>>>> effectively offline
> > >>>>>>>>>>>>> for everyone.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>> Chris.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> -----Original Message-----
> > >>>>>>>>>>>>>> From: [log in to unmask]
> > >> [mailto:[log in to unmask]]
> > >>>>>>>>>>>>>> Sent: 07 February 2008 13:39
> > >>>>>>>>>>>>>> To: cajbrew
> > >>>>>>>>>>>>>> Cc: [log in to unmask]
> > >>>>>>>>>>>>>> Subject: Re: Help
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> When we broke our dcache with the SpaceManager we found
> > >>>>>>>>>>> that in order
> > >>>>>>>>>>>>>> to get things working again we had to:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Cross fingers.
> > >>>>>>>>>>>>>> Get rid of all the linkGroups in the
> > >>>> PoolManager.conf (or at least
> > >>>>>>>>>>>>>> remove all the links from them).
> > >>>>>>>>>>>>>> Set dcacheSetup to have SpaceManager disabled on
> > >>>> the srm and
> > >>>>>>>>>>>>>> all the door nodes
> > >>>>>>>>>>>>>> Rerun install.sh on srm node(I'm not sure if this
> > >>>> is totally
> > >>>>>>>>>>>>>> nessicery, but it seems to do the trick)
> > >>>>>>>>>>>>>> Restart the srm node.
> > >>>>>>>>>>>>>> Restart the door nodes.
> > >>>>>>>>>>>>>> Throw holy water at your nodes till the the
> > SpaceManager
> > >>>>>>>>>>>>>> leaves them be.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> It's a bloody lot of hassle I tell you. To be
> > honest half
> > >>>>>>>>>>> those steps
> > >>>>>>>>>>>>>> might be unnessicery, but I'm not sure which
> > half so I'll
> > >>>>>>>>>>> keep this
> > >>>>>>>>>>>>>> arcane ritual.
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> I'm totally stuck with the whole SpaceToken thing,
> > >>>> after countless
> > >>>>>>>>>>>>>> emails with attached configs and logs I've had
> > to go and
> > >>>>>>>>>>> give access
> > >>>>>>>>>>>>>> to our dcache to Dmitri so he can have a good
> > poke- which
> > >>>>>>>>>>> goes against
> > >>>>>>>>>>>>>> some University rules so I'm having to be a
> > bit hush hush
> > >>>>>>>>>>> about it.
> > >>>>>>>>>>>>>> Hopefully he's not filling my SRM with naughty
> > >>>> pictures, and finds
> > >>>>>>>>>>>>>> some way to get us working that I can spread
> > to the other
> > >>>>>>>>>>> UK dcaches.
> > >>>>>>>>>>>>>> Hope this gets your dcache up and running again,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Matt
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 07/02/2008, cajbrew <[log in to unmask]> wrote:
> > >>>>>>>>>>>>>>> Hi Grieg, Matt
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> (The Atlas center has lost power so my work
> > mail and the
> > >>>>>>>>>>>>>> maillist are all
> > >>>>>>>>>>>>>>> down)
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I'm trying to enable space tokens but seem to
> > >>>> have run into
> > >>>>>>>>>>>>>> the same problem
> > >>>>>>>>>>>>>>> as Matt.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> When I try to transfer some data in I get:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> heplnx101 - ~ $ lcg-cr -v --vo babar -d
> > >>>> heplnx204.pp.rl.ac.uk -P
> > >>>>>>>>>>>>>>> testfile.brew file:/opt/ppd/scratch/brew/LoadTestSeed
> > >>>>>>>>>>>>>>> Using grid catalog type: lfc
> > >>>>>>>>>>>>>>> Using grid catalog : lfcserver.cnaf.infn.it
> > >>>>>>>>>>>>>>> Using LFN :
> > >>>>>>>>>>>>>>>
> > >>>> /grid/babar/generated/2008-02-07/file-de6e10d4-db82-4658-8dd7-
> > >>>>>>>>>>>>>> 5b0390c4e8cc
> > >>>>>>>>>>>>>>> Using SURL :
> > >>>>>>>>>>>>>>>
> > >>
> > srm://heplnx204.pp.rl.ac.uk/pnfs/pp.rl.ac.uk/data/babar/testfile.brew
> > >>>>>>>>>>>>>>> Alias registered in Catalog:
> > >>>>>>>>>>>>>>>
> > >>>> lfn:/grid/babar/generated/2008-02-07/file-de6e10d4-db82-4658-8
> > >>>>>>>>>>>>>> dd7-5b0390c4e8
> > >>>>>>>>>>>>>>> cc
> > >>>>>>>>>>>>>>> Source URL: file:/opt/ppd/scratch/brew/LoadTestSeed
> > >>>>>>>>>>>>>>> File size: 2747015459
> > >>>>>>>>>>>>>>> VO name: babar
> > >>>>>>>>>>>>>>> Destination specified: heplnx204.pp.rl.ac.uk
> > >>>>>>>>>>>>>>> Destination URL for copy:
> > >>>>>>>>>>>>>>>
> > >>>> gsiftp://heplnx172.pp.rl.ac.uk:2811//pnfs/pp.rl.ac.uk/data/bab
> > >>>>>>>>>>>>>> ar/testfile.br
> > >>>>>>>>>>>>>>> ew
> > >>>>>>>>>>>>>>> # streams: 1
> > >>>>>>>>>>>>>>> # set timeout to 0 seconds
> > >>>>>>>>>>>>>>>             0 bytes      0.00 KB/sec avg
> > >> 0.00 KB/sec
> > >>>>>>>>>>>>>>> instglobus_ftp_client: the server responded
> > >> with an error
> > >>>>>>>>>>>>>>> 451 Operation failed: Non-null return code from
> > >>>>>>>>>>>>>>> [>PoolManager@dCacheDomain:*@dCacheDomain]
> > with error No
> > >>>>>>>>>>> write pools
> > >>>>>>>>>>>>>>> configured for <babar:babar@osm>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Unfortunately when I try to back out and set
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> srmSpaceManagerEnabled=no
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> I still get the same error.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> So I now seem to be stuck, I cannot go
> > forwards or back.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> No, actually I've gone further back and
> > >> commented out all
> > >>>>>>>>>>>>>> the LinkGroup
> > >>>>>>>>>>>>>>> setting s in PoolManager.conf and I can at
> > >> least transfer
> > >>>>>>>>>>>>>> data in with both
> > >>>>>>>>>>>>>>> srmv1 and srmv2
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> So has Lancaster solved this or are we both in
> > >>>> the same boat?
> > >>>>>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>>>>> Chris.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> >
>