| |||||||||||||
A kernel change breaks GlusterFSA kernel change breaks GlusterFSPosted Mar 29, 2013 17:24 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: A kernel change breaks GlusterFS by mkerrisk Parent article: A kernel change breaks GlusterFS
The question is where you consider the definition of the ABI to be. Is it some documented standard ("this is a 64-bit field"), or is it "the behavior as (it appears to be) implemented" ("only 32 bits are ever used in this field")? The GlusterFS folks clearly took it to be the latter. According to what you wrote, they did more than that. They looked at the man page, which is the closest Linux comes to an ABI specification. They noted the language in there, which could have said "continuation cookie" or something, but actually uses the word "offset." This suggests that it is a very old interface from days before we understood layering the way we do now and that it is (or at least has to emulate) a byte offset within the stored representation of the directory. They probably noticed that the C type of the member is the one used for file offsets. That means only in a huge directory could it have nonzero upper bits. It's not clear to me how they disposed of the possibility of a huge directory, but that's probably beside the point. But I have to say I assume the developers knew they were taking a risk. Common sense would have told them that modern filesystems, especially the ones that haven't been invented yet, don't have such simple implementations of directories and their developers might well use the upper 32 bits freely. They decided to trade the future breakage for all the present benefits truncating the offset gave them . We tend to remember those tradeoffs differently after payment becomes due.
(Log in to post comments)
|
|||||||||||||