From: Christoph Hellwig <hch@infradead.org>
To: "Josef 'Jeff' Sipek" <jsipek@cs.sunysb.edu>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
akpm@osdl.org
Subject: Re: [PATCH 4/4] fs/unionfs/: Don't duplicate the struct nameidata
Date: Tue, 30 Jan 2007 09:42:33 +0000 [thread overview]
Message-ID: <20070130094233.GA6972@infradead.org> (raw)
In-Reply-To: <11701030643398-git-send-email-jsipek@cs.sunysb.edu>
On Mon, Jan 29, 2007 at 03:37:42PM -0500, Josef 'Jeff' Sipek wrote:
> The only fields that we have to watch out for are the dentry and vfsmount.
> Additionally, this makes Unionfs gentler on the stack as nameidata is rather
> large.
That's onviously not true at all. To handle any filesystems using intents
(e.g. NFSv4) you need to do much more. Then again doing things correctly
doesn't seem to be interesting to the stackable filesystems crowd an this
problem has been constantly ignored over the last year, including merging
ecryptfs which has been broken in the same way.
Folks, if you want your stackable filesystem toys taken seriously you
need to fix these kind of issues instead of talking them away. And yes,
this will involve some surgery to the VFS.
next prev parent reply other threads:[~2007-01-30 9:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 20:37 [GIT PULL -mm] Unionfs updates/cleanups Josef 'Jeff' Sipek
2007-01-29 20:37 ` [PATCH 1/4] fs/unionfs/: Remove stale_inode.c Josef 'Jeff' Sipek
2007-01-29 20:37 ` [PATCH 2/4] fs/unionfs/: possible cleanups Josef 'Jeff' Sipek
2007-01-29 20:37 ` [PATCH 3/4] fs/unionfs/: Andrew Morton's comments Josef 'Jeff' Sipek
2007-01-29 20:37 ` [PATCH 4/4] fs/unionfs/: Don't duplicate the struct nameidata Josef 'Jeff' Sipek
2007-01-30 9:42 ` Christoph Hellwig [this message]
2007-01-30 17:52 ` Josef Sipek
2007-01-29 20:37 ` Josef 'Jeff' Sipek
2007-01-29 20:40 ` Josef Sipek
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=20070130094233.GA6972@infradead.org \
--to=hch@infradead.org \
--cc=akpm@osdl.org \
--cc=jsipek@cs.sunysb.edu \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@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 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.