Decide against extending the log at this point - no oa_present yet
With the previous commit, we restore the objcore's oa_present field when we first read the object. On top of that, it would be nice if we could restore the field or at least the bit for OA_VARY when we read the log, because a cache lookup checks it and could avoid reading objects if the OA_VARY bit is not set. On the other hand, if vary is used, the object needs to be read anyway, so restoring oa_present during log read only payed off for no vary. The straight forward solution would be to add 2 bytes to struct fellow_dle_obj. This would - require a DLE version bump and compatibility code - bump the dle size from 72 to 80 bytes (because alignment) - consequently, reduce FELLOW_DISK_LOG_BLOCK_ENTRIES from 56 to 4032 / 80 = 50 All this is possible and part of the fellow design, but at this point I conclude that it is not worth the effort. Another option would be to cram two bits into the existing fellow_dle_obj, for example by exploiting the fact that the sign bit of ban and t_origin is always zero. This could break backwards compatibility, so we prepare for the option, but do not implement it. All in all, we just add a TODO to add this when we need to extend the DLE anyway. Closes #17
Showing
Please register or sign in to comment