On Dec 03, 2006 08:10 -0800, Sage Weil wrote:
> My only concern is the "at least as recent as the opendir()" part,
> in contrast to statlite(), which has undefined "recentness" of its
> result for fields not specified in the mask.
>
> Ideally, I'd like to see readdirplus() also take a statlite()
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
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
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
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()
On Sat, 2 Dec 2006, Andreas Dilger wrote:
Just to be clear, I have no desire to include any kind of
"synchronization" semantics to readdirplus() that is also being discussed
in this thread. Just the ability to bundle select stat info along with
the readdir information, and to allow stat to not r
Brad Boyer wrote:
This sounds slightly petty to me. For example, generic_file_read() is
there just to make it easier to implement the read callback, but it
isn't required. In fact, I would think that any filesystem complex
enough to be worth making proprietary would not use it. However, that
doe
Brad Boyer wrote:
> To be honest, I think it looks bad for someone associated with redhat
> to be suggesting that life should be made more difficult for those
> who write proprietary software on Linux. The support from commercial
> software is a major reason for the success of the RHEL product line