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 >> >> >>