 |
 |
Hi Volodymyr, ----- Original Message ----- From: "Volodymyr Kapchynskyy" <[log in to unmask]> To: <[log in to unmask]> Sent: Friday, September 16, 2005 4:16 AM Subject: dCache wants to communicate with XRootd > Flushing files to MSS. > Calling "msstalk create mssfn mode" in the most straightforward way does > not work. > It seems to us that > 1. The "create" command is called BEFORE the actual file was written into > the local folder by xrdcp. So there is nothing to flush. > 2. It is kind of unknown when the file should be start to being flushed. > 3. "create" should first touch the file on MSS, return "0" saying that > evrything is ok and then it can actually flush the file. Otherwise the > flushing does not work. Actually, the reason it looks that way is because the mssgwcmd isn't meant to be used for file "after" events but for "prior" events (e.g., successful creation of a file in the MSS prior to creating it on disk). Please look into using the "ofs.notify" directive which provides you with a complete "post" event notification mechanism to synchrnoze any external MSS with events occuring in xrootd. That directive is available in the latest development build but it looks like that build will soon become production anyway. Using notify does not preclude using mssgwcmd simply because the mssgwcmd is still needed for "stat()" functions. In general, we are looking at ways to integrate xrootd with a generalized SRM which, hopefully, will straighten out the somewhat scattered directives with dealing with an external MSS. That situation has become somewhat cumbersome due to years of iterative/incremental changes that needed to be backward compatible. > So we wonder how actually the create should function and how it should > communicate with XRootd? In this case (as I menetioned above) create is called to verify that the file can actually be created in the mss before creating on disk. > What kind of logic should be behind the implementation of create part of > oss.mssgwcmd command? Use the ofs.notify directive. In your case you want to use the closew event notfications. This doesn't actually tell you if the file has actually been modified, simply that it was originally opened in write mode. If you want to gaurd against flushing unmodified files, then you can use the fwrite event which will tell you that indeed the file has been modified. In retrospect, I could have probably made these a bit more fine grained such as adding "openc" and "closec" (for create) and having a closewm which would be called if the file was actually modified. Anyway, the above will work. Andy