On Tue, Jan 15 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Chris Mason wrote:
Hello everyone,
Here is a modified version of Jens' patch. The basic idea is to push
the mapping maintenance out of loop and down into the filesystem (ext2
in
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Allow clone_mnt() to return errors other than ENOMEM. This will be used for
returning a different error value when the number of user mounts goes over
the
limit.
Fix copy_tree() to return EPERM
On Tue, Jan 15 2008, Jens Axboe wrote:
On Tue, Jan 15 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Jens Axboe wrote:
On Mon, Jan 14 2008, Chris Mason wrote:
Hello everyone,
Here is a modified version of Jens' patch. The basic idea is to push
the mapping maintenance out of
On Jan 15, 2008 8:41 AM, Miklos Szeredi [EMAIL PROTECTED] wrote:
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
From: Miklos Szeredi [EMAIL PROTECTED]
Add a new mount flag nomnt, which denies submounts for the owner.
This would be useful, if we want to support traditional /etc/fstab
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. Also if the parent has the
nosuid flag, set this flag for the child as well.
What
Sounds like a sysctl to enable FS_SAFE for fuse will make this patch
acceptable to everyone?
I think the most generic approach, is to be able to set safeness for
any fs type, not just fuse (Karel's suggestion).
E.g:
echo 1 /proc/sys/fs/types/cifs/safe
This would also provide a way to
Why not nosubmnt?
Why not indeed. Maybe I should try to use my brain sometime.
Thanks,
Miklos
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Remove redirty_tail(). It's no longer used.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c | 24
1 files changed, 24 deletions(-)
--- linux-mm.orig/fs/fs-writeback.c
+++
Redirtied inodes could be seen in really fast writes.
They should really be synced as soon as possible.
redirty_tail() could delay the inode for up to 30s.
Kill the delay by using requeue_io() instead.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by:
The `truncated' page in block_write_full_page() may stick for a long time.
E.g. ext2_rmdir() will set i_size to 0, and then the dir inode may hang around
because of being referenced by someone.
So clear PAGECACHE_TAG_DIRTY to prevent pdflush from retrying and iowaiting on
it.
Tested-by: Joerg
Replace redirty_tail() with queue_dirty() on memory backed bdi.
It makes no difference - only simpler.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c |2 +-
1 files changed, 1 insertion(+), 1
Introduce super_block.s_more_io_wait to park inodes that for some reason cannot
be synced immediately. They will be revisited in the next s_io enqueue
time(=5s).
The new data flow after this patchset:
s_dirty -- s_io -- s_more_io/s_more_io_wait --+
^
Convert to requeue_io_wait() for case:
- kupdate cannot write all pages due to some blocking condition;
- during sync, a file is being written to too fast, starving other
files.
In the case of sync, requeue_io_wait() can break the starvation because the
inode requeued
Convert to requeue_io_wait() for case:
inode is locked.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
---
Merge duplicate code from background_writeout() and wb_kupdate() into
writeback_some_pages().
The pages_skipped in background_writeout() is ignored. The inode cannot be
written now will be retried in the next run of pdflush, typically in 5s.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter
Make the if-else straight in __sync_single_inode().
No behavior change.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c | 15 +++
1 files changed, 7 insertions(+), 8 deletions(-)
---
Convert to requeue_io_wait() for case:
pages skipped due to locked buffers.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
---
Introduce queue_dirty() to enqueue a newly dirtied inode.
It helps remove duplicate code.
Cc: Michael Rubin [EMAIL PROTECTED]
Cc: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Fengguang Wu [EMAIL PROTECTED]
---
fs/fs-writeback.c | 21 +
1 files changed, 13 insertions(+),
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
Sounds like a sysctl to enable FS_SAFE for fuse will make this patch
acceptable to everyone?
I think the most generic approach, is to be able to set safeness for
any fs type, not just fuse (Karel's suggestion).
E.g:
echo 1
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
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. Also if the parent has the
nosuid flag,
On Mon, Jan 14, 2008 at 09:26:06PM -0700, Matthew Wilcox wrote:
On Mon, Jan 14, 2008 at 03:44:19PM -0500, J. Bruce Fields wrote:
Thanks! I've queued it up for 2.6.25.
Hi Bruce,
I haven't had as much time to play with de-BKL-ising fs/locks.c as I
would like, so fixing that for 2.6.25 is
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated. Also if the parent has the
nosuid flag, set this flag for the child as well.
What about nodev?
Hmm, I think the nosuid thing is meant to prevent suid mounts
On Mon, Jan 14, 2008 at 09:28:30PM -0700, Matthew Wilcox wrote:
interruptible_sleep_on_locked() is just an open-coded
wait_event_interruptible_timeout() with a few assumptions since we know
we hold the BKL. locks_block_on_timeout() is only used in one place, so
it's actually simpler to
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
On mount propagation, let the owner of the clone be inherited from the
parent into which it has been propagated. Also if the parent has the
nosuid flag, set this flag for the child as well.
What about nodev?
Hmm, I think
On Tue, Jan 15, 2008 at 09:48:51AM -0500, J. Bruce Fields wrote:
On Mon, Jan 14, 2008 at 09:28:30PM -0700, Matthew Wilcox wrote:
interruptible_sleep_on_locked() is just an open-coded
wait_event_interruptible_timeout() with a few assumptions since we know
we hold the BKL.
On Fri, 2007-12-14 at 17:16 +0200, Pekka J Enberg wrote:
+static int revoke_files(struct inode *inode)
+{
+ struct super_block *sb;
+ struct file *file;
+ int err = 0;
+
+ sb = inode-i_sb;
+ if (!sb)
+ return -EINVAL;
+
+restart:
+
Hello everyone,
Btrfs v0.10 is now available for download from:
http://oss.oracle.com/projects/btrfs/
Btrfs is still in an early alpha state, and the disk format is not finalized.
v0.10 introduces a new disk format, and is not compatible with v0.9.
The core of this release is explicit back
On Tue, Jan 15, 2008 at 10:52:38AM -0500, Chris Mason wrote:
http://oss.oracle.com/projects/btrfs/
Btrfs is still in an early alpha state, and the disk format is not finalized.
v0.10 introduces a new disk format, and is not compatible with v0.9.
Looks like fun. btrfsck fails to check if it
On Tue, Jan 15, 2008 at 04:14:54PM +0100, Peter Zijlstra wrote:
Humm, we were trying to get rid of file_list_lock(), this puts up
another user of the sb file list.
Also, that loop looks horribly expensive: n*(1+m); where n is the list
size, and m the number of matching fds.
Granted, I see
On Jan 15, 2008 4:36 AM, Fengguang Wu [EMAIL PROTECTED] wrote:
Andrew,
This patchset mainly polishes the writeback queuing policies.
Anyone know which tree is this patched based out of?
The main goals are:
(1) small files should not be starved by big dirty files
(2) sync as fast as
On Mon, Jan 14, 2008 at 09:29:39PM -0700, Matthew Wilcox wrote:
Reduce the spaghetti-like nature of flock_lock_file by making the chunk
of code labelled find_conflict into its own function. Also allocate
memory before taking the kernel lock in preparation for switching to a
normal spinlock.
On Tue, Jan 15, 2008 at 08:04:47AM -0700, Matthew Wilcox wrote:
On Tue, Jan 15, 2008 at 09:48:51AM -0500, J. Bruce Fields wrote:
On Mon, Jan 14, 2008 at 09:28:30PM -0700, Matthew Wilcox wrote:
interruptible_sleep_on_locked() is just an open-coded
wait_event_interruptible_timeout() with a
Hi!
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks that did this rapidly got firmware updates
because there are other
On Tue, Jan 15, 2008 at 09:16:53PM +0100, Pavel Machek wrote:
Hi!
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks
Hi!
What are ext3 expectations of disk (is there doc somewhere)? For
example... if disk does not lie, but powerfail during write damages
the sector -- is ext3 still going to work properly?
Nope. However the few disks that did this rapidly got firmware updates
because there
On Jan 15, 2008 6:07 PM, Pavel Machek [EMAIL PROTECTED] wrote:
I had write cache enabled on my main computer. Oops. I guess that
means we do need better documentation.
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice to know which brands fail here, if any,
because writeback
Hello.
Serge E. Hallyn wrote:
I must say I personally prefer the apparmor approach.
No problem.
But I'd recommend
you get together and get this piece pushed on its own, whichever version
you can agree on.
TOMOYO can use AppArmor's patch.
Yes it needs a user, but at this point I would think
On Jan 15, 2008 7:15 PM, Alan Cox [EMAIL PROTECTED] wrote:
Writeback cache on disk in iteself is not bad, it only gets bad if the
disk is not engineered to save all its dirty cache on power loss,
using the disk motor as a generator or alternatively a small battery.
It would be awfully nice
On Tue, 15 Jan 2008 20:24:27 -0500
Daniel Phillips [EMAIL PROTECTED] wrote:
On Jan 15, 2008 7:15 PM, Alan Cox [EMAIL PROTECTED] wrote:
Writeback cache on disk in iteself is not bad, it only gets bad
if the disk is not engineered to save all its dirty cache on
power loss, using the disk
Hi Pavel,
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
Regards,
Daniel
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL
On Tue, Jan 15, 2008 at 10:33:01AM -0800, Michael Rubin wrote:
On Jan 15, 2008 4:36 AM, Fengguang Wu [EMAIL PROTECTED] wrote:
Andrew,
This patchset mainly polishes the writeback queuing policies.
Anyone know which tree is this patched based out of?
They are against the latest -mm tree,
On Tue, 15 Jan 2008 20:44:38 -0500
Daniel Phillips [EMAIL PROTECTED] wrote:
Along with this effort, could you let me know if the world actually
cares about online fsck? Now we know how to do it I think, but is it
worth the effort.
With a filesystem that is compartmentalized and checksums
43 matches
Mail list logo
