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
> ==============================================================
> ==========
>
|