Messages in this thread | | | Date | Wed, 10 Feb 1999 22:49:01 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [patch] real fix [Re: [patch] fixed 2.2.1 inode-leakage due bogus design of the free_inodes algorithm |
| |
On Wed, 10 Feb 1999, Andrea Arcangeli wrote:
> On Wed, 10 Feb 1999, Steve Dodd wrote: > > >Hi, > > > >On Fri, Feb 05, 1999 at 12:46:43AM +0100, Andrea Arcangeli wrote: > > > >> free_inode_memory() is ok to not be recalled from try_to_free_pages() > >> because it can't generate more free memory but only more clean inode to > >> reuse in the filesystem so only the fs must call it when get_new_inode() > >> or something similar fails. > > > >Except in NTFS (I think), where clea{r,n}ing an inode frees up some memory > >allocated specifically by the file system. > > Again: free_inode_memory() don't generate free memory: it _only_ move > inodes from one list to another list. > > Could you show me the code you think is freeing memory?
D'oh. Code in question is in filesystems. Look: suppose you want to allocate a data associated with inode. You will do it from read_inode() and on inode creation, all right, but where will you free it? The *only* resonable place being ->clear_inode() method. And it's called by fs/inode.c::clear_inode(). Called by fs/inode.c::dispose_list(). Called by fs/inode.c::free_inodes(). Called by fs/inode.c::free_inode_memory(). See the path now? Again, it doesn't free inode memory per se. But for some inodes it informs filesystems that they should free their internal data associated with said inodes.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |