lock_rename for cluster filesystems? (was: Re: [PATCH] prune_icache_sb)

2007-03-02 Thread Mike Snitzer
On 12/4/06, Wendy Cheng <[EMAIL PROTECTED]> wrote: Russell Cattelan wrote: > Wendy Cheng wrote: > >> Linux kernel, particularly the VFS layer, is starting to show signs >> of inadequacy as the software components built upon it keep growing. >> I have doubts that it can keep up and handle this com

Re: [PATCH] prune_icache_sb

2006-12-04 Thread Wendy Cheng
Russell Cattelan wrote: Wendy Cheng wrote: Linux kernel, particularly the VFS layer, is starting to show signs of inadequacy as the software components built upon it keep growing. I have doubts that it can keep up and handle this complexity with a development policy like you just described (f

Re: [PATCH] prune_icache_sb

2006-12-04 Thread Russell Cattelan
Wendy Cheng wrote: Andrew Morton wrote: On Thu, 30 Nov 2006 11:05:32 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: The idea is, instead of unconditionally dropping every buffer associated with the particular mount point (that defeats the purpose of page caching), base kernel exports the

Re: [PATCH] prune_icache_sb

2006-12-03 Thread Andrew Morton
On Mon, 04 Dec 2006 00:57:50 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > > > > > >>>Did you look at improving that lock-lookup algorithm, btw? Core kernel has > >>>no problem maintaining millions of cached VFS objects - is there any reason > >>>why your lock lookup cannot be similarly effici

Re: [PATCH] prune_icache_sb

2006-12-03 Thread Wendy Cheng
Andrew Morton wrote: On Sun, 03 Dec 2006 12:49:42 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: I read this as "It is ok to give system admin(s) commands (that this "drop_pagecache_sb() call" is all about) to drop page cache. It is, however, not ok to give filesystem developer(s) this very

Re: [PATCH] prune_icache_sb

2006-12-03 Thread Andrew Morton
On Sun, 03 Dec 2006 12:49:42 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > >On Thu, 30 Nov 2006 11:05:32 -0500 > >Wendy Cheng <[EMAIL PROTECTED]> wrote: > > > > > > > >> > >>The idea is, instead of unconditionally dropping every buffer associated > >>with the particul

Re: [PATCH] prune_icache_sb

2006-12-03 Thread Wendy Cheng
Andrew Morton wrote: On Thu, 30 Nov 2006 11:05:32 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: The idea is, instead of unconditionally dropping every buffer associated with the particular mount point (that defeats the purpose of page caching), base kernel exports the "drop_pagecache_sb()

Re: [PATCH] prune_icache_sb

2006-12-01 Thread Andrew Morton
On Thu, 30 Nov 2006 11:05:32 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > How about a simple and plain change with this uploaded patch > > The idea is, instead of unconditionally dropping every buffer associated > with the particular mount point (that defeats the purpose of page > cachin

Re: [PATCH] prune_icache_sb

2006-11-30 Thread Nate Diller
On 11/30/06, Wendy Cheng <[EMAIL PROTECTED]> wrote: How about a simple and plain change with this uploaded patch The idea is, instead of unconditionally dropping every buffer associated with the particular mount point (that defeats the purpose of page caching), base kernel exports the "drop

Re: [PATCH] prune_icache_sb

2006-11-30 Thread Wendy Cheng
How about a simple and plain change with this uploaded patch The idea is, instead of unconditionally dropping every buffer associated with the particular mount point (that defeats the purpose of page caching), base kernel exports the "drop_pagecache_sb()" call that allows page cache to be

Re: [PATCH] prune_icache_sb

2006-11-28 Thread Wendy Cheng
Andrew Morton wrote: We shouldn't export this particular implementation to modules because it has bad failure modes. There might be a case for exposing an i_sb_list-based API or, perhaps better, a max-unused-inodes mount option. Ok, thanks for looking into this - it is appreciated. I'll tr

Re: [PATCH] prune_icache_sb

2006-11-28 Thread Andrew Morton
On Tue, 28 Nov 2006 16:41:07 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > On Mon, 27 Nov 2006 18:52:58 -0500 > > Wendy Cheng <[EMAIL PROTECTED]> wrote: > > > > > >> Not sure about walking thru sb->s_inodes for several reasons > >> > >> 1. First, the changes made a

Re: [PATCH] prune_icache_sb

2006-11-28 Thread Wendy Cheng
Andrew Morton wrote: On Mon, 27 Nov 2006 18:52:58 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: Not sure about walking thru sb->s_inodes for several reasons 1. First, the changes made are mostly for file server setup with large fs size - the entry count in sb->s_inodes may not be shorte

Re: [PATCH] prune_icache_sb

2006-11-27 Thread Andrew Morton
On Mon, 27 Nov 2006 18:52:58 -0500 Wendy Cheng <[EMAIL PROTECTED]> wrote: > Andrew Morton wrote: > > This search is potentially inefficient. It would be better walk > > sb->s_inodes. > > > > > Not sure about walking thru sb->s_inodes for several reasons > > 1. First, the changes made are

Re: [PATCH] prune_icache_sb

2006-11-27 Thread Wendy Cheng
Andrew Morton wrote: This search is potentially inefficient. It would be better walk sb->s_inodes. Not sure about walking thru sb->s_inodes for several reasons 1. First, the changes made are mostly for file server setup with large fs size - the entry count in sb->s_inodes may not be s