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
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
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
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.
>>
>>
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
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 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/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 and
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, so in other
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 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
SELinux
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 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 not he's
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
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
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
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
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
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 mb_cache
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 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 xattrs
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
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 for perf
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 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.
So
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 the
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 checked
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
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
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
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
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
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 for
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 the
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's
40 matches
Mail list logo
