FWD Software

["Van Buren, Gene" <gene AT bnl.gov>]

Hi, Nick

Thanks for the explanation.... Some comments....

1) storage=nfs is not a reliable choice in future analysis passes, as I do 
not have enough room to hold everything on NFS, and will begin deleting there 
in a month or so (the production will take many more months). But xrootd will 
house the entire dataset.

2) I believe that storage=local should work, as other people running other 
analyses are doing. It would be helpful to me if you could give a specific 
example of a file which succeeded using nfs but failed using xrootd.

-Gene


> On Apr 23, 2026, at 12:09 PM, Jindal, Nicholas 
> <star-fwd-software-l AT lists.bnl.gov> wrote:
> 
> This Message Is From an External Sender
> This message came from outside your organization.
> Hi All,
> 
> David helped me solve this job submission issue I was having on the new 
> nodes so I thought I’d pass along the fix. Before switching over to the 
> alma9 nodes, getting a file list with something like 
> 
> 'get_file_list.pl -keys fdid,storage,site,node,path,filename,events -cond 
> production=P25ib,trgsetupname=production_pp500_2022,filetype=daq_reco_picodst,storage=local’
>  
> 
> worked just fine when used in an xml submission script like this:
> '<input 
> URL="catalog:star.bnl.gov?production=P25ib,trgsetupname=production_pp500_2022,filetype=daq_reco_picodst,storage=local"
>  nFiles="1" />’. 
> 
> Now, using 'storage=local' seems to impose a requirement on the node the 
> jobs are run on, which don’t match any of the alma9 nodes so the jobs will 
> fail. Changing 'storage=local' to ’storage=nfs’ fixes it. I’ve attached a 
> screenshot of what running the get_file_list.pl command returns when asking 
> for ’storage=local’. 
> 
> I am curious if anyone, particularly Gene, knows why this failed without 
> this change? 
> 
> Best,
> -- 
> Nicholas Jindal
> PhD Candidate
> The Ohio State University Department of Physics
> jindal.78 AT osu.edu<Screenshot 2026-04-23 at 12.01.09 PM.png>