How long can an inode structure reside in the inode_cache?

How long can an inode structure reside in the inode_cache?

[Xin Zhao]

I was wondering how Linux decide to free an inode from the
inode_cache? If a file is open, an inode structure will be created and
put into the inode_cache, but when will this inode be free and removed
from the inode_cache? after this file is closed? If so, this seems to
be inefficient.

Can someone tell me how Linux handle this issue?

Thanks,
Xin

Re: How long can an inode structure reside in the inode_cache?

[Matthew Wilcox]

On Fri, Jun 09, 2006 at 08:10:10PM -0400, Xin Zhao wrote:
> I was wondering how Linux decide to free an inode from the
> inode_cache? If a file is open, an inode structure will be created and
> put into the inode_cache, but when will this inode be free and removed
> from the inode_cache? after this file is closed? If so, this seems to
> be inefficient.

how can you possibly release an inode while the file's still open?
look at all the information stored in the inode, like the length of the
file, last accessed time, not to mention which filesystem the inode
belongs to.

Re: How long can an inode structure reside in the inode_cache?

[Xin Zhao]

No. I guess I didn't make my question clear.

My question is: Will an inode be released after the last file refers
to this is closed? If so, this could bring a performance issue.
Consider this case: a process open a file, read it, close it, then
reopen this file, read it, close it. For every open,  the inode has to
be read from disk again, which make hurt performance.

So I think inode should stay in inode_cache for a while, not released
right after the last file stops referring it. I just want to know
whether my guess is right. If it is, when will kernel release the
inode, since an inode cannot stay in memory forever.

xin

On 6/10/06, Matthew Wilcox <matthew@wil.cx> wrote:
> On Fri, Jun 09, 2006 at 08:10:10PM -0400, Xin Zhao wrote:
> > I was wondering how Linux decide to free an inode from the
> > inode_cache? If a file is open, an inode structure will be created and
> > put into the inode_cache, but when will this inode be free and removed
> > from the inode_cache? after this file is closed? If so, this seems to
> > be inefficient.
>
> how can you possibly release an inode while the file's still open?
> look at all the information stored in the inode, like the length of the
> file, last accessed time, not to mention which filesystem the inode
> belongs to.
>

Re: How long can an inode structure reside in the inode_cache?

[Jeff Mahoney]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Xin Zhao wrote:
> No. I guess I didn't make my question clear.
> 
> My question is: Will an inode be released after the last file refers
> to this is closed? If so, this could bring a performance issue.
> Consider this case: a process open a file, read it, close it, then
> reopen this file, read it, close it. For every open,  the inode has to
> be read from disk again, which make hurt performance.
> 
> So I think inode should stay in inode_cache for a while, not released
> right after the last file stops referring it. I just want to know
> whether my guess is right. If it is, when will kernel release the
> inode, since an inode cannot stay in memory forever.

That's pretty much exactly what happens. The kernel caches inodes and
dentries when memory usage allows. When the last reference to an inode
is dropped and the file system is still in use, the inode goes on the
unused_inode list. It remains linked to the inode hash table. When a
inode is requested, the hash table is checked before trying to read it
back from disk. Check out generic_forget_inode() and ifind().

When there is memory pressure, the VM system will shrink these caches.
inode_init() registers a callback for the VM to call
shrink_icache_memory () which will finally free the memory. Check out
mm/vmscan.c and fs/inode.c for more detailed information.

- -Jeff

- --
Jeff Mahoney
SUSE Labs


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEixcGLPWxlyuTD7IRAn1SAJ4yjgtJ9YL321W/18a7nttlaEc9pACeIMJX
yNUuC/impK4eZpHpLkwtCOQ=
=ykbS
-----END PGP SIGNATURE-----

Re: How long can an inode structure reside in the inode_cache?

[UZAIR LAKHANI]

--- Jeff Mahoney <jeffm@suse.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Xin Zhao wrote:
> > No. I guess I didn't make my question clear.
> > 
> > My question is: Will an inode be released after
> the last file refers
> > to this is closed? If so, this could bring a
> performance issue.
> > Consider this case: a process open a file, read
> it, close it, then
> > reopen this file, read it, close it. For every
> open,  the inode has to
> > be read from disk again, which make hurt
> performance.
> > 
> > So I think inode should stay in inode_cache for a
> while, not released
> > right after the last file stops referring it. I
> just want to know
> > whether my guess is right. If it is, when will
> kernel release the
> > inode, since an inode cannot stay in memory
> forever.
> 
> That's pretty much exactly what happens. The kernel
> caches inodes and
> dentries when memory usage allows. When the last
> reference to an inode
> is dropped and the file system is still in use, the
> inode goes on the
> unused_inode list. It remains linked to the inode
> hash table. When a
> inode is requested, the hash table is checked before
> trying to read it
> back from disk. Check out generic_forget_inode() and
> ifind().
> 
> When there is memory pressure, the VM system will
> shrink these caches.
> inode_init() registers a callback for the VM to call
> shrink_icache_memory () which will finally free the
> memory. Check out
> mm/vmscan.c and fs/inode.c for more detailed
> information.
> 
> - -Jeff
> 
> - --
> Jeff Mahoney
> SUSE Labs

Hello All,

Continuing the above discusssion I want to ask one
question. If a file system allocated new inodes using
new_inode() then after this uses d_add or
d_instantiate to attach this inode to a dentry, then
what will happen when we get short of memory.

In other words since new_inode() alolocates the memory
for the inode in the inode cache and since we are
getting short of memory so we can loose this inode but
we already have attached this inode with a dentry.
Then how the kernel will get the inode for this dentry
since we already have loose the inode for this dentry.

Similarly the file system allocates the memory for
dentries using d_alloc; is this can also create
problems like for the inodes.

Thanks,
Uzair Lakhani,
Karachi, Pakistan.
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with SUSE -
> http://enigmail.mozdev.org
> 
>
iD8DBQFEixcGLPWxlyuTD7IRAn1SAJ4yjgtJ9YL321W/18a7nttlaEc9pACeIMJX
> yNUuC/impK4eZpHpLkwtCOQ=
> =ykbS
> -----END PGP SIGNATURE-----
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: How long can an inode structure reside in the inode_cache?

[Neil Brown]

On Saturday June 10, uzairr_bs1b@yahoo.com wrote:
> 
> Hello All,
> 
> Continuing the above discusssion I want to ask one
> question. If a file system allocated new inodes using
> new_inode() then after this uses d_add or
> d_instantiate to attach this inode to a dentry, then
> what will happen when we get short of memory.

 Maybe you should spend a week reading the code?  It can be a lot of
fun, and you might even find a bug or two...

 Each dentry hold a reference on it's parent, and on it's inode.
Neither a dentry nor an inode can be freed when anyone holds a
reference on it.

 From this it is fairly easy to deduce that the first things to go
when there is memory pressure are the leaf dentries.  Once these are
gone, the inodes they referred to, and the parents of the dentries
will become available for being discarded.

NeilBrown


> 
> In other words since new_inode() alolocates the memory
> for the inode in the inode cache and since we are
> getting short of memory so we can loose this inode but
> we already have attached this inode with a dentry.
> Then how the kernel will get the inode for this dentry
> since we already have loose the inode for this dentry.
> 
> Similarly the file system allocates the memory for
> dentries using d_alloc; is this can also create
> problems like for the inodes.
> 
> Thanks,
> Uzair Lakhani,
> Karachi, Pakistan.

Re: How long can an inode structure reside in the inode_cache? - read the code

[Bryan Henderson]

>Maybe you should spend a week reading the code?  It can be a lot of
>fun, and you might even find a bug or two...

I'm not sure how serious this suggestion is, but it could be taken as as 
advice not to ask questions like this on the list, and I'd like to say 
that the questions are entirely appropriate.

It makes more sense to me to ask someone, via linux-fsdevel, who has 
already spent the week analyzing the code than to duplicate that effort.

Many people, including me, have difficulty extracting the big picture from 
Linux source code, and have very little fun trying.  Questions of object 
lifetimes and memory management are big-picture issues.  I can tell from 
reading lists such as linux-fsdevel that there are others who read Linux C 
code like they read a textbook.  (These are the folks who get irritated at 
excessive commenting and long variable names).  But for the rest of us, 
asking an expert shouldn't be discouraged.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

Re: How long can an inode structure reside in the inode_cache? - read the code

[Neil Brown]

On Monday June 12, hbryan@us.ibm.com wrote:
> >Maybe you should spend a week reading the code?  It can be a lot of
> >fun, and you might even find a bug or two...
> 
> I'm not sure how serious this suggestion is, but it could be taken as as 
> advice not to ask questions like this on the list, and I'd like to say 
> that the questions are entirely appropriate.

It was meant seriously, but lightly (if that makes sense), I answered
the question after all.

> 
> It makes more sense to me to ask someone, via linux-fsdevel, who has 
> already spent the week analyzing the code than to duplicate that effort.
> 

I'm happy to have questions asked, and am happy to answer them.  But I
like to see evidence that the person asking them is putting some
effort in themselves. 

In this case it was the third question in a fairly confined area.
Always fairly brief questions, with no evidence of background
research.
Now maybe that is due to language issues, or maybe they are just
someone who prefers to be terse or whatever and it certainly isn't
enough justification to be harsh, but I don't think I was harsh
(apologies if it seemed that way).


> Many people, including me, have difficulty extracting the big picture from 
> Linux source code, and have very little fun trying.  Questions of object 
> lifetimes and memory management are big-picture issues.  I can tell from 
> reading lists such as linux-fsdevel that there are others who read Linux C 
> code like they read a textbook.  (These are the folks who get irritated at 
> excessive commenting and long variable names).  But for the rest of us, 
> asking an expert shouldn't be discouraged.

Certainly, people should be free to ask questions. I tend to prefer
questions that demonstrate that the asker is doing some research
themselves. 
  "I found this piece of code but don't quite understand what it
    does?"
  "Where should I look for code that implements ...."
  "When is foo() called, and why?

NeilBrown

Re: How long can an inode structure reside in the inode_cache? - read the code

[Nate Diller]

On 6/12/06, Neil Brown <neilb@suse.de> wrote:
> On Monday June 12, hbryan@us.ibm.com wrote:
> > >Maybe you should spend a week reading the code?  It can be a lot of
> > >fun, and you might even find a bug or two...
> >
> > I'm not sure how serious this suggestion is, but it could be taken as as
> > advice not to ask questions like this on the list, and I'd like to say
> > that the questions are entirely appropriate.
>
> It was meant seriously, but lightly (if that makes sense), I answered
> the question after all.
>
> >
> > It makes more sense to me to ask someone, via linux-fsdevel, who has
> > already spent the week analyzing the code than to duplicate that effort.
> >
>
> I'm happy to have questions asked, and am happy to answer them.  But I
> like to see evidence that the person asking them is putting some
> effort in themselves.
>
> In this case it was the third question in a fairly confined area.
> Always fairly brief questions, with no evidence of background
> research.
> Now maybe that is due to language issues, or maybe they are just
> someone who prefers to be terse or whatever and it certainly isn't
> enough justification to be harsh, but I don't think I was harsh
> (apologies if it seemed that way).
>
>
> > Many people, including me, have difficulty extracting the big picture from
> > Linux source code, and have very little fun trying.  Questions of object
> > lifetimes and memory management are big-picture issues.  I can tell from
> > reading lists such as linux-fsdevel that there are others who read Linux C
> > code like they read a textbook.  (These are the folks who get irritated at
> > excessive commenting and long variable names).  But for the rest of us,
> > asking an expert shouldn't be discouraged.
>
> Certainly, people should be free to ask questions. I tend to prefer
> questions that demonstrate that the asker is doing some research
> themselves.
>   "I found this piece of code but don't quite understand what it
>     does?"
>   "Where should I look for code that implements ...."
>   "When is foo() called, and why?

The lack of big-picture comments (and accompanying LKML discussions),
is IMO the biggest problem with Linux.  Not only does this cause
problems for people such as Xin and Uzair trying to understand the
code, but it causes large performance problems to go
unnoticed/undiagnosed.  Of course, I'm one of the ones that never
asks, i just read the code as many times as I need to (thanks LXR),
but that's because I get paid for this, and I can afford the time.

Hopefully I will be able to submit some performance patches sometime
soon, and I assure you they will have big-picture comments.  Maybe the
comments will even be kept up-to-date by people when they modify the
design.

NATE

Re: How long can an inode structure reside in the inode_cache? - read the code

[Andrew Morton]

[catching up]

On Tue, 13 Jun 2006 16:25:13 -0700
"Nate Diller" <nate.diller@gmail.com> wrote:

> The lack of big-picture comments (and accompanying LKML discussions),
> is IMO the biggest problem with Linux.

yes, it's a barrier.

> 
> ..
>
> Hopefully I will be able to submit some performance patches sometime
> soon, and I assure you they will have big-picture comments.  Maybe the
> comments will even be kept up-to-date by people when they modify the
> design.

Feel free to send big-picture comments against the _existing_ code any
time.  They'll get well-reviewed.

That has nothing to do with any new performance work.