 |
 |
Hi Manny and Chris, You've probably already thought about these problems, but I thought I should bring them up just in case... I guess XrdMSSStat.pl uses the ADS "datastore query" command to find out whether the file exists. xrootd also asks for the file size, but that can only be determined approximately (without reading the file from tape), since the ADS only stores the number of (roughly 4096-byte) "pages" (OK, it does store some other information that might allow the accurate file size to be determined, but I didn't find a reliable method). Does xrootd need the accurate file size? The mapping onto other "ls -l" fields (eg. file mode) is also rudimentary, and directories probably aren't supported at all. This is presumably a problem for any MSS without a full metadata catalogue. Tim. > -----Original Message----- > From: [log in to unmask] > [mailto:[log in to unmask]] On Behalf Of > Chris Brew > Sent: 14 September 2004 17:02 > To: Jean-Yves Nief > Cc: Emmanuel Olaiya; [log in to unmask] > Subject: Re: Problem interfacing MPS with the MSS > > > Hi Manny, > > An example of the perl code that needs to be called but the xrootd > server for the statx is in ~bbdatsrv/bin/XrdMSSStat.pl from the look > of it you may need to combine that with the XrdMSSGet.pl to provide a > single interface to both the "statx" and "get" calls. > > Yours, > Chris. > > On Tue, 14 Sep 2004, Jean-Yves Nief wrote: > > > hello Manny, > > > > Emmanuel Olaiya wrote: > > > > > Hi Jean-Yves > > > > > > Using the trace all directive has helped. In at least I > can now see > > > the problem. I now see in the log file: > > > > > > 040914 14:06:30 8052 XrootdXeq: User logged in as > olaiya.20722:14@csfe > > > 040914 14:06:30 8052 olaiya.20722:14@csfe oss_Open_ufs: > fd=512 flags=0 > > > mode=0 > > > > path=/stage/bdata-data38/kanga/store/PRskims/R14/14.4.3d/BCCC0 > 3a3body/15/Manny_test.01.root > > > > > > 040914 14:06:31 8052 XrdLink: olaiya.20722:14@csfe > disconnected after > > > 0:00:01 > > > 040914 14:06:42 8041 XrootdXeq: User logged in as > olaiya.20727:14@csfe > > > 040914 14:06:42 8041 olaiya.20727:14@csfe oss_Open_ufs: > fd=-2 flags=0 > > > mode=0 > > > > path=/stage/bdata-data38/kanga/store/PRskims/R14/14.4.3d/BCCC0 > 3a3body/15/Manny_test2.01.root > > > > > > 040914 14:06:42 8041 oss_MSS_Xeq: sending to mss > > > '/home/csf/bbdatsrv/bin/MSSGet.pl statx > > > /store/PRskims/R14/14.4.3d/BCCC03a3body/15/Manny_test2.01.root' > > > 040914 14:06:42 8049 oss_MSS_Gateway: received > > > '/home/csf/bbdatsrv/bin/MSSGet.pl statx > > > /store/PRskims/R14/14.4.3d/BCCC03a3body/15/Manny_test2.01.root' > > > 040914 14:06:42 8041 oss_MSS_Xeq: received 'ub1017 * > > > /store/PRskims/R14/14.4.3d/BCCC03a3body/15/Manny_test2.01.root' > > > 040914 14:06:42 8041 oss_XrdOssMSS_Xeq: Unable to execute statx > > > /store/PRskims/R14/14.4.3d/BCCC03a3body/15/Manny_test2.01.root; > > > invalid response from mass storage system interface > > > 040914 14:06:42 8041 ofs_open: olaiya.20727:14@csfe > Unable to open > > > /store/PRskims/R14/14.4.3d/BCCC03a3body/15/Manny_test2.01.root; > > > invalid response from mass storage system interface > > > 14/09 14:06:42 tape: Unable to open file > > > > /store/PRskims/R14/14.4.3d/BCCC03a3body/15/Manny_test2.01.root for > > > writing > > > 040914 14:06:42 8041 XrdLink: olaiya.20727:14@csfe > disconnected after > > > 0:00:00 > > > Failed to read file to tape ub1017 at > > > /home/csf/bbdatsrv/bin/MSSGet.pl line 21 > > > > > > Though I'm not too sure what statx is and where it comes from? > > > > statx return stat information on a file or a dir stored in your MSS > > (last access time, modify time etc....). > > you should have a statx functionality in your perl script: MSSGet.pl > > so when you call "MSSGet.pl statx <filename>",, it should > return all the > > stat information in a format which should be the one you > find in the > > xrootd documentation (oss.mssgwcmd) and that your xrootd daemon is > > expecting. > > cheers, > > JY > > > > > > > > cheers > > > > > > Manny > > > > > > > > > Jean-Yves Nief wrote: > > > > > >> Emmanuel Olaiya wrote: > > >> > > >>> Hi Jean-Yves > > >>> > > >>> Thanks, I didn't have this directive but I have added > it now. Though > > >>> the data is still not being staged. Does anyone know > where to look > > >>> in order to monitor the mps status? > > >> > > >> > > >> > > >> I forgot to tell you that you also need: > > >> oss.path /store mig > > >> and that should make it. > > >> it fou still encounter problems, you can use: > > >> oss.trace all > > >> in order to a better traing of the problem in the log file. > > >> cheers, > > >> JY > > >> > > >>> > > >>> cheers > > >>> > > >>> Manny > > >>> > > >>> PS. Pete, when you bounce my original mail to this > list, I also > > >>> didn't recieve a copy via it. > > >>> > > >>> Jean-Yves Nief wrote: > > >>> > > >>>> hello Manny, > > >>>> > > >>>> do you have the following directive in > your config > > >>>> files ? > > >>>> for the load balancer on the data servers: > > >>>> olb.path rs <what ever path you need, eg: /store> > > >>>> s means that the file in this file system can be staged. > > >>>> hope this help. > > >>>> cheers, > > >>>> JY > > >>>> > > >>>> Emmanuel Olaiya wrote: > > >>>> > > >>>> > > >>>> > > >>>>> *** Discussion title: KanSOS > > >>>>> Email replies to [log in to unmask] must include: > > >>>>> In-Reply-To: <[log in to unmask]> > > >>>>> Subject: ...change this to be about your reply. > > >>>>> > > >>>>> Hi > > >>>>> > > >>>>> I'm having problems interfacing MPS with the MSS at > RAL and was > > >>>>> wondering if anyone has any ideas that could help me. > I have a > > >>>>> script to retrieve data > > >>>>> from our MSS at RAL (MSSGet.pl). This works well > with mps_stage > > >>>>> on the > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > >>>>> command line. I'm now trying to set this up within > the xrootd.cf > > >>>>> config > > >>>>> file. I have added the following lines to the config > file on a > > >>>>> server machine > > >>>>> > > >>>>> mps.stage.xfrcmd /opt/xrootd/utils/mps_Stage > > >>>>> mps.stage.msscmd /home/csf/olaiya/testspace/area1/MSSGet.pl > > >>>>> > > >>>>> However when I ask for a file that is in the MSS but > not on disk > > >>>>> it does not get staged. Is there any other directives > that people > > >>>>> believe I should add to the config file? > > >>>>> > > >>>>> When I restart xrootd and oldb on the dataserver I > see all the ofs > > >>>>> and oss directives printed out in the xrdlog file. I > don't see any > > >>>>> of my mps > > >>>>> directives printed here which makes me think they aren't > > >>>>> interfaced. Am I supposed to see the directives here > or is there a > > >>>>> separate log file where I can monitor mps output? > This is the tail > > >>>>> end of my xrdlog: > > >>>>> > > >>>>> ofs.authorize > > >>>>> ofs.redirect target > > >>>>> ofs.fdscan 9 120 1200 > > >>>>> ofs.maxdelay 60 > > >>>>> ofs.trace 0 > > >>>>> 040909 23:31:02 21726 oss_Init: (c) 2003, Stanford > University, oss > > >>>>> Version1.0.0 > > >>>>> 040909 23:31:02 21726 oss_config: Storage system > initialization > > >>>>> started. > > >>>>> 040909 23:31:02 21726 oss_config: Storage system > initialization > > >>>>> completed. > > >>>>> /opt/xrootd/etc/xrootd.cf oss configuration: > > >>>>> oss.alloc 0 0 0 > > >>>>> oss.cachescan 600 > > >>>>> oss.compdetect * > > >>>>> oss.fdlimit 512 1024 > > >>>>> oss.maxdbsize 0 > > >>>>> oss.localroot /stage/bdata-data38/kanga > > >>>>> oss.stagecmd /opt/xrootd/utils/mps_Stage > > >>>>> oss.mssgwpath /tmp/gateway.mss.21726 > > >>>>> oss.trace 0 > > >>>>> oss.xfr 1 9437184 30 10800 > > >>>>> oss.path /store r/o > > >>>>> oss.cache public /stage/bdata-data38/cache/ > > >>>>> oss.cache public /stage/bdata-data46/cache/ > > >>>>> 040909 23:31:02 21726 oss_MSS_Init: Mass storage interface > > >>>>> initialization started. > > >>>>> 040909 23:31:02 21726 oss_MSS_Init: Mass storage interface > > >>>>> initialized. > > >>>>> 040909 23:31:02 21726 Prep log directory not > specified; prepare > > >>>>> tracking disabled. > > >>>>> 040909 23:31:02 21726 Exporting /store > > >>>>> 040909 23:31:02 21726 XRootd protocol version 2.2.0 build > > >>>>> 20040901-0613 successfully loaded. > > >>>>> 040909 23:31:02 21726 [log in to unmask]:1094 > initialization > > >>>>> completed. > > >>>>> > > >>>>> Also as the problem could be with my script, is there > a log file > > >>>>> where I would see any output generated from it? > > >>>>> > > >>>>> cheers > > >>>>> > > >>>>> Manny > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >