All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	Neil Brown <neilb@suse.de>, Steve Dickson <SteveD@redhat.com>,
	NFSv3 list <linux-nfs@vger.kernel.org>,
	Mi Jinlong <mijinlong@cn.fujitsu.com>
Subject: Re: [RFC] server's statd and lockd will not sync after its nfslock restart
Date: Thu, 17 Dec 2009 15:48:03 -0500	[thread overview]
Message-ID: <1261082883.4080.28.camel@localhost> (raw)
In-Reply-To: <76D5AD4C-2DDA-4A12-BD53-168D04CA9E7C@oracle.com>

On Thu, 2009-12-17 at 15:34 -0500, Chuck Lever wrote: 
> On Dec 17, 2009, at 3:27 PM, Trond Myklebust wrote:
> > One alternative might be to just record the kernel's random boot_id in
> > the pid file. That gets regenerated on each boot, so should be unique.
> 
> Where do you get it in user space?  Is it available on earlier  
> kernels?  ("should be unique" -- I hope it doesn't have the same  
> problem we had with XID replay on diskless systems).

You can access it from userland as the 'kernel.random.boot_id' sysctl.

It is available on 2.4 kernels and newer.

It is based on the kernel random number generator, so should be
reasonably unique.

> Fwiw, I tried using the boot time stamp at one point, but  
> unfortunately that's adjusted by the ntp offset, so it can take  
> different values over time.  It was difficult to compare it to a time  
> stamp recorded in a file.

Agreed. You can't rely on time stamps.

Trond


  reply	other threads:[~2009-12-17 20:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-15 10:02 [RFC] server's statd and lockd will not sync after its nfslock restart Mi Jinlong
2009-12-15 12:41 ` J. Bruce Fields
2009-12-16  9:46   ` Mi Jinlong
2009-12-15 15:10 ` Chuck Lever
2009-12-16 10:27   ` Mi Jinlong
2009-12-16 13:49     ` Jeff Layton
     [not found]       ` <20091216084902.64f722ad-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2009-12-17  9:34         ` Mi Jinlong
2009-12-16 19:33     ` Chuck Lever
2009-12-17 10:07       ` Mi Jinlong
2009-12-17 16:18         ` Chuck Lever
2009-12-17 20:14           ` J. Bruce Fields
2009-12-17 20:35             ` Chuck Lever
2009-12-17 20:27           ` Trond Myklebust
2009-12-17 20:34             ` Chuck Lever
2009-12-17 20:48               ` Trond Myklebust [this message]
2009-12-17 23:14           ` Neil Brown
     [not found]             ` <20091218101438.48eb06a4-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2009-12-18 15:18               ` Chuck Lever
2009-12-19 16:42                 ` Steve Dickson

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=1261082883.4080.28.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=SteveD@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=chuck.lever@oracle.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mijinlong@cn.fujitsu.com \
    --cc=neilb@suse.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.