From: Peter Staubach <staubach@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Neil Brown <neilb@suse.de>, nfs@lists.sourceforge.net
Subject: Re: [PATCH 002 of 2] Avoid flush-when-locking when interclient consistency not needed.
Date: Mon, 16 Apr 2007 10:48:31 -0400 [thread overview]
Message-ID: <46238CBF.4090700@redhat.com> (raw)
In-Reply-To: <1176734503.6761.37.camel@heimdal.trondhjem.org>
Trond Myklebust wrote:
>
>
> On Mon, 16 Apr 2007 at 10:12:09 -0400, Peter Staubach wrote:
>
>> "llock" or "local lock" implies that only local locks will be used.
>> Thus, only the locks that the kernel is managing are used or kept
>> track of. No over the wire traffic for locking is issued.
>>
>> With this option, caching is enabled.
>>
>
> So are you saying that 'llock' basically mirrors our 'nolock', or does
> it additionally disable the flushing operations? If the latter, then I
> suggest that we add a mount flag, NFS_MOUNT_LLOCK which automatically
> sets NFS_MOUNT_NONLM + a new flag that just disables the cache flush on
> lock/unlock.
I believe that the use of "llock" also disables the cache flush at
lock/unlock. Perhaps someone with access to the OpenSolaris code,
who isn't worried about CDDL versus GPL issues, could look to verify.
It has been a bit since I've worked on that code.
I do remember that the "llock" code was designed to be used for things
like root file systems, where there shouldn't be any conflicts between
different clients, and hence, no need for special page cache handling.
Thanx...
ps
-------------------------------------------------------------------------
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/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2007-04-16 14:50 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 5:40 [PATCH 000 of 2] A couple of possible nfs client patches NeilBrown
2007-03-06 5:40 ` [PATCH 001 of 2] Set meaningful value for fattr->time_start in readdirplus results NeilBrown
2007-04-14 22:13 ` Trond Myklebust
2007-04-15 23:35 ` Neil Brown
2007-04-16 15:23 ` Trond Myklebust
2007-03-06 5:40 ` [PATCH 002 of 2] Avoid flush-when-locking when interclient consistency not needed NeilBrown
2007-03-06 14:40 ` Trond Myklebust
2007-03-07 23:03 ` Neil Brown
2007-04-14 22:21 ` Trond Myklebust
2007-04-16 1:49 ` Chuck Lever
2007-04-16 14:12 ` Peter Staubach
2007-04-16 14:41 ` Trond Myklebust
2007-04-16 14:48 ` Peter Staubach [this message]
2007-03-06 14:57 ` [PATCH 000 of 2] A couple of possible nfs client patches Chuck Lever
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=46238CBF.4090700@redhat.com \
--to=staubach@redhat.com \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
--cc=trond.myklebust@fys.uio.no \
/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.