xfs
[Top] [All Lists]

Re: inode64 workaround

To: chatz@xxxxxxxxxxxxxxxxx
Subject: Re: inode64 workaround
From: Deanan <delusion@xxxxxxxxxxxx>
Date: Wed, 29 Nov 2006 16:59:58 -0800
Cc: xfs@xxxxxxxxxxx
In-reply-to: <456E2A30.4010101@melbourne.sgi.com>
References: <200611290027.AA04740@TNESG9305.tnes.nec.co.jp> <1164838985.4992.30.camel@edge> <456E1B08.7090802@delusion.com> <456E2A30.4010101@melbourne.sgi.com>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird 1.5.0.8 (Windows/20061025)
Hi David,

I'm not sure if it will help but I'd like to try.
Where do you set the rotor?
 BTW< tis particular box is 2.6.9.

Thanks,

Deanan


> Deanan,
>
> Would something like the inode rotor help?
>
>   fs.xfs.rotorstep              (Min: 1  Default: 1  Max: 256)
>
>         In "inode32" allocation mode, this option determines how many
>
>         files the allocator attempts to allocate in the same allocation
>
>         group before moving to the next allocation group.  The intent
>
>         is to control the rate at which the allocator moves between
>
>         allocation groups when allocating extents for new files.
>
> David
>
>
> Deanan wrote:
>   
>> Hi,
>>
>> I've got some systems that I can't change the kernel on (external
>> vendor) that
>> are 32bit but I'm running into the performance problem that is fixed by
>> using
>> inode64. Is there any known way of working around the problem on a 32bit
>> kernel?
>>
>> In our case, the problem occurs as soon as you start to delete files and
>> write new ones.
>>
>> Cheers,
>>
>> Deanan
>>
>>     
>
>   



[[HTML alternate version deleted]]


<Prev in Thread] Current Thread [Next in Thread>