On Wed, Feb 20, 2008 at 03:36:53PM +0100, Ferenc Wagner wrote:
> David Chinner <[EMAIL PROTECTED]> writes:
> > The xfs inodes are clearly pinned by the dentry cache, so the issue
> > is dentries, not inodes. What's causing dentries not to be
> > reclaimed? I can't see anything that cold pin them
David Chinner <[EMAIL PROTECTED]> writes:
> The xfs inodes are clearly pinned by the dentry cache, so the issue
> is dentries, not inodes. What's causing dentries not to be
> reclaimed? I can't see anything that cold pin them (e.g. no filp's
> that would indicate open files being responsible),
David Chinner [EMAIL PROTECTED] writes:
The xfs inodes are clearly pinned by the dentry cache, so the issue
is dentries, not inodes. What's causing dentries not to be
reclaimed? I can't see anything that cold pin them (e.g. no filp's
that would indicate open files being responsible), so my
On Wed, Feb 20, 2008 at 03:36:53PM +0100, Ferenc Wagner wrote:
David Chinner [EMAIL PROTECTED] writes:
The xfs inodes are clearly pinned by the dentry cache, so the issue
is dentries, not inodes. What's causing dentries not to be
reclaimed? I can't see anything that cold pin them (e.g. no
On Tue, Feb 19, 2008 at 05:57:08PM +0100, Ferenc Wagner wrote:
> David Chinner <[EMAIL PROTECTED]> writes:
> > On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
> So, I loaded the same kernel on a different machine, but that seems to
> exhibit a very similar behaviour. The machine is
David Chinner <[EMAIL PROTECTED]> writes:
> On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
>
>> 5 days ago I pulled the git tree (HEAD was
>> 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
>> (the vmsplice fix and the GFS1 exports), compiled and booted the
>>
David Chinner [EMAIL PROTECTED] writes:
On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
5 days ago I pulled the git tree (HEAD was
25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
(the vmsplice fix and the GFS1 exports), compiled and booted the
kernel.
On Tue, Feb 19, 2008 at 05:57:08PM +0100, Ferenc Wagner wrote:
David Chinner [EMAIL PROTECTED] writes:
On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
So, I loaded the same kernel on a different machine, but that seems to
exhibit a very similar behaviour. The machine is
David Chinner <[EMAIL PROTECTED]> writes:
> On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
>
>> 5 days ago I pulled the git tree (HEAD was
>> 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
>> (the vmsplice fix and the GFS1 exports), compiled and booted the
>>
On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
> Hi,
>
> 5 days ago I pulled the git tree (HEAD was
> 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
> (the vmsplice fix and the GFS1 exports), compiled and booted the
> kernel. Things are working OK, but I
On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
Hi,
5 days ago I pulled the git tree (HEAD was
25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
(the vmsplice fix and the GFS1 exports), compiled and booted the
kernel. Things are working OK, but I noticed
David Chinner [EMAIL PROTECTED] writes:
On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
5 days ago I pulled the git tree (HEAD was
25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
(the vmsplice fix and the GFS1 exports), compiled and booted the
kernel.
Hi,
5 days ago I pulled the git tree (HEAD was
25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
(the vmsplice fix and the GFS1 exports), compiled and booted the
kernel. Things are working OK, but I noticed that inode usage has
been steadily rising since then (see attached
Hi,
5 days ago I pulled the git tree (HEAD was
25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
(the vmsplice fix and the GFS1 exports), compiled and booted the
kernel. Things are working OK, but I noticed that inode usage has
been steadily rising since then (see attached
14 matches
Mail list logo