There's also this
http://www.dcache.org/archive/user-forum/0239.shtml
about moving PNFS to a different host. It may actually be easier to leave
PNFS where it is and move all of the other dCache services to a different
host, that way you can leave the postgreSQL database where it is.
Cheers,
Greig
On Wed, 31 May 2006, Brew, CAJ (Chris) wrote:
> Hi,
>
> Yes, I'm running the gridftpdoor on the Admin node. Sacrificing speed
> for reliability.
>
> Chris
>
> > -----Original Message-----
> > From: GRIDPP2: Deployment and support of SRM and local
> > storage management [mailto:[log in to unmask]] On
> > Behalf Of Greig A Cowan
> > Sent: 31 May 2006 11:03
> > To: [log in to unmask]
> > Subject: Re: FW: 'Not a PNFS File, can't get a PNFS ID' error
> >
> > Owen, do you think it would be possible for you to raise this
> > issue with the dCache team while you are visiting DESY? It is
> > very strange behaviour and Chris has performed some good work
> > in tracking down what the problem appears to be.
> >
> > Chris, I noticed yesterday that you passed all of the SFTs
> > over the weekend. Has something else changed in your dCache
> > configuration?
> >
> > Cheers,
> > Greig
> >
> >
> > On Wed, 31 May 2006, Coles, J (Jeremy) wrote:
> >
> > > Hi Chris
> > >
> > > You raised this problem and it seems people agree that this is not
> > > normal behaviour! I had hoped this response would be more
> > useful but
> > > the reply is simply to raise this to [log in to unmask] I
> > also copy
> > > in the storage group in case they have anything to add/suggest.
> > >
> > > Cheers,
> > > Jeremy
> > >
> > > -----Original Message-----
> > > From: Maite Barroso Lopez [mailto:[log in to unmask]]
> > > Sent: 30 May 2006 16:55
> > > To: Strange, PJ (Philippa); Coles, J (Jeremy)
> > > Subject: 'Not a PNFS File, can't get a PNFS ID' error
> > >
> > > Hello,
> > >
> > > Regarding the following issue reported by one site in your ROC
> > > (UKI-SOUTHGRID-RALPP):
> > >
> > > Radom SFT-RM failures with 'Not a PNFS File, can't get a PNFS ID'
> > > error have occured previously as detailed in previous
> > reports but we
> > > much more frequent this week. It appears that increasing
> > the number of
> > > supported VOs and so PNFS databases to 24 has tripped the
> > balance from
> > > occasional failures to almost continuous failures. Further
> > > investigation indicated that copying a file to a the SE and
> > imediately
> > > trying to access or replicate it (as the SFT does) causes
> > this error,
> > > waiting 15-20secs after the file creation seems to allow
> > the database
> > > updates to occur fully and avoids the problem. Runinng the
> > gridftpdor
> > > on the admin node also solves the problem at the expense of
> > > significantly slower transfers. We're investigating database tuning
> > > and/or the possibility of running PNFS on a separate host
> > hoping that'll fix the problem.
> > >
> > > It was discussed at the operations meeting and noted that
> > this seems
> > > unusual behavior, not seen in other places.
> > > Could you please, contact [log in to unmask] and send all available
> > > details so they can investigate the problem?
> > >
> > > Thanks in advance,
> > >
> > > Maite
> > >
> >
> > --
> > ==============================================================
> > ==========
> > Dr Greig A Cowan
> > http://www.ph.ed.ac.uk/~gcowan1
> > School of Physics, University of Edinburgh, James Clerk
> > Maxwell Building
> >
> > TIER-2 STORAGE SUPPORT PAGES:
> > http://wiki.gridpp.ac.uk/wiki/Grid_Storage
> > ==============================================================
> > ==========
> >
>
--
=======================================================================
Dr Greig A Cowan http://www.ph.ed.ac.uk/~gcowan1
School of Physics, University of Edinburgh, James Clerk Maxwell Building
TIER-2 STORAGE SUPPORT PAGES: http://wiki.gridpp.ac.uk/wiki/Grid_Storage
=======================================================================
|