> 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.
>
> I notice Alexander Viro wrote also:
>
> > [2] BTW, life would be *much* easier if we'ld keep fs-specific parts of
> > inode and super allocated separately. I did it for ext2 and it seems to
> > work fine. If it would be done for all filesystems the memory usage would
> > decrease for almost everybody.
>
> So it might be the same also for ext2.
Erm... In my tree - yes. But not in the mainstream kernel. Wait till 2.3.
What I'm doing is:
* allocate ext2-specific part in ext2_read_inode() and in
ext2_new_inode() (very beginning).
* free the ext2-specific part in ext2_clear_inode() (and before
calling bad_inode() from the ext2_read_inode() if something fails).
There is a nasty gotcha in mainstream variant - pipe_inode_info is member
of the same union as everything else. It means that you can't use
->u.generic_ip for filesystems that support named pipes. Fix was simple -
take the sucker away from union, allocate it dynamically and keep the
pointer to it in struct inode (*outside* of union, indeed). Killed several
related kludges in other filesystems - ext2-specific part of inode has a
large piece in the beginning unused in case of named pipes, but NFS has to
add fake struct pipe_inode_info to nfs_inode_info, ditto for UMSDOS, etc.
IIRC I've posted that patch to l-k sometime ago (FIFO-related one, that
is).
Aside of that everything was pretty simple. From the VFS point of
view memory is freed from clean_inode() (inode.c). The same can be done
with other filesystems - ufs and nfs being the most obvious candidates.
-
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/