[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130910210250.GH29237@thunk.org>
Date: Tue, 10 Sep 2013 17:02:50 -0400
From: Theodore Ts'o <tytso@....edu>
To: Andreas Dilger <adilger@...ger.ca>
Cc: Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke@...com>,
T Makphaibulchoke <tmac@...com>,
Al Viro <viro@...iv.linux.org.uk>,
"linux-ext4@...r.kernel.org List" <linux-ext4@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org Devel" <linux-fsdevel@...r.kernel.org>,
aswin@...com, Linus Torvalds <torvalds@...ux-foundation.org>,
aswin_proj@...ts.hp.com
Subject: Re: [PATCH v3 0/2] ext4: increase mbcache scalability
On Tue, Sep 10, 2013 at 02:47:33PM -0600, Andreas Dilger wrote:
> I agree that SELinux is enabled on enterprise distributions by default,
> but I'm also interested to know how much overhead this imposes. I would
> expect that writing large external xattrs for each file would have quite
> a significant performance overhead that should not be ignored. Reducing
> the mbcache overhead is good, but eliminating it entirely is better.
I was under the impression that using a 256 byte inode (which gives a
bit over 100 bytes worth of xattr space) was plenty for SELinux. If
it turns out that SELinux's use of xattrs have gotten especially
piggy, then we may need to revisit the recommended inode size for
those systems who insist on using SELinux... even if we eliminate the
overhead associated with mbcache, the fact that files are requiring a
separate xattr is going to seriously degrade performance.
- Ted
--
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/
Powered by blists - more mailing lists