From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fieldses.org ([173.255.197.46]:51294 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405706AbfFLP31 (ORCPT ); Wed, 12 Jun 2019 11:29:27 -0400 Date: Wed, 12 Jun 2019 11:29:27 -0400 From: "J . Bruce Fields" Subject: Re: [PATCH 1/2] vfs: replace i_readcount with a biased i_count Message-ID: <20190612152927.GE16331@fieldses.org> References: <20190608135717.8472-1-amir73il@gmail.com> <20190608135717.8472-2-amir73il@gmail.com> <1560343899.4578.9.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-unionfs-owner@vger.kernel.org To: Amir Goldstein Cc: Mimi Zohar , Miklos Szeredi , Jeff Layton , Al Viro , linux-fsdevel , overlayfs , linux-integrity List-ID: On Wed, Jun 12, 2019 at 06:09:59PM +0300, Amir Goldstein wrote: > But if I am following Miklos' suggestion to make i_count 64bit, inode > struct size is going to grow for 32bit arch when CONFIG_IMA is not > defined, so to reduce impact, I will keep i_readcount as a separate > member and let it be defined also when BITS_PER_LONG == 64 > and implement inode_is_open_rdonly() using d_count and i_count > when i_readcount is not defined. How bad would it be just to let the inode be a little bigger? How big is it already on 32 bit architectures? How much does this change e.g. how many inodes you can cache per megabyte? --b.