linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Jordi Pujol Palomer <jordipujolp@gmail.com>
Cc: linux-unionfs@vger.kernel.org,
	Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>, "A. Wan" <jm@mokwan.com>,
	Patrick Frisch <patrick@frischux.de>,
	Aaron Campbell <aaron@arbor.net>
Subject: Re: [RFC PATCH] overlayfs: support more than one read-only layer
Date: Mon, 17 Nov 2014 11:32:07 +0100	[thread overview]
Message-ID: <CAJfpegvYBMbhbmpA2kB01qQ3u5ict7rgWib4tx=941yyzqJBMQ@mail.gmail.com> (raw)
In-Reply-To: <20141114095511.789a76ac@gmail.com>

On Fri, Nov 14, 2014 at 9:55 AM, Jordi Pujol Palomer
<jordipujolp@gmail.com> wrote:
> EL Mon, 10 Nov 2014 10:09:54 +0100
> Miklos Szeredi <miklos@szeredi.hu> escrigué:
>
>> Maybe it wasn't clear, but the number of lower layers isn't limited by
>> FILESYSTEM_MAX_STACK_DEPTH,
> sorry, you have been clear, it's me that have not explained the purpose
> of that patch. This idea is also valid for the main overlayfs
> development.
> Consider that we have an encrypted partition and a live OS that
> uses overlayfs and works over it, when the OS is started already
> reaches the maximum stacking depth (2). Also, hardcoding parameters
> into the code may be annoying because a change implies creating and
> mantaining patches, otherwise when the parameter is configurable we can
> change it in a config value.

Before allowing a change to FILESYSTEM_MAX_STACK_DEPTH we'd need to
analyze the kernel stack usage of anything taking part in the
filesystem stack.  Not something that can be expected of users before
they set a kernel config variable.

'Course we can change overlayfs and/or ecryptfs to use a new context
for operations done on underlying layers.  Not sure how much work that
would be...

> Also, I include a patch to explain better my first statement,
> would say lowerdirs has extended the functionality of lowerdir,
> therefore we can discard the lowerdir case that only works with one
> lower layer and rename lowerdirs to lowerdir. It's more simple and all
> the functionality is preserved.

Yeah.  But we also need some escaping in 'lowerdir=' argument to allow
filenames with comma and colon.  Current patch doesn't yet have that,
but will work on it.

Thanks,
Miklos
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2014-11-17 10:32 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 17:02 [RFC PATCH] overlayfs: support more than one read-only layer Miklos Szeredi
2014-11-08  9:35 ` Patrick Frisch
2014-11-08 18:27 ` Jordi Pujol Palomer
2014-11-10  9:09   ` Miklos Szeredi
2014-11-10 17:08     ` Erez Zadok
2014-11-14  8:55     ` Jordi Pujol Palomer
2014-11-17 10:32       ` Miklos Szeredi [this message]

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='CAJfpegvYBMbhbmpA2kB01qQ3u5ict7rgWib4tx=941yyzqJBMQ@mail.gmail.com' \
    --to=miklos@szeredi.hu \
    --cc=aaron@arbor.net \
    --cc=dhowells@redhat.com \
    --cc=jm@mokwan.com \
    --cc=jordipujolp@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=patrick@frischux.de \
    --cc=viro@zeniv.linux.org.uk \
    /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).