 |
 |
On Thu, 5 Aug 2021 at 23:21, Andrew Hanushevsky ***@***.***> wrote: > Hi Albert, > > I think I can explain what is going on here and it woud indicate that the > latest change to Ral's Ceph plugin is causing the problem (they recently > added async I/O to the plugin). RAL hasn't recently added async I/O to the Ceph plugin. The plugin uses the RADOS Striper library, which has used RADOS async I/O as long as I've known it. There might be some confusion with the experimental approach to supporting Vector Reads; this does explicitly use async I/O, but is not accessible to any users except RAL developers and is not on an advertised gateway (hence is not germane to this discussion.) Way back there was this quirk in the > xrootd read driver that would re-issue a read request for the remaining > bytes of a read request when the plugin returned less than the requested > number of bytes. The read would terminate only if zero bytes were returned > (i.e. none of it could be satisfied). We determined that this was really > unneeded behaviour but when we asked plug-in writers if they felt > comfortable with us changing the behaviour to simply terminate further > reads when less bytes were returned than we asked for, we received a > negative response (i.e. leave it as is). So, we left the code unchanged. > This behavior has been there for the last 20 years and all plugins obey > the general rule if there is no more data they will return 0 bytes. This > was also true of the Ceph plugin over the years. Apparently, that has > changed and when reading precisely past the file's EOF. Under such > circumstances the Ceph plugin seems to be manufacturing data, which is > patently wrong. > > This is obviously shown in the log where we read 4194304, get back the > correct amount of 1755648 and then issue one more read for the remaining > 2438656 bytes but instead of getting the expected 0 byte result we get > phantom data precisely equaling that amount. > > So, I would bring this up with RAL. > > Andy > > > On Thu, 5 Aug 2021, Albert Rossi wrote: > > > At any rate, I'm trying a different strategy. I want to fix this before > reporting to RAL this weirdness. > > > > -- > > You are receiving this because you were mentioned. > > Reply to this email directly or view it on GitHub: > > https://github.com/xrootd/xrootd/issues/1454#issuecomment-893821802 > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/xrootd/xrootd/issues/1454#issuecomment-893859109>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAPH634UGFY4S7XW6A3FXTTT3MFF3ANCNFSM44JDUM5A> > . > Triage notifications on the go with GitHub Mobile for iOS > <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> > or Android > <https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email> > . > -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1454#issuecomment-894044696 ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1