On 9/11/13 3:36 PM, Thavatchai Makphaibulchoke wrote:
> I seem to be seeing the same thing as Eric is seeing.
...
> For both filesystems, the security xattr are about 32.17 and 34.87 bytes
> respectively.
...
Can you triple-check the inode size on your fs, for good measure?
dumpe2fs -h /dev/wh
On 09/11/2013 09:25 PM, Theodore Ts'o wrote:
> On Wed, Sep 11, 2013 at 03:48:57PM -0500, Eric Sandeen wrote:
>>
>> So at this point I think it's up to Mak to figure out why on his system,
>> aim7 is triggering mbcache codepaths.
>>
>
> Yes, the next thing is to see if on his systems, whether or n
On Wed, Sep 11, 2013 at 03:48:57PM -0500, Eric Sandeen wrote:
>
> So at this point I think it's up to Mak to figure out why on his system, aim7
> is triggering mbcache codepaths.
>
Yes, the next thing is to see if on his systems, whether or not he's
seeing external xattr blocks.
On 9/11/13 3:32 PM, David Lang wrote:
> On Wed, 11 Sep 2013, Eric Sandeen wrote:
>
>>> The reason why I'm pushing here is that mbcache shouldn't be showing
>>> up in the profiles at all if there is no external xattr block. And so
>>> if newer versions of SELinux (like Adnreas, I've been burned by
On Wed, 11 Sep 2013, Eric Sandeen wrote:
The reason why I'm pushing here is that mbcache shouldn't be showing
up in the profiles at all if there is no external xattr block. And so
if newer versions of SELinux (like Adnreas, I've been burned by
SELinux too many times in the past, so I don't use
On 9/11/13 11:49 AM, Eric Sandeen wrote:
> On 9/11/13 6:30 AM, Theodore Ts'o wrote:
>> On Tue, Sep 10, 2013 at 10:13:16PM -0500, Eric Sandeen wrote:
>>>
>>> Above doesn't tell us the prevalence of various contexts on the actual
>>> system,
>>> but they are all under 100 bytes in any case.
>>
>> OK
On 9/11/13 6:30 AM, Theodore Ts'o wrote:
> On Tue, Sep 10, 2013 at 10:13:16PM -0500, Eric Sandeen wrote:
>>
>> Above doesn't tell us the prevalence of various contexts on the actual
>> system,
>> but they are all under 100 bytes in any case.
>
> OK, so in other words, on your system i_file_acl an
On Tue, Sep 10, 2013 at 10:13:16PM -0500, Eric Sandeen wrote:
>
> Above doesn't tell us the prevalence of various contexts on the actual system,
> but they are all under 100 bytes in any case.
OK, so in other words, on your system i_file_acl and i_file_acl_high
(which is where we store the block
On 9/10/13 4:02 PM, Theodore Ts'o wrote:
> 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 xat
On 09/10/2013 09:02 PM, Theodore Ts'o wrote:
> 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
On 2013-09-06, at 6:23 AM, Thavatchai Makphaibulchoke wrote:
> On 09/06/2013 05:10 AM, Andreas Dilger wrote:
>> On 2013-09-05, at 3:49 AM, Thavatchai Makphaibulchoke wrote:
>>> No, I did not do anything special, including changing an inode's size. I
>>> just used the profile data, which indicated
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 signifi
On 09/06/2013 05:10 AM, Andreas Dilger wrote:
> On 2013-09-05, at 3:49 AM, Thavatchai Makphaibulchoke wrote:
>> No, I did not do anything special, including changing an inode's size. I
>> just used the profile data, which indicated mb_cache module as one of the
>> bottleneck. Please see below fo
On 2013-09-05, at 3:49 AM, Thavatchai Makphaibulchoke wrote:
> On 09/05/2013 02:35 AM, Theodore Ts'o wrote:
>> How did you gather these results? The mbcache is only used if you
>> are using extended attributes, and only if the extended attributes don't fit
>> in the inode's extra space.
>>
>> I
On 09/04/2013 08:00 PM, Andreas Dilger wrote:
>
> In the past, I've raised the question of whether mbcache is even
> useful on real-world systems. Essentially, this is providing a
> "deduplication" service for ext2/3/4 xattr blocks that are identical.
> The question is how often this is actually
On 09/05/2013 02:35 AM, Theodore Ts'o wrote:
> How did you gather these results? The mbcache is only used if you are
> using extended attributes, and only if the extended attributes don't
> fit in the inode's extra space.
>
> I checked aim7, and it doesn't do any extended attribute operations.
>
On Wed, Sep 04, 2013 at 10:39:14AM -0600, T Makphaibulchoke wrote:
>
> Here are the performance improvements in some of the aim7 workloads,
How did you gather these results? The mbcache is only used if you are
using extended attributes, and only if the extended attributes don't
fit in the inode'
On 09/04/2013 08:00 PM, Andreas Dilger wrote:
>
> In the past, I've raised the question of whether mbcache is even
> useful on real-world systems. Essentially, this is providing a
> "deduplication" service for ext2/3/4 xattr blocks that are identical.
> The question is how often this is actually
On 2013-09-04, at 10:39 AM, T Makphaibulchoke wrote:
> This patch intends to improve the scalability of an ext filesystem,
> particularly ext4.
In the past, I've raised the question of whether mbcache is even
useful on real-world systems. Essentially, this is providing a
"deduplication" service f
This patch intends to improve the scalability of an ext filesystem,
particularly ext4.
The patch consists of two parts. The first part introduces higher degree of
parallelism to the usages of the mb_cache and mb_cache_entries and impacts
all ext filesystems.
The second part of the patch further
20 matches
Mail list logo
