What needs to be done before the big kernel lock can moved in favor of
the finer-grained inode lock?
Thanks,
Jeff
--
Jeff Garzik | Just once, I wish we would encounter
Building 1024| an alien menace that wasn't immune to
MandrakeSoft, Inc. | bullets.
On Fri, 3 Dec 1999, Jeff Garzik wrote:
What needs to be done before the big kernel lock can moved in favor of
the finer-grained inode lock?
knfsd cleanup. SMP-safe dcache. SMP-safe namei.c. And quite a bit of
filesystem code.
Hi Linus,
when grab_cache_page was added to kernel, someone who did global
kernel search replace swapped grab_cache_page and find_lock_page
in ncpfs :-( Because of ncpfs requires page allocation to success,
it did not work as it did find instead of allocation... These
changes are limited to
On Fri, 3 Dec 1999, Richard Gooch wrote:
What? Having group write on the directory? No thanks.
You can't hardlink a directory.
I'll tell another way that will let you understand correctly for sure.
I want that the i_link of an inode can be changed only by an user that has
write permissions on
On Fri, Dec 03, 1999 at 12:18:19PM -0500, Alexander Viro wrote:
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
I don't like having only coda breaking the semantic. You'll end getting
reports of "program X doesn't work with coda, why?". If you'll break the
semantic in the VFS the program
On Fri, 3 Dec 1999, Alexander Viro wrote:
Andrea, you _do_ realize that CODA is not a Linux-only thing? So it's
Have I ever talked about coda in first place?
Andrea
On Fri, 3 Dec 1999, Alexander Viro wrote:
... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
a separate filesystem.
Would you call this a solution? This is a very ugly workaround. The fact
this works is only a side effect of the limitations of the hardlink.
So another
Alexander Viro writes:
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
On Fri, 3 Dec 1999, Richard Gooch wrote:
A hard link is the ideal solution. Many users can "lock" the file so
that they will retain access to it without consuming more space. When
each user has lost interest, the
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
I don't need quota for myself either. So? Do you suggest to remove quota
from the kernel because me and you don't need it? You can't just take
decisions for everybody only looking at your needs. Or you should then say
"this system is insecure and
Andrea Arcangeli writes:
On Fri, 3 Dec 1999, Richard Gooch wrote:
And I want the opposite: I want any user to be able to make hard links
to my files, without needing write access to the inodes, and without
needing some stupid set{u|g}id binary.
Any sane workgroup project uses an unix
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
Really it seems nobody cares about the implications of the problem and if
nobody needs the change I don't need it either for myself. So probably
it's better to put the change in an unofficial patch (for example in the
Solar's secure-linux patch
In message [EMAIL PROTECTED], Andrea
Arcang
eli writes:
+-
| then. It's a namespace issue. If I put my inode in my directory it must
| not finish into /tmp after some time by somebody that has nothing to do
| with me.
+---8
*bzzzt*
"Namespace issue"? Perhaps you should learn some Unix
Alexander Viro writes:
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
I don't need quota for myself either. So? Do you suggest to remove quota
from the kernel because me and you don't need it? You can't just take
decisions for everybody only looking at your needs. Or you should then say
Andrea Arcangeli writes:
On Fri, 3 Dec 1999, Richard Gooch wrote:
What? Having group write on the directory? No thanks.
You can't hardlink a directory.
Duh. I know that. One proposal was to use access permissions on the
directory to determine if hardlinking was allowed. Yuk.
I'll tell
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
On Fri, 3 Dec 1999, Alexander Viro wrote:
Oh, great. So your reasons should pass for arbitrary filesystem, right?
It's always been so. Sorry if I am been not clear. I was talking about the
VFS not about lowlevel fs. I don't either know why
On Fri, 3 Dec 1999, Andrea Arcangeli wrote:
On Fri, 3 Dec 1999, Alexander Viro wrote:
... and F- on UNIX SA 101 - if you don't know the reasons to keep /tmp on
a separate filesystem.
Would you call this a solution? This is a very ugly workaround. The fact
this works is only a side
16 matches
Mail list logo
