On Thu, Sep 5, 2019 at 6:58 PM Mike Marshall <hubcap@xxxxxxxxxxxx> wrote:
>
> I spoke to Walt Ligon about the versioning code, and also shared
> this thread with him. He isn't a fan of the versioning code.
> and we think it should go. As I read through the commit messages
> from when the versioning code was added, it relates to mtime
> on directories. If a directory is read, and it has enough entries,
> it might take several operations to collect all the entries. During
> this time the directory might change. The versioning is a way to
> tell that something changed between one of the operations...
>
> commit: 7878027e9c2 (Oct 2004)
> - added a directory version that is passed back from the server to
> the client on each successful readdir call (happens to be the
> directory's mtime encoded as an opaque uint64_t)
>
> We will work to see if we can figure out what we need to do to Orangefs
> on both the userspace side and the kernel module side to have all 64 bit
> time values.
Ok, sounds good. For the time being, I have applied the patch
that limits the kernel to timestamps in the 1970 to 2106 range, which
is compatible with the existing user space and will be good enough for
a while.
If you can ignore the old pre-versioning interfaces, you can decide to
encode the epoch number in the remaining 12 bits of the on-disk
representation, like
time64 = (u32)(timeversion >> 32) + ((s64)(timeversion & 0xffc00000) << 12);
to extend it into the far-enough future (136 years times 2^12), or possibly
using
time64 = (s32)(timeversion >> 32) + ((s64)(timeversion & 0xffc00000) << 12);
to interpret existing timestamps with the msb set as dates between 1902
and 1970, which would fix the test case that broke, but disallow dates past
2038 with unmodified kernels.
Arnd
