Hi Chris,
OK, so we had the answer all along, just it was applied to the wrong mount
point. I'm a bit confused though since I don't have that /pnfs/pnfsdoors
mount on my system, only the /pnfs/fs one that exists in /etc/fstab. Does
the pnfsdoors one always exist, even after a restart?
Cheers,
Greig
On Wed, 31 May 2006, Brew, CAJ (Chris) wrote:
> Hi Greig,
>
> I got a fix from the dcache user-forum. Turns out it was almost the
> first thing I thought of mount options on the pnfs areas but I got it
> the wrong way round, I'd tried making the mount options on /pnfs/fs
> (which is mounted from /etc/fstab) look like those on /pnfs/pnfsdoors
> (which is mounted by something else) but I should have remounted
> /pnfs/pnfsdoors with the same options and /pnfs/fs (specifically noac).
> I'll probably add the noatime and nodiratime as well just to future
> proof myself but things seem to be working again.
>
> Thanks,
> 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 16:22
> > To: [log in to unmask]
> > Subject: Re: FW: 'Not a PNFS File, can't get a PNFS ID' error
> >
> > 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
> > ==============================================================
> > ==========
> >
>
--
=======================================================================
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
=======================================================================
|