| |||||||||||||
The ext4 change 'breaks' Samba tooThe ext4 change 'breaks' Samba tooPosted Mar 28, 2013 2:43 UTC (Thu) by abartlet (✭ supporter ✭, #3928)Parent article: A kernel change breaks GlusterFS
It is interesting to see this article, because this same change (from the description) also 'breaks' Samba.
We see the same thing, and have had to blacklist a number of our testsuites from our automated testing, because when an older diretory searching/enumeration protocol is used, we mapped the readdir() cookie onto a 4 byte element in that protocol. These tests in turn started spinning in an infinite loop due to the truncation.
Now, the fix for us is presumably to have some other in-memory mapping from 64-bit back to 32-bit for the cookies Samba clients have obtained. Naturally we also would need to avoid a DoS by allocation of an infinite number of mapped cookies, and other challenges, which along with the real-world use case for the interface being old DOS clients, means we haven't got around to it yet.
I only mention this to indicate that this was noticed beyond GlusterFS.
Andrew Bartlett
(Log in to post comments)
The ext4 change 'breaks' Samba too Posted Mar 28, 2013 7:54 UTC (Thu) by Lumag (subscriber, #22579) [Link]
Why can't GlusterFS also have an internal mapping between new cookies and some random bitstring given as a part of NFS' readdir() ?
The ext4 change 'breaks' Samba too Posted Mar 28, 2013 13:34 UTC (Thu) by bfields (subscriber, #19510) [Link] Once handed out to an NFS client, you don't know when the client may use a cookie; could be much later, could be after we've rebooted. So that internal mapping would have to be kept forever, on disk (to survive reboots). You could do it, but I think you'd quickly start feeling like you were doing a ton of work that the filesystem should really be doing for you. SMB might make this easier, I don't know. It might be possible to extend the NFS protocol to use some kind of directory-read pointer with a more limited lifetime. But that won't solve anybody's problem today, at least not until we get the IETF a time machine. (Four days left for someone to publish an RFC addressing the paradoxes inherent to time-travelling standards processes.)
The tree makes noise, but we need a test to listen for it Posted Mar 30, 2013 17:30 UTC (Sat) by davecb (subscriber, #1574) [Link]
Many years ago I was on the ABI stability team at Sun, and we actively tried to test all the "must be true" assertions in library interfaces like this. The easiest were changes in the nature of parameters: the hardest were changes in the meanings of otherwise unchanged parameters.
Ones like this we would have considered either "uninterpreted opaque cookie" (good) or "must be zero" (bad). Finding the latter usually resulted in version-number changes, weird backward-compatibility tests to see if anyone had stolen the upper half for anything and debates about how to change the documentation.
As a side effect, we tried to write a static test or shared-library test we could run against any apps that were being compatibility-tested by their vendors, and we recorded the difference in our porting database, so that if another vendor or an old SunOS system used it, it would get fixed in a port.
The latter, IMHO, was the really valuable part: if Hockey-PUX had the bug, we'd refrain from reproducing it on applications ported to Solaris. Linux rarely has such bugs: other vendors (including ourselves) weren't as fortunate.
--dave
|
|||||||||||||