dCache / xrootd4j

Implementation of the xrootd data access protocol in Java
Other
3 stars 8 forks source link

Implement kXR_fattr and extended info for xKR_stat #140

Closed cal-jlab closed 2 years ago

cal-jlab commented 2 years ago

Hello,

I'm currently working on a proof-of-concept project to interface XRootD with Jefferson Lab's (www.jlab.org) tape library. My initial approach is to use the xroot.redirect directive to fetch file metadata from the tape library, and possibly the file residency manager to control staging and migrating. I have already added support for extended stat info in my personal copy of the xrootd4j 4.4.0. This was fairly simple. But it looks like adding support for fattr will take a bit more effort because little of the required scaffolding is present in the current code.

Can someone offer some suggestion on the best way to proceed? I would like to contribute this new functionality back to the repository when it is ready.

Thanks!

Chris

kofemann commented 2 years ago

Hi Chris,

thanks for getting in touch with us. The simplest way well be to prototype the fattr implementation in standalone server and use UserDefinedFileAttributeView to access file systems extended attributes. @alrossi and myself will be happy to help you.

Best regards

cal-jlab commented 2 years ago

Hi! Thanks for the quick response. I'll look at UserDefinedFileAttributeView. Please note that I am implementing this on top of our home-grown tape library software so I will not actually be interfacing with a file system, but rather presenting what looks like one to the XRootD clients. So the fattr call will supply fields like tape location, storage set, etc. It looks like I'll need to create a doOnFattr() method in XrootdRequestHandler as well as implement a corresponding FattrResponse object?

alrossi commented 2 years ago

Hi Chris, yes that is the case (doOnFattr() and the response object). You will also need to add the appropriate switch condition to the decoder(s) getRequest, and call doOnFattr() in the handler itself (which I'm sure you already figured out).

Just one caveat: if this is an implementation-specific addition, which it sounds like it is, it would be best (after you are done prototyping) to create a separate plugin to the xrootd4j library (xrootd4j-jlab perhaps) and place the code there that implements the kXR_fattr request, making the core handler implementation of doOnFattr() simply return unsupported.

I'll let you play around with this, but if you need guidance on any specific issue, don't hesitate to ask.

Cheers, Al

cal-jlab commented 2 years ago

Yes, certainly my intent was not to include jlab-specific code in this repository, but rather to implement the necessary scaffolding. Hopefully it will be useful to others as well. Thanks again, and I'll be sure to let you know if I need more guidance. Cheers!

cal-jlab commented 2 years ago

Okay, I whipped up a first-cut implementation of the kXR_fattr protocol request on the 4.4 branch. I added two new classes (FattrRequest, FattrResponse) and added a doOnFattr() method to XrootdRequestHandler. I overrode this method in my proof-of-concept server to implement listing and getting attributes from our tape library. I'm sure there are some bugs, edge cases, and sanity checks yet to be remedied, but thought it might be good to get some feedback before doing any more. I'm fairly new to collaborating on github; can you help me get my modifications visible for review? Thanks!

kofemann commented 2 years ago

@cal-jlab the best option is to create a branch from master in your fork, apply your changes and then create a pool request against out repo. In that case we review the code, comment it and merge, when it's ready

cal-jlab commented 2 years ago

Thanks @kofemann. I created pull request #141

cal-jlab commented 2 years ago

Just saw that the changes were merged in to master. Thanks!