All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glauber Costa <glommer@parallels.com>
To: Dave Chinner <david@fromorbit.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-fsdevel@vger.kernel.org>,
	<containers@lists.linux-foundation.org>,
	Pavel Emelyanov <xemul@parallels.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Hugh Dickins <hughd@google.com>, Nick Piggin <npiggin@kernel.dk>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Rik van Riel <riel@redhat.com>,
	Dave Hansen <dave@linux.vnet.ibm.com>,
	James Bottomley <JBottomley@parallels.com>
Subject: Re: [PATCH 4/4] parse options in the vfs level
Date: Tue, 2 Aug 2011 10:04:06 -0300	[thread overview]
Message-ID: <4E37F5C6.8060908@parallels.com> (raw)
In-Reply-To: <20110731013456.GM5404@dastard>

On 07/30/2011 10:34 PM, Dave Chinner wrote:
> On Fri, Jul 29, 2011 at 05:44:19PM +0400, Glauber Costa wrote:
>> This patch introduces a simple generic vfs option parser.
>> Right now, the only option we have is to limit the size of the dcache.
>>
>> So any user that wants to have a dcache entries limit, can specify:
>>
>>    mount -o whatever_options,vfs_dcache_size=XXX<dev>  <mntpoint>
>>
>> It is supposed to work well with remounts, allowing it to change
>> multiple over the course of the filesystem's lifecycle.
>>
>> I find mount a natural interface for handling filesystem options,
>> so that's what I've choosen. Feel free to yell at it at will if
>> you disagree.
>
> IMO, the whole point of having a configurable cache size maximum is
> that is can be changed at runtime. Tying it to mount options is a
> painful way to acheive that because the only way to change it would
> be via a remount command.
And what's wrong with a remount command? It's a quite natural operation.
Furthermore, changing it at runtime is important - and as you noted, 
quite doable, but it is not "the whole point of it".
The whole point of it is to allow a piece of the fs hierarchy to have
a limit on the cache sizes. So I expect the most common usage to be
at mount itself. Specifically for the use case I have in mind, when
a new container is created.

> I'm not sure what the best API is, but I'd prefer something that is
> specific to a superblock, not a vfs mount. Perhaps something in
> /sys/fs?

I am not sure either, but I still believe my proposal is superior to 
write-to-a-file specifically. Writing to a file, be it in proc, sys, or 
wherever, leaves a window of opportunity open between mounting a 
filesystem and limiting its caches. Doing it on mount is atomic.

Effectively, I see this limit as a property of a particular instance of 
a mounted filesystem. Since all properties of a filesystem are specified 
during mount, this becomes a natural extension.

Let me know what you think



  reply	other threads:[~2011-08-02 13:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-29 13:44 [PATCH 0/4] Per-superblock dcache limitation Glauber Costa
2011-07-29 13:44 ` Glauber Costa
2011-07-29 13:44 ` [PATCH 1/4] Keep nr_dentry per super block Glauber Costa
     [not found]   ` <1311947059-17209-2-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-07-31  0:50     ` Dave Chinner
2011-07-31  0:50   ` Dave Chinner
     [not found] ` <1311947059-17209-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-07-29 13:44   ` Glauber Costa
2011-07-29 13:44   ` [PATCH 2/4] limit nr_dentries per superblock Glauber Costa
2011-07-29 13:44   ` [PATCH 3/4] dcache set size Glauber Costa
2011-07-29 13:44   ` [PATCH 4/4] parse options in the vfs level Glauber Costa
2011-07-29 13:44 ` [PATCH 2/4] limit nr_dentries per superblock Glauber Costa
     [not found]   ` <1311947059-17209-3-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-07-31  1:15     ` Dave Chinner
2011-07-31  1:15   ` Dave Chinner
2011-08-02 12:46     ` Glauber Costa
2011-08-02 12:46       ` Glauber Costa
2011-07-29 13:44 ` [PATCH 3/4] dcache set size Glauber Costa
2011-07-31  1:38   ` Dave Chinner
     [not found]   ` <1311947059-17209-4-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-07-31  1:38     ` Dave Chinner
2011-07-29 13:44 ` [PATCH 4/4] parse options in the vfs level Glauber Costa
2011-07-31  1:34   ` Dave Chinner
2011-08-02 13:04     ` Glauber Costa [this message]
2011-08-02 14:18       ` Al Viro
     [not found]         ` <20110802141806.GL2203-3bDd1+5oDREiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
2011-08-02 14:43           ` Glauber Costa
2011-08-02 14:43         ` Glauber Costa
     [not found]       ` <4E37F5C6.8060908-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-08-02 14:18         ` Al Viro
2011-08-02 13:04     ` Glauber Costa
     [not found]   ` <1311947059-17209-5-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2011-07-31  1:34     ` Dave Chinner

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=4E37F5C6.8060908@parallels.com \
    --to=glommer@parallels.com \
    --cc=JBottomley@parallels.com \
    --cc=aarcange@redhat.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=dave@linux.vnet.ibm.com \
    --cc=david@fromorbit.com \
    --cc=hughd@google.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@kernel.dk \
    --cc=riel@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xemul@parallels.com \
    /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.