Disk IO issues

[Mike McGrath]

On Fri, 2 Jan 2009, Stephen John Smoogen wrote:

> 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?
>

Correct, 64 bit OS.  I'm going to get some of our FS guys on the horn as
soon as RH is back to work.  I think most of them will return on Monday.

	-Mike