The files are statically placed by a distributed disk
system I presented at one or the other CHEP. Works fine but
sucks to actually do that statically (so one possible advantage
of Xrootds goal #3 leading to dynamic population). The diverse
partitions are not fixed i.e. some node may have one more more
but not all (or all) of the mentionned partitions. The path is
HPSS is /home/starreco/XXX while on local disk it is /YYY/XXX
where /YYY is /?/starlib "?" standing for one of data0, data1,
data2 or home. Of course, if I could map /home/starreco/XXX
to /?/starlib/XXX that would surely help reducing the namespace
(replica Catalog) down to nothing (goal #2).
No SRM involved at this stage (SRM manages big gatekeeper
local storage or NFS based cache, not the 200 nodes storage ...
yet). This would be goal #4 (or a variant).
> in a multi experiment setup, I "tricked" the system by using soft
> links, making one single filesystem being visible using two different
> prefix, but I don't think this is exactly what you want in your
> particular case.
Jean Yves, I can play tricks using soft-links of
directories and use /home only, I think (this is the only
one which is more or less always present although may be
a soft-link itself to another FS). Looking for the best way
to do that ...
> AFAIK, there is no simple directive or soft link trick for that. The
> best bet is the cache filesystem, see the mps/cache-filesystem doc:
>
> http://xrootd.slac.stanford.edu/doc/mps_config/mps_config.htm
... and as far as I understand the presence of multiple
disks on one node along with purge/migration and MPS component
is possible (??!) In your figure /kanga and /cache0, /cache1 etc ..
is /kanga "populated" by links to the cache(s) ??
Thanks,
,,,,,
( o o )
--m---U---m--
Jerome
PS : Is there a problem in setting the Reply-to of this list to
be the list itself ?? I receive duplicate Emails for about
every post since poeople use 'Reply-all' to cope for Reply-to,
From discrepencies.
Peter Elmer wrote:
> Hi Jerome,
>
> On Mon, Feb 28, 2005 at 11:24:18AM -0500, Jerome LAURET wrote:
>
>> I beleive we asked how to do that at some point (hide the path
>> arranegement) except that we could not figure out on how to mix
>> /home and /data into a single substitution. Your case of
>> oss.localroot /kanga and oss.remoteroot /kanga or /xrootd at SLAC
>> ar a bit too convenient. Can we trick olb with soft-link or there
>> is a simple syntax which can take care of all /data + /home (the
>> path afterward is all and the same) ??
>
>
> I guess there is nothing special to differentiate the 4 partitions
> {/data0, /data1, /data2, /home}? i.e. all files can in principle go
> on any of the 4 partitions?
>
> AFAIK, there is no simple directive or soft link trick for that. The
> best bet is the cache filesystem, see the mps/cache-filesystem doc:
>
> http://xrootd.slac.stanford.edu/doc/mps_config/mps_config.htm
>
> What currently manages the data on those partitions? Has it just been
> statically placed there or is it being actively managed/staged by
> something? (SRM?)
>
> Pete
>
>
>> Peter Elmer wrote:
>>
>>
>>> Hi Pavel,
>>>
>>> On Sun, Feb 27, 2005 at 01:05:46PM +0100, Pavel Jakl wrote:
>>>
>>>
>>>> we are using in our conf files export multiple directories and
>>>> all data
>>>
>>>> from these directives are accessible:
>>>
>>>> xrootd.export /data0 xrootd.export /data1 xrootd.export /data2
>>>> xrootd.export /home
>>>
>>>
>>> Hmm, you are probably right: perhaps this was something that Andy
>>> fixed at some point? I see Matt is using the xrootd version from
>>> ROOT 4.02-00 itself (i.e. 20041124-0752). What version are you
>>> running at BNL?
>>>
>>> Matt, could you try the latest "development" version
>>> 20050226-0852? This is a development version, but the one we are
>>> currently testing to become the next "production" version.
>>>
>>> (Unfortunately it looks like we got one of the intermediate
>>> development versions of the xrootd server itself into the
>>> production version of ROOT! It is no big deal to download and
>>> build the proper version of the server separately, but we'll need
>>> to be careful in the future to make sure only production versions
>>> of xrootd wind up in production versions of ROOT...)
>>>
>>>
>>>
>>>> I also enlose the log file from redirector where you can see,
>>>> that files (from /data1 and data2) are located and redirected
>>>> to right node without using cache file system.
>>>>
>>>> 050227 12:14:22 28868 odc_Locate: user=starlib.782:12@rcas6002
>>>> redirected to rcas6067.rcf.bnl.gov:1095 by xrdstar
>>>> path=/data2/starlib/reco/productionCentral/FullField/P02ge/2001/318/st_physics_2318037_raw_0012.MuDst.root
>>>> 050227 12:14:22 28868 odc_Receive: Server: Received from
>>>> xrdstar.rcf.bnl.gov: 481 !try rcas6067.rcf.bnl.gov:1095 050227
>>>> 12:14:22 28868 odc_Locate: user=starlib.782:12@rcas6002
>>>> redirected to rcas6067.rcf.bnl.gov:1095 by xrdstar
>>>> path=/data2/starlib/reco/productionCentral/FullField/P02ge/2001/318/st_physics_2318037_raw_0008.MuDst.root
>>>>
>>>
>>>
>>> I guess the "/data2", etc. is left from your previous method of
>>> finding the files? In general we try to hide that from the user
>>> (since it is an internal detail of the server-side) with some
>>> combination of the cache filesystem and the use of the
>>> "localroot" directive.
>>>
>>> Pete
>>>
>
>
>
> -------------------------------------------------------------------------
> Peter Elmer E-mail: [log in to unmask] Phone: +41 (22)
> 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva
> 23, Switzerland
> -------------------------------------------------------------------------
>
--
