linux-kernel - Re: [RFC PATCH 0/2] A new way of attaching information to inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 May 2009 05:08:59 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Theodore Tso <tytso@....edu>, Jan Kara <jack@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/