…and a somehow related question (ok, not really, this is due to my ignorance).
I was trying, using a standard xrootd (no modification apart form some printout), to access via a global redirector a non existing file …
I see that if I have at the same time, on my machine
- xrootd
- cmsd
- xfrd
enabled, I always get redirected to that machine.
Does it make sense? in a sense yes: locally the file is not there, but xrootd is not aware of what is on tape, so "maybe it is there" ….
but, if this is the case,
- how can this be avoided?
- if there are two sites with cmsd + frd, how can the system know the file is in one place and not another?
also, a command like
xrd <redirector> locateall <that non existing file>
returns nothing, so is the redirector using a different api to locate files?
I maybe completely wrong, clearly …. In case, sorry in advance
tom
On Mar 12, 2013, at 12:04 PM, Tommaso Boccali <[log in to unmask]> wrote:
> Hi,
> I am trying to patch Xrootd for a specific use case, for a site with GPFS + TSM backend.
>
> The system is somehow different from a standard disk + tape, since GPFS reports (via posix) the files always present, even if they are tape only.
> In principle, one could forget and let GPFS do the magic: if a fopen is issued to GPFS for a file only on tape, recall is automatically triggered etc …
>
> BUT: the tape system cannot really afford this kind of random recalls, and there is a specific interface to queue recalls and combine them in a smart way (for example, do all the recalls in the same cassette etc).
>
> So I am trying to patch xrootd for this (I was already successful in instrumenting cmsd not to publicize files just on tape…)
>
> Main idea is to use a standard stagein technique, via
>
> frm.xfr.copycmd out /bin/true 0
> frm.xfr.copycmd in stats noalloc /opt/xrootd/bin/copy.sh $SRC $DST
> frm.xfr.copymax 200
>
> where the script enqueues the recall to the proper mechanism.
>
> The patch is needed since xrootd uses frm interface when the file is missing, and this is never the case for a tape only file since GPFS always shows all the files …
>
> So my patch would be to simply tell xrootd that a file on GPFS, but with stat buf.blocks == 0, should be considered as absent, and hence trigger frm.
>
> I was optimistic that a simple change like checking the # of blocks in XrdOssApi:Open_ufs would be sufficient, like
>
> struct stat buf;
> if (!stat(path,&buf)) {
> if ((buf.st_mode & S_IFMT) == S_IFREG) {
> if (buf.st_size>0 && buf.st_blocks==0){
> // i want to kill this one, I return not existing
> std::cerr<<" APPLYING MY FIX!!!!!!!!!!"<<std::endl;
> return -ENOENT;
> }
> }
> }
>
> and indeed it works, in the sense that the file is recognized as present BUT on disk only, and hence the same error code as for missing files is returned (-ENOENT).
>
> Problem is that, later, no recall command is issued for the file, and an open is issued continuously with 1 sec delay. So probably what I did is not enough. I will file a request for enhancement (as I already did for the cmsd part), but in case someone sees a trivial cause for this behavior, I would be happy to test a solution.
>
> thanks
>
> tommaso
>
>
>
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the XROOTD-L list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
