From: "J . Bruce Fields" <bfields@fieldses.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
Miklos Szeredi <miklos@szeredi.hu>,
Jeff Layton <jlayton@poochiereds.net>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
overlayfs <linux-unionfs@vger.kernel.org>,
linux-integrity <linux-integrity@vger.kernel.org>
Subject: Re: [PATCH 1/2] vfs: replace i_readcount with a biased i_count
Date: Wed, 12 Jun 2019 11:29:27 -0400 [thread overview]
Message-ID: <20190612152927.GE16331@fieldses.org> (raw)
In-Reply-To: <CAOQ4uxhooVwtHcDCr4hu+ovzKGUdWfQ+3F3nbgK3HXgV+fUK9w@mail.gmail.com>
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.
next prev parent reply other threads:[~2019-06-12 15:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-08 13:57 [PATCH 0/2] Fix write leases on overlayfs Amir Goldstein
2019-06-08 13:57 ` [PATCH 1/2] vfs: replace i_readcount with a biased i_count Amir Goldstein
2019-06-09 19:36 ` Miklos Szeredi
[not found] ` <20190610151836.5E2A3207E0@mail.kernel.org>
2019-06-10 16:37 ` Amir Goldstein
2019-06-12 12:51 ` Mimi Zohar
2019-06-12 15:09 ` Amir Goldstein
2019-06-12 15:29 ` J . Bruce Fields [this message]
2019-06-12 15:35 ` Amir Goldstein
2019-06-12 15:59 ` Mimi Zohar
2019-06-08 13:57 ` [PATCH 2/2] locks: eliminate false positive conflicts for write lease Amir Goldstein
[not found] ` <20190610151835.2FFC12089E@mail.kernel.org>
2019-06-10 16:38 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190612152927.GE16331@fieldses.org \
--to=bfields@fieldses.org \
--cc=amir73il@gmail.com \
--cc=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=viro@zeniv.linux.org.uk \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.