On Friday 18 January 2008, Chris mason wrote:
On Thursday 17 January 2008, Christian Hesse wrote:
On Thursday 17 January 2008, Chris mason wrote:
So, I've put v0.11 out there.
Ok, back to the suspend problem I mentioned:
[ oopsen ]
I get this after a suspend/resume cycle with
2008/1/21, Christian Hesse [EMAIL PROTECTED]:
Back in early december I reported the problem for btrfs 0.9. Seems like the
lockfs call still is not implemented. Any hints what I need when I try to
code it myself?
Please try this dirty patch. I think it can solve your problem.
Regards
YZ
---
On Monday 21 January 2008, Yan Zheng wrote:
2008/1/21, Christian Hesse [EMAIL PROTECTED]:
Back in early december I reported the problem for btrfs 0.9. Seems like
the lockfs call still is not implemented. Any hints what I need when I
try to code it myself?
Please try this dirty patch. I
Miklos,
You have removed the code that checked if the peer or
master mount was in the same namespace before reporting their
corresponding mount-ids. One downside of that approach is the
user will see an mount_id in the output with no corresponding
line to
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Don't require the user_id= and group_id= options for unprivileged mounts,
but if they are present, verify them for sanity.
Disallow the allow_other option for unprivileged mounts.
FUSE was designed from
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated.
If the parent has the nosuid flag, set this flag for the child as
well. This is needed for
What do you think about doing this only if FS_SAFE is also set,
so for instance at first only FUSE would allow itself to be
made user-mountable?
A safe thing to do, or overly intrusive?
It goes somewhat against the no policy in kernel policy ;). I think
the warning in the documentation
On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
You have removed the code that checked if the peer or
master mount was in the same namespace before reporting their
corresponding mount-ids. One downside of that approach is the
user will see an mount_id in the output
On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
You have removed the code that checked if the peer or
master mount was in the same namespace before reporting their
corresponding mount-ids. One downside of that approach is the
user will see an mount_id in the output
On Jan 16, 2008 13:30 -0800, Valerie Henson wrote:
I have a partial solution that sort of blindly manages the buffer
cache. First, the user passes e2fsck a parameter saying how much
memory is available as buffer cache. The readahead thread reads
things in and immediately throws them away so
On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
On Jan 16, 2008 13:30 -0800, Valerie Henson wrote:
I have a partial solution that sort of blindly manages the buffer
cache. First, the user passes e2fsck a parameter saying how much
memory is available as buffer cache. The
On Jan 21, 2008 23:17 -0500, [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008 14:38:30 +1100, David Chinner said:
Perhaps instead of swapping immediately, a SIGLOWMEM could be sent
to a processes that aren't masking the signal followed by a short
grace period to allow the processes to free up
On Jan 22, 2008 14:38 +1100, David Chinner wrote:
On Mon, Jan 21, 2008 at 04:00:41PM -0700, Andreas Dilger wrote:
I discussed this with Ted at one point also. This is a generic problem,
not just for readahead, because fsck can run multiple e2fsck in parallel
and in case of many large
13 matches
Mail list logo
