Badari Pulavarty (BP) writes:
BP In order to do the correct accounting, we need to mark a page
BP to indicate if we reserved a block or not. One way to do this,
BP to use page-private to indicate this. But then, all the generic
BP routines will fail - since they assume that page-private
Badari Pulavarty [EMAIL PROTECTED] writes:
[...]
Yes. Its possible to do what you want to. I am currently working on
adding delayed allocation support to ext3. As part of that, We
As you most likely already know, Alex Thomas already implemented delayed
block allocation for ext3.
[...]
In
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
users/groups were
Hello,
here is a patch to fix the problem discussed at the [PATC] small VFS
change for JFFS2 thread in LKML (http://lkml.org/lkml/2005/4/18/77).
The problem description:
~~
prune_icache() removes inodes from the inode hash (inode-i_hash) and
drops the node_lock spinlock. If
On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote:
Badari Pulavarty [EMAIL PROTECTED] writes:
[...]
Yes. Its possible to do what you want to. I am currently working on
adding delayed allocation support to ext3. As part of that, We
As you most likely already know, Alex Thomas already
Badari Pulavarty (BP) writes:
you can introduce one more bit to page-flags
BP Agreed. I was hoping to avoid it as much as I can.
well, you're gonna modify mpage api anyway ...
BP What I meant by jounalling mode is that - after the pages are submitted
BP for IO, we need some way of
On Tue, 2005-04-19 at 08:04, Alex Tomas wrote:
Badari Pulavarty (BP) writes:
you can introduce one more bit to page-flags
BP Agreed. I was hoping to avoid it as much as I can.
well, you're gonna modify mpage api anyway ...
Okay, I will give a serious look then. Last time, I tried
Badari Pulavarty (BP) writes:
2) Andrew proposed the excelent solution
BP Well, I wasn't sure how heavy thats going to be. He was recommending
BP that we flush all dirty pages from all inodes for each transaction
BP commit. Isn't it ?
this is exactly what ext3 does being mounted with
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
Badari Pulavarty [EMAIL PROTECTED] writes:
On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote:
Badari Pulavarty [EMAIL PROTECTED] writes:
[...]
Yes. Its possible to do what you want to. I am currently working on
adding delayed allocation support to ext3. As part of that, We
As you
Nikita Danilov (ND) writes:
In order to do the correct accounting, we need to mark a page
to indicate if we reserved a block or not. One way to do this,
to use page-private to indicate this. But then, all the generic
I believe one can use PG_mappedtodisk bit in page-flags for this
Alex Tomas wrote:
Nikita Danilov (ND) writes:
In order to do the correct accounting, we need to mark a page
to indicate if we reserved a block or not. One way to do this,
to use page-private to indicate this. But then, all the generic
I believe one can use PG_mappedtodisk bit in
On Tue, 2005-04-19 at 19:55 +0400, Nikita Danilov wrote:
Badari Pulavarty [EMAIL PROTECTED] writes:
On Tue, 2005-04-19 at 04:22, Nikita Danilov wrote:
Badari Pulavarty [EMAIL PROTECTED] writes:
[...]
Yes. Its possible to do what you want to. I am currently working on
adding
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote:
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
Do folks think
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
-
To unsubscribe from this list: send the
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount system calls -- adding a flag which created a
new namespace for the resulting
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
Based on some of the FUSE permissions discussions, I wanted to check
into modifying the mount
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation at mount/bind time.
*UGH*
So what happens to those who happen to
routines will fail - since they assume that page-private represents
bufferheads. So we need a better way to do this.
They are not generic then. Some file systems store things completely
different from buffer head ring in page-private.
I've seen these instances (and worked around them because I
This is again related to the FUSE permission thread, but a slightly
different idea and without a slimy hack patch.
I really want to enable users to be able to create private namespaces,
but I want to try and avoid creating a venerability by allowing them
to abuse system resources. It looks like
On Tue, 2005-04-19 at 18:24, Eric Van Hensbergen wrote:
This is again related to the FUSE permission thread, but a slightly
different idea and without a slimy hack patch.
I really want to enable users to be able to create private namespaces,
but I want to try and avoid creating a
On Tue, Apr 19, 2005 at 06:53:29PM -0500, Eric Van Hensbergen wrote:
On 4/19/05, Al Viro [EMAIL PROTECTED] wrote:
On Tue, Apr 19, 2005 at 05:13:32PM -0500, Eric Van Hensbergen wrote:
The motivation behind this patch is to make private namespaces more
accessible by allowing their creation
You are right. A more priviledged process running as a child of
another process should not be allowed to look at the same namespace as
its parent. However, there is atleast one other example where
something like this exists and there is a counter for that. We can
learn from the counter.
Consider
Eric Van Hensbergen wrote:
Somewhat related question for Viro/the group:
Why is CLONE_NEWNS considered a priveledged operation? Would placing
limits on the number of private namespaces a user can own solve any
resource concerns or is there something more nefarious I'm missing?
-
To
24 matches
Mail list logo
