linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Mike Marshall <hubcap@omnibond.com>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [GIT PULL] vfs: Add support for timestamp limits
Date: Thu, 5 Sep 2019 20:33:27 +0200	[thread overview]
Message-ID: <CAK8P3a22QBPO_+H3XV+u+Hue6ThVYg+Lfk0NPuiFYS_mTYw1eQ@mail.gmail.com> (raw)
In-Reply-To: <CAOg9mSS=V7cQqPMCj90LtudxhN7_owoEBKxkvsXjzdtu+R69hA@mail.gmail.com>

On Thu, Sep 5, 2019 at 6:58 PM Mike Marshall <hubcap@omnibond.com> 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

      reply	other threads:[~2019-09-05 18:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29  4:11 [GIT PULL] vfs: Add support for timestamp limits Deepa Dinamani
2019-08-30 12:56 ` Arnd Bergmann
2019-08-30 15:47   ` [GIT PULL RESEND] " Deepa Dinamani
     [not found] ` <CABeXuvoKD83B7iUqE33Y9E2OVtf61DKv-swZr-N=ozz-cMmGOA@mail.gmail.com>
     [not found]   ` <CAOg9mSR25eAH7e1KhDZt_uscJSzyuSmELbCxgyh=-KWRxjZtcw@mail.gmail.com>
     [not found]     ` <CABeXuvpe9vADLZUr4zHrH0izt=1BaLQvBMxAu=T1A2CV3AN4vA@mail.gmail.com>
     [not found]       ` <CAK8P3a0NMUv2xOw=fCxJXo_2wbmBMG24Fst3U1LT-m7C8uxz0w@mail.gmail.com>
     [not found]         ` <CABeXuvrm76iKnFrd7Wo=z4d0v7i7xT+Ta37D-mwVwy7-P3YyUg@mail.gmail.com>
2019-09-05 16:58           ` [GIT PULL] " Mike Marshall
2019-09-05 18:33             ` Arnd Bergmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a22QBPO_+H3XV+u+Hue6ThVYg+Lfk0NPuiFYS_mTYw1eQ@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=hubcap@omnibond.com \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).