On Fri, 19 Feb 2016, Arnd Bergmann wrote: > On Friday 19 February 2016 12:42:02 Ilya Dryomov wrote: > > I want the kernel client to be bug compatible with servers and other > > clients in ceph.git. > > > > > > > > a) Remain consistent with current 64-bit servers and clients, > > > interpreting the number as an unsigned 32-bit integer where > > > possible, and remain broken on existing 32-bit machines > > > until they start using 64-bit time_t. > > > > > > b) Change 64-bit clients to behave the same way that that 32-bit > > > clients and servers do today, and actually use the times as > > > a signed number that you claimed they already did. > > > > > > c) Interpret all times before 1980 or after 2038 as buggy servers > > > and only accept times that are always handled consistently. > > > Also fix the server to reject those times coming from broken > > > clients. > > > > > > d) Leave 64-bit clients unchanged (using unsigned timestamps) and > > > document that 32-bit clients should keep interpreting them as > > > signed even when we fix VFS, to preserve the existing behavior. > > > > > > I think a), b) and c) are all reasonable, and I can send a patch > > > as soon as you know what you want. If you want d), please leave > > > me out of that and do it yourself. > > > > My preference would be a), possibly with some comments along the lines > > of c), to make the ..2038 range more explicit, as I doubt we've ever > > assumed ..2106 on 64-bit. This is all really old code and goes back to > > the dawn of ceph and beyond the kernel client, so let's wait for Sage > > to chime in. > > Ok, thanks! > > I think the same problem appeared in a lot of places when code was > originally written with the assumption that time_t is 32-bit, > and then it kept working in practice when ported to 64-bit systems > for the first time but the underlying assumptions changed. > > /* > * ceph timestamp handling is traditionally inconsistent between > * 32-bit clients and servers using them as a signed 32-bit time_t > * ranging from 1902 to 2038, and 64-bit clients and servers > * interpreting the same numbers as unsigned 32-bit integers > * with negative numbers turning into dates between 2038 and 2106. > * > * Most clients and servers these days are 64-bit, so let's pretend > * that interpreting the times as "__u32" is intended, and use > * that on 32-bit systems as well once using a 64-bit time_t. > */ This sounsd right to me. In practice we never have negative timestamps, so keeping the unsigned interpretation makes the most sense, and buys us several decades. Although it's pretty likely we'll switch to a 64-bit encoding long before then... sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
