Hi Fabrizio,
Thanks for the information, but my problem seems to be more generic. I
am trying to make sure that I understand the XROOTD_VMP variable. Using
"ls" for a single file is just my way to test the posix preload
mechanism. I adjusted my example usage to talk directly with a dataserver.
The xrdcp command can copy a specific file from a dataserver via:
xrdcp root://host:port//xrd/test1/100mb /tmp/test
However, using the following does not work for "ls":
export XROOTD_VMP='host:port:/xroot/=/xrd/'
export LD_LIBRARY_PATH=/opt/xrootd/lib/
export LD_PRELOAD=/opt/xrootd/lib/libXrdPosixPreload.so
ls /xroot/test1/100mb
ls root://host:port//xrd/test1/100mb
I don't see any traffic (via tcpdump) between the client and the data
server.
I have also tried "host:port:/xrd" as the XROOTD_VMP.
Patrick
Fabrizio Furano wrote:
> Hi Patrick,
>
> are you using it towards an xrootd cluster or a single server? I
> suppose the former, since you speak about a redirector.
>
> The point is that an xrootd cluster is not a file system from the
> semantic point of view. It is a file access system, i.e. a very fast and
> scalable thing where you put/get files. The overall architecture
> stresses this concept to achieve performance and scalability.
>
> So, ls gives a meaningful output only for the single server case, where
> actually you have a unique file system behind.
>
> The posix preload stuff simply translates the calls (and ls is just one
> of them) at the client side, but if your application desperately needs a
> file system-like semantic (e.g. a working ls), this is not sufficient.
> In the xrootd world, dirlist (i.e. ls) works only in the local fashion,
> locally to the server you are connected to, the redirector in your case.
> And the redirector has no files.
>
> This is the reason why some people around is (alpha) using the thing we
> call CNSd and the FUSE module, i.e. a thing which can fake
> file-system-like primitives like ls, and allows you to mount xrootd
> clusters.
>
> In general, being ls a generically non scalable primitive, it's just
> better if your applications do not rely on that. And we have just to
> keep in ming that the more we get closer (with particular sophisticated
> setups) to filesystem-like semantics, typically the more we well get
> closer to filesystem-like scalability, i.e. an order of magnitude less
> than what you can expect from a pure xrootd cluster setup.
>
>
> Fabrizio
>
>
> Patrick McGuigan wrote:
>> Hi,
>>
>> Now that I have an libXrdPosixPreload.so to use, I am running into
>> problems getting this to work. I am trying to set it up to support a
>> gridftp server but I thought I would first start with a presumably
>> simpler case. I just want to use "ls" against a file. The README
>> file for XrdPosix implies that this should work.
>>
>> I have a file available in the name space that can be copied back to
>> the client machine, via our redirector:
>>
>> [mcguigan@gk01 ~]$ /opt/xrootd/bin/xrdcp
>> root://xrdb.local:1094//xrd/test1/100mb /tmp/wood
>> [xrootd] Total 95.37 MB |====================| 100.00 % [115.2 MB/s]
>>
>>
>>
>> I created the following xrdrun.sh file:
>>
>> #!/bin/sh
>> export XROOTD_VMP='xrd.local:1094:/xroot/=/xrd/'
>> export LD_LIBRARY_PATH=/opt/xrootd/lib/
>> export LD_DEBUG=libs
>> export LD_PRELOAD=/opt/xrootd/lib/libXrdPosixPreload.so
>> export XRDPOSIX_DEBUG=3
>> $*
>>
>> Shouldn't this allow me to do:
>> ./xrdrun.sh ls /xroot/test1/100mb
>> ./xrdrun.sh ls root://xrdb.local:1094//xrd/test1/100mb
>>
>>
>> I receive the message "No such file or directory error" from the ls.
>>
>> With the LD_DEBUG statement I can see that the pre-load library is
>> being loaded and initialized just prior to ls being loaded. Also, if
>> I malform the VMP environment varialble, I will get an Invalid map
>> message from XrdPosix. I don't get any information by setting
>> XRDPOSIX_DEBUG.
>>
>> Should this work?
>>
>> How can I debug this? I tried rebuilding the XrdPosix libraries with
>> a couple of very simple output statements in XrdPosixXrootPath::URL
>> but I get seg faults when I try to use them.
>>
>> I am working on SL4.5 X86_64.
>>
>> Any advice is greatly appreciated.
>>
>> Patrick
>>
>>
>>
|