Hey, Boaz.
On Tue, Nov 18, 2014 at 02:10:50PM +0200, Boaz Harrosh wrote:
> Right? well if so than those special inodes do
> not hold any data and never do IO of any kind
> so all the inode members that are needed for IO
> are candidates.
It may not carry dirty pages but the inode itself still can get
dirtied tho.
> example: i_wb_list; i_lru; i_dio_count i_writecount
So, neither i_wb_list or i_lru can be used. It could be that some of
the atomic counters can be used but that requires collecting four such
counters consecutively.
> i_dquot (when QUOTA is on) i_private and more
If quota is off? i_private maybe but it's not big enough.
> Even union with the "cgroup writback support" you
> want to add.
Again, these inodes can get dirtied.
I think unions are okay when lifetime rules clearly separate how the
field is used or the usages are contained in a logical unit but
overloading random fields which may be used across lifetime in a data
structure which is as widely used and abused as inode is likely to
lead to later headaches.
This is really something special and local {block|char}_dev are doing
which doens't have to interfere with anything else. I think it's a
better approach to confine it to {block|char}_dev in the long term
even if that means carrying a bit more code.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
