How can you sync an srm contents with a grid file catalog? A file in a
SRM could be in any file catalog around the world? unless you have a
list of all catalogs that an experiment has around the world, how can
you tell if the reason that a file is not in a catalog is because of a
sync problem or just that you are looking at an incorrect catlaog?
Brian
On 06/07/06, Kostas Georgiou <[log in to unmask]> wrote:
> On Thu, Jul 06, 2006 at 11:24:09AM +0100, Owen Synge wrote:
>
> > On Thu, 6 Jul 2006 09:32:51 +0100
> > Greig A Cowan <[log in to unmask]> wrote:
> >
> > > Hi Andrew,
> > >
> > > > Does dCache's SRM check that the box hosting the pool is online
> > > > when the SRM answers a query about one of its files? ie is the
> > > > issue about not using resilient dCache just that a box/pool
> > > > could go offline, or that plus the danger that the SRM will be
> > > > falsely claiming to have files that are now offline?
> > >
> > > Like Derek has said already, if dCache can't get a file from an online
> > >
> > > pool, it expects to be able to get it from tape or for an offline pool
> > >
> > > to become available again.
> >
> > This is in my understanding also, I personally don't like the NFS model
> > of blocking and locking the file system until it comes on line again. I
> > prefer the idea of failing with an error quickly. The problem is the
> > streaming POSIX model does not have space for presenting a currently
> > unavailable file system that may come back and POSIX is a widely used
> > standard. Because of this code developed against POSIX IO does not have
> > checks for media changing to off line. SRM's though don't have such
> > history and share nearly no state between client and server so could
> > fail rather than block.
> >
> > I have to support the (gsi)pnfs, (I assume rfio also) POSIX layer
> > blocking as they need to map to current expectations for a POSIX layer
> > and behave in the same way as NFS.
>
> POSIX does not require you to block, nfs for example (not that it's posix
> compliant) has the soft mount option that will give you an I/O error in case
> of a timeout. You can (if it's sensible to do so is another matter) just send
> an I/O error (return EIO) if the file somehow disappears (because the pool is
> down or whatever).
>
> Kostas
>
|