public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Jamie Lokier <jamie@shareable.org>
Cc: Phillip Lougher <phillip@lougher.demon.co.uk>,
	David Newall <davidn@davidnewall.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	hch@lst.de
Subject: Re: [RFC 0/7] [RFC] cramfs: fake write support
Date: Sun, 1 Jun 2008 23:49:28 +0200	[thread overview]
Message-ID: <200806012349.29538.arnd@arndb.de> (raw)
In-Reply-To: <20080601122818.GA3687@shareable.org>

On Sunday 01 June 2008, Jamie Lokier wrote:
> Ok, so why not fix that in unionfs?  An option so that holes in the
> overlay file let through data from the underlying file sounds like it
> would be generally useful, and quite easy to implement.

I can imagine a lot of unexpected effects with that. Think of e.g.
someone replacing the underlying file with a new one. Then enlarge
the file using truncate() and read from it -- suddenly you see
the old contents instead of zeroes. Probably fixable as well, but
certainly not in a nice way.

Besides, there are a many more problems with unionfs, which have
all been mentioned in the previous review cycles. Aufs doesn't
address those either AFAIK, with the exception of at least
not making additional copies in the page cache when writing to
a file.

The real solution of course are VFS based union mounts (think
'mount --union -t tmpfs none /'), but the patches for that
are not stable enough for inclusion in mainline yet.

> If not unionfs, a "union-tmpfs" combination would be good.  Many
> filesystems aren't well suited to being the overlay filesystem -
> adding to the implementation's complexity - but a modified tmpfs could
> be very well suited.

Yes, that is similar to one of my earlier ideas as well. Christoph
managed to convince me that it's not as easy as I thought, though
I can't remember the exact arguments any more. I'll try to think
about that some more.

One of the problems is certainly the complexity involved in tmpfs
to start with, which is the reason I based the code on ramfs instead.

	Arnd <><

  reply	other threads:[~2008-06-01 21:50 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-31 15:37 [RFC 0/7] [RFC] cramfs: fake write support arnd
2008-05-31 18:56 ` David Newall
2008-05-31 20:40   ` Arnd Bergmann
2008-06-01  3:54     ` Phillip Lougher
2008-06-01  8:52       ` Arnd Bergmann
2008-06-01 12:28       ` Jamie Lokier
2008-06-01 21:49         ` Arnd Bergmann [this message]
2008-06-02  2:48           ` hooanon05
2008-06-02  3:25             ` Erez Zadok
2008-06-02  7:51               ` Arnd Bergmann
2008-06-02 18:13                 ` Erez Zadok
2008-06-03  2:02                   ` Phillip Lougher
2008-06-02  3:51             ` Erez Zadok
2008-06-02 11:07               ` Jamie Lokier
2008-06-02  4:37             ` Erez Zadok
2008-06-02  6:07               ` Bharata B Rao
2008-06-02  7:17               ` Jan Engelhardt
2008-06-02  7:12             ` Arnd Bergmann
2008-06-02 10:36               ` hooanon05
2008-06-02 11:15                 ` Arnd Bergmann
2008-06-02 12:56                   ` hooanon05
2008-06-02 14:13                     ` Arnd Bergmann
2008-06-02 14:33                       ` hooanon05
2008-06-02 15:01                         ` Arnd Bergmann
2008-06-03 11:04                           ` hooanon05
2008-06-02 14:54                   ` Evgeniy Polyakov
2008-06-02 17:42                     ` Arnd Bergmann
2008-06-02 15:35               ` Erez Zadok
2008-06-01  6:02     ` David Newall
2008-06-01  9:11       ` Jan Engelhardt
2008-06-01 16:25       ` Jörn Engel
2008-06-01  3:19 ` Phillip Lougher

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=200806012349.29538.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=davidn@davidnewall.com \
    --cc=hch@lst.de \
    --cc=jamie@shareable.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillip@lougher.demon.co.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