Anton Titov <a.titov@xxxxxxx> wrote: > > On Fri, 2006-01-20 at 19:17 -0600, James Bottomley wrote: > > On Fri, 2006-01-20 at 16:50 -0800, Andrew Morton wrote: > > > For linux-scsi reference, Chase's /proc/slabinfo says: > > > > > > scsi_cmd_cache 1547440 1547440 384 10 1 : tunables 54 27 8 : > > > slabdata 154744 154744 0 > > > > There's another curiosity about this: the linux command stack is pretty > > well counted per scsi device (it's how we control queue depth), so if a > > driver leaks commands we see it not by this type of behaviour, but by > > the system hanging (waiting for all the commands the mid-layer thinks > > are outstanding to return). So, the only way we could leak commands > > like this is in the mid-layer command return logic ... and I can't find > > anywhere this might happen. > > > > Just to mention, that 2.6.14.2 does not have this problem: > > vip ~ # cat /proc/slabinfo | grep scsi > scsi_cmd_cache 60 60 384 10 1 : tunables 54 27 > 8 : slabdata 6 6 27 > > but my guess is that the problem may be not in SCSI, as not /and > previosly actually/ I have this: > > vip ~ # cat /proc/slabinfo | grep reiser > reiser_inode_cache 556594 556614 408 9 1 : tunables 54 27 > 8 : slabdata 61846 61846 0 > > which seems too high too Having large numbers of cached inodes is fairly common. Try running something which uses lots of memory: memset(malloc(gigabytes)), or usemem from http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz or read a multi-gigabyte file from disk and you shuld see the inode count wind down. - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
