linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Jeff Layton <jlayton@redhat.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH][RFC] nfsd/lockd: have locks_in_grace take a sb arg
Date: Wed, 11 Apr 2012 14:34:37 +0400	[thread overview]
Message-ID: <4F855E3D.6090306@parallels.com> (raw)
In-Reply-To: <20120410202251.GH18465@fieldses.org>

11.04.2012 00:22, J. Bruce Fields пишет:
> On Tue, Apr 10, 2012 at 04:46:38PM +0400, Stanislav Kinsbursky wrote:
>> 10.04.2012 16:16, Jeff Layton пишет:
>>> On Tue, 10 Apr 2012 15:44:42 +0400
>>>
>>> (sorry about the earlier truncated reply, my MUA has a mind of its own
>>> this morning)
>>>
>>
>> OK then. Previous letter confused me a bit.
>>
>>>
>>> TBH, I haven't considered that in depth. That is a valid situation, but
>>> one that's discouraged. It's very difficult (and expensive) to
>>> sequester off portions of a filesystem for serving.
>>>
>>> A filehandle is somewhat analogous to a device/inode combination. When
>>> the server gets a filehandle, it has to determine "is this within a
>>> path that's exported to this host"? That process is called subtree
>>> checking. It's expensive and difficult to handle. It's always better to
>>> export along filesystem boundaries.
>>>
>>> My suggestion would be to simply not deal with those cases in this
>>> patch. Possibly we could force no_subtree_check when we export an fs
>>> with a locks_in_grace option defined.
>>>
>>
>> Sorry, but without dealing with those cases your patch looks a bit... Useless.
>> I.e. it changes nothing, it there will be no support from file
>> systems, going to be exported.
>> But how are you going to push developers to implement these calls?
>> Or, even if you'll try to implement them by yourself, how they will
>> looks like?
>> Simple check only for superblock looks bad to me, because any other
>> start of NFSd will lead to grace period for all other containers
>> (which uses the same filesystem).
>
> That's the correct behavior, and it sounds simple to implement.  Let's
> just do that.
>
> If somebody doesn't like the grace period from another container
> intruding on their use of the same filesystem, they should either
> arrange to export different filesystems (not just different subtrees)
> from their containers, or arrange to start all their containers at the
> same time so their grace periods overlap.
>

Starting all at once is not a very good solution.
When you start 100 containers simultaneously - then you can't predict, when the 
process as a whole will succeed (it will produce heavy load on all subsystems). 
Moreover, there is also  server restart...
Anyway, I agree with the idea of this patch.

Please, have a look at new export option I mentioned in "Grace period" thread.

-- 
Best regards,
Stanislav Kinsbursky

  reply	other threads:[~2012-04-11 10:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-03 12:14 [PATCH][RFC] nfsd/lockd: have locks_in_grace take a sb arg Jeff Layton
2012-04-09 23:18 ` J. Bruce Fields
2012-04-10 11:13   ` Jeff Layton
2012-04-10 13:18     ` J. Bruce Fields
2012-04-10 11:44 ` Stanislav Kinsbursky
2012-04-10 12:05   ` Jeff Layton
2012-04-10 12:18     ` Stanislav Kinsbursky
2012-04-10 12:16   ` Jeff Layton
2012-04-10 12:46     ` Stanislav Kinsbursky
2012-04-10 13:39       ` Jeff Layton
2012-04-10 14:52         ` Stanislav Kinsbursky
2012-04-10 18:45           ` Jeff Layton
2012-04-11 10:09             ` Stanislav Kinsbursky
2012-04-11 11:48               ` Jeff Layton
2012-04-11 13:08                 ` Stanislav Kinsbursky
2012-04-11 17:19                   ` J. Bruce Fields
2012-04-11 17:37                     ` Stanislav Kinsbursky
2012-04-11 18:22                       ` J. Bruce Fields
2012-04-11 19:24                         ` Stanislav Kinsbursky
2012-04-11 22:17                           ` J. Bruce Fields
2012-04-12  9:05                             ` Stanislav Kinsbursky
2012-04-10 20:22       ` J. Bruce Fields
2012-04-11 10:34         ` Stanislav Kinsbursky [this message]
2012-04-11 17:20           ` J. Bruce Fields
2012-04-11 17:33             ` Stanislav Kinsbursky
2012-04-11 17:40               ` Stanislav Kinsbursky
2012-04-11 18:20               ` J. Bruce Fields
2012-04-11 19:39                 ` Stanislav Kinsbursky
2012-04-11 19:54                   ` J. Bruce Fields

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=4F855E3D.6090306@parallels.com \
    --to=skinsbursky@parallels.com \
    --cc=bfields@fieldses.org \
    --cc=jlayton@redhat.com \
    --cc=linux-nfs@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).