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
Eric Dumazet wrote:
For dentry name, we certainly could use [address of inode] instead
of [inode number] to get unicity, but do we care ?
For st_ino values on pipefs and sockets, I doubt any user application would
care. I never had to fstat() a socket fd. Of course it's a file descriptor,
This patch updates pipefs to do defer assigning an i_ino value to its inodes
until someone actually tries to stat it. This allows us to have unique i_ino
values for the inodes here, without the performance impact for anyone who
doesn't actually care about it.
Since we don't have an i_ino value at
This patch adds 2 new libfs functions that allow for us to defer assignment of
an i_ino value until such time that it's actually used. This allows us to
ensure uniqueness without actually impacting the cases that don't really care
about it. With this i_ino == 0 has a special meaning of unassigned.
While working on a case, Christoph mentioned that he thought that iunique
ought to be cleaned up to use a more conventional loop construct. This patch
does that, turning the strange goto loop into a do/while.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
diff --git a/fs/inode.c b/fs/inode.c
index
Kirill Korotaev wrote:
Jeff,
taking into account the discussion about unawarness/uncertainty
of whether *unique* inode number is needed at all on pipe fds and such
do we need this at all?
Thanks,
Kirill
Fair enough, perhaps we should just not worry about it, and assume that there
might be
Jeff,
taking into account the discussion about unawarness/uncertainty
of whether *unique* inode number is needed at all on pipe fds and such
do we need this at all?
Thanks,
Kirill
Fair enough, perhaps we should just not worry about it, and assume that there
might be collisions.
If so,
On Tue, Jan 30, 2007 at 09:42:33AM +, Christoph Hellwig wrote:
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
Since posting that patch to add i_ino uniqueness to pipefs, I've gotten some
comments that have convinced me that we should probably leave it as is for
now (at least until someone we a good reason).
So, please back out that patch from -mm.
The patch below should revert pipefs to its original
From: Randy Dunlap [EMAIL PROTECTED]
Indent help text as expected.
Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
fs/dlm/Kconfig | 16
fs/gfs2/Kconfig | 47 +++
2 files changed, 31 insertions(+), 32 deletions(-)
---
On Mon, 29 Jan 2007 11:31:37 +0100 (CET)
Nick Piggin [EMAIL PROTECTED] wrote:
The following set of patches attempt to fix the buffered write
locking problems
y'know, four or five years back I fixed this bug by doing
current-locked_page = page;
in the write() code, and then teaching
On Tue, 30 Jan 2007, Bodo Eggert wrote:
change pipefs to use a unique inode number equal to the memory
address unless it would be truncated.
I *really* wouldn't want to expose kernel addresses to user space, it just
ends up being a piece of data that they shouldn't have. If we have some
Linus Torvalds wrote:
On Tue, 30 Jan 2007, Bodo Eggert wrote:
change pipefs to use a unique inode number equal to the memory
address unless it would be truncated.
I *really* wouldn't want to expose kernel addresses to user space, it just
ends up being a piece of data that they shouldn't
On Tue, 30 Jan 2007, Jeff Layton wrote:
Also, that patch would break many 32-bit programs not compiled with large
offsets when run in compatibility mode on a 64-bit kernel. If they were to
do a stat on this inode, it would likely generate an EOVERFLOW error since
the pointer address would
On Tue, Jan 30, 2007 at 03:21:19PM -0800, Andrew Morton wrote:
On Tue, 30 Jan 2007 12:55:58 -0800
Andrew Morton [EMAIL PROTECTED] wrote:
y'know, four or five years back I fixed this bug by doing
current-locked_page = page;
in the write() code, and then teaching the pagefault
15 matches
Mail list logo
