lkml.org 
[lkml]   [2009]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 0/2] A new way of attaching information to inodes
On Thu, Apr 30, 2009 at 03:43:39PM -0400, Theodore Tso wrote:
> One of the things on my "round tuit" list was separating out those
> inode fields which are only needed when the inode is in use, and
> separating them out into a separate data structure, so that the 90+%
> of the inodes which are just being cached, and are not active, don't
> burn space in struct inode. In particular, we can probably move out
> i_mutex, i_alloc_sem, i_size_seqcount, i_flock, and perhaps others.

I think that's generally a good idea, but I don't think we should
use this mechanism for it. Just split the inode into two structures,
as struct cached_inode and a struct active_inode and make the struct
inode an anonymous union of the two.

> The same applies for the filesystem-specific portion of the in-core
> inode; and for some filesystems there might be even more opportunity
> for savings there.

I'd rather move them out into the filesystem. E.g. i_alloc_sem is
specific to those few filesystem that support O_DIRECT but don't
actually do good enough internal locking - we'd be much better
off just having the i_alloc_sem equivalent inside those filesystems
and get rid of the calls to it in the VFS which only hurt the others.

Similarly I'd really love to get rid of the quota calls in the VFS but
instead move calls to these helpers into the filesystems - it's not
a function of the VFS switch and that way we can easily keep the quota
inode in the FS without a feature table.



\
 
 \ /
  Last update: 2009-05-01 11:13    [W:2.386 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site