Disk IO issues
Stephen John Smoogen
smooge at gmail.com
Fri Jan 2 19:16:04 UTC 2009
On Fri, Jan 2, 2009 at 10:57 AM, Mike McGrath <mmcgrath at redhat.com> wrote:
> On Fri, 2 Jan 2009, Sascha Thomas Spreitzer wrote:
>
>> Hello again,
>>
>> this line looks suspicious to me:
>>
>> # name <active_objs> <num_objs> <objsize> <objperslab>
>> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> :
>> slabdata <active_slabs> <num_slabs> <sharedavail>
>> ext3_inode_cache 98472 150260 760 5 1 : tunables 54 27
>> 8 : slabdata 30052 30052 189
>>
>> Is it 1 big filesystem with about 1,342,177,280 inodes. Has this
>> amount ever be tested in the wild?
>
> Not sure if it has been tested in the wild or not but the filesystem
> itself contains a _TON_ of hardlinks. Creation of hardlinks is one of the
> big purposes of this filesystem.
>
Well then my idea of making smaller filesystems would break that
then... hmmm I would say that its time to escalate this to Level 2
support :). What do the filesystem kernel people think? I would bring
them in to see if there is something we are missing. Maybe something
in the dealing with that many inodes per file is causing a problem (or
maybe this is just known behaviour for large filesystems.) By the way,
this is a 64 bit OS correct?
--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"
More information about the infrastructure
mailing list