From: Chuck Lever <chuck.lever@oracle.com>
To: Jeff Layton <jlayton@redhat.com>
Cc: nfs@lists.sourceforge.net
Subject: Re: [PATCH] nfs-utils: make auth_reload respect sub-second timestamps on etab
Date: Wed, 25 Apr 2007 17:29:52 -0400 [thread overview]
Message-ID: <462FC850.7040600@oracle.com> (raw)
In-Reply-To: <20070425201354.GD6696@salusa.poochiereds.net>
[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]
Jeff Layton wrote:
> On Wed, Apr 25, 2007 at 02:09:34PM -0400, Jeff Layton wrote:
>> On Wed, Apr 25, 2007 at 01:39:20PM -0400, Jeff Layton wrote:
>>> Currently, when auth_reload is called, it only looks at the tv_sec field
>>> of the mtime when deciding whether to invalidate the exports cache. It's
>>> fairly simple to fool this by doing something like:
>>>
>>> # exportfs -rv && rpc.mountd && exportfs -uva && exportfs -iv -o no_root_squash,rw 127.0.0.1:/foo
>>>
>>> With this, exportfs will show the export for /foo, but mountd will still have
>>> whatever contents were in /etc/exports. The issue is that the etab is being
>>> updated twice during the same second, and mountd is reading in the file in
>>> between updates. When it goes to look at the file again, its timestamp matches
>>> the timestamp of the cache, and it ends up keeping the cached contents even
>>> though the file has changed.
>>>
>>> While not all local filesystems provide sub-second timestamps, we might as
>>> well fix this problem on those that do. The following patch changes
>>> auth_reload to consider the tv_nsec field of the mtime when deciding whether
>>> to invalidate the export cache. It also fixes up the callers to pass it a
>>> pointer to a struct timespec for it to fill out.
>>>
>>> I've not yet tested this on a filesystem that provides sub-second timestamps,
>>> so I'm not clear on how well this works yet, but it seems to not break
>>> anything on ext3 in some cursory testing.
>>>
>> No sooner than I post than I see a (minor) problem. The check for a NULL
>> pointer in auth_reload should be (ts != NULL) instead of (ts). Respun patch
>> follows:
>>
>
> I tested this on a filesystem that does nanosecond timestamps (xfs), and it
> seems to correct the original problem.
Hi Jeff-
I don't know much about the export logic, but why not use inode change
notification instead of time stamps?
[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 336 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
email;internet:chuck.lever@nospam-oracle.com
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel/
version:2.1
end:vcard
[-- Attachment #3: Type: text/plain, Size: 286 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[-- Attachment #4: Type: text/plain, Size: 140 bytes --]
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-04-25 21:31 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 17:39 [PATCH] nfs-utils: make auth_reload respect sub-second timestamps on etab Jeff Layton
2007-04-25 18:09 ` Jeff Layton
2007-04-25 20:13 ` Jeff Layton
2007-04-25 21:29 ` Chuck Lever [this message]
2007-04-26 4:56 ` Neil Brown
2007-04-26 12:05 ` Jeff Layton
2007-04-26 16:23 ` Jeff Layton
2007-04-26 16:58 ` J. Bruce Fields
2007-04-26 17:00 ` Jeff Layton
2007-04-26 17:24 ` J. Bruce Fields
2007-04-26 18:29 ` Jeff Layton
2007-05-03 0:55 ` Neil Brown
2007-05-03 11:58 ` Jeff Layton
2007-05-03 12:11 ` Jeff Layton
2007-04-26 17:33 ` Jeff Layton
2007-04-26 12:35 ` J. Bruce Fields
2007-04-26 4:50 ` Neil Brown
2007-04-26 11:50 ` Jeff Layton
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=462FC850.7040600@oracle.com \
--to=chuck.lever@oracle.com \
--cc=jlayton@redhat.com \
--cc=nfs@lists.sourceforge.net \
/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.