[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Objy/ROOT discussion at today's phone meeting



> >   Can anyone allay my concerns?  Does anyone else share them?
> I'm convinced! I share your concern

I also share these concerns.  Using the Objy catalog for the
ROOT file catalog can be coerced to work for MDC2 but
is certainly not a good long term solution (where long term
can be quite short).
Another weak spot is assuming that all files are in
a single HPSS directory.  This is not very useful for
real data, but also can be coerced to work in MDC2
because of the ability to make links in HPSS
by using HSI.  I did some looking around about a month
ago for "file catalog" ideas but did not really find anything.
A file catalog that maintains file ID's as well as pathname
mappings for HPSS and disk locations does not seem like a
particularly difficult database application, but I did not
find an implementation.

Doug

> -----Original Message-----
> From: Torre Wenaus [mailto:wenaus@bnl.gov]
> Sent: Thursday, December 17, 1998 12:46 PM
> To: David M. Malon
> Cc: challenge@sseos.lbl.gov; hnordberg@lbl.gov
> Subject: Re: Objy/ROOT discussion at today's phone meeting
>
>
> >   Can anyone allay my concerns?  Does anyone else share them?
> I'm convinced! I share your concern
>
> "David M. Malon" wrote:
> >
> > >
> > >  This is what I understood of the usage of ROOT for MDC2:
> > >
> > >  * Storage Manager will not be affected.
> > >  * ROOT will contain some event components.
> > >  * SM will provide Objy OID's and FID's and it's up to codes
> to find out
> > >  what files to look for the events in. I.e., the codes will
> do the FID to
> > >  ROOT file name mapping.
> > >  * Objy's catalog for mapping of FID to filename will be used for ROOT
> > >  files too.
> > >
> > >  Comments?
> > >  _________________________________________
> > >  Henrik Nordberg       <hnordberg@lbl.gov>
> > >  Scientific Data Management Research Group
> > >  Lawrence Berkeley National Laboratory
> > >
> >
> >    This is my understanding as well, with the clarification that the SM
> >    will ALSO be a client of the FID-to-filename mapping, so that the
> >    Cache Manager can deliver the correct files by the time the user code
> >    tries to reach them.
> >
> >    I am not yet comfortable with the proposed approach to generating
> >    FIDs for ROOT files, but Henrik's text does correctly describe the
> >    current proposal.  I have no objection to having Objectivity manage
> >    the FID-to-name mapping; it's the consumption of Objectivity DB ids
> >    (there are only 64K of them available--scalability implications?) and
> >    faking Objectivity into believing that ROOT files are
> federation databases
> >    (implications for database administration operations (install,
> >    attach/detach, copy, ...?) that still bother me.  (Some
> Objectivity tools
> >    check whether an alleged database file is really an
> Objectivity database.)
> >    There are certainly other ways to generate unique FIDs
> between ROOT and
> >    Objectivity, as well as other ways to let Objectivity manage
> the mapping.
> >
> >    I realize that the proposed approach will probably be okay for MDC2.
> >    Scalability, though, is the GCA's raison d'etre, so I am reluctant to
> >    deceive Objectivity in a way that may diminish scalability
> unless there
> >    is a good reason for it.
> >
> >    Can anyone allay my concerns?  Does anyone else share them?
> >
> >    Cheers,
> >
> >    David
>
> -- Torre Wenaus, BNL     wenaus@bnl.gov    516-344-4755  Fax
> 516-344-4206 --
> -- STAR Experiment, RHIC@BNL  Computing and software project
> leader       --
> -- B. 510A Room 1-175
> http://www.rhic.bnl.gov/STAR/computing.html --
> --
>            http://www.wenaus.com/torre.html            --
>