Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Aug 2013 23:08:24 +0100
From:      Frank Leonhardt <frank2@fjl.co.uk>
To:        freebsd-questions@freebsd.org
Subject:   Re: Terrible disk performance with LSI / FreeBSD 9.2-RC1
Message-ID:  <5202C558.3010305@fjl.co.uk>
In-Reply-To: <CABXB=RRvp0BLURq7M9iBb5anqaGsrvXeA1WmAroNji6bZP8p4w@mail.gmail.com>
References:  <CABXB=RSRnB41yjq5Qcbiz-JCRssNwx2AatJ2Dn+HhuD9GaBh+w@mail.gmail.com> <CAEhBLvg7ZUMja5zpFm2UQBXESW-0fL9L7EatR2aasstXd8ALHA@mail.gmail.com> <CABXB=RRvp0BLURq7M9iBb5anqaGsrvXeA1WmAroNji6bZP8p4w@mail.gmail.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 07/08/2013 21:36, J David wrote:
> It feels like some sort of issue with the
> bus/controller/kernel/driver/ZFS that is affecting all the drives
> equally.
>
> Also, even ls takes forever (10-30 seconds for "ls -lh /") but when it
> eventually does finish, "time ls -lh /" reports:
>
>          0.02 real         0.00 user         0.00 sys
>
> Really not sure what to make of that. An attempt to do "ps axlww |
> fgrep ls" while the ls was running failed, because the ps hangs just
> as long as the ls.  So it's like the system is just repeatedly putting
> anything that touches the disks on hold, even if all the data being
> requested is clearly in cache.  (Even apparently loading the binary
> for /bin/ls or doing "ls -lh /" twice in a row.)

As a suggestion, what happens if you read from the drives directly? Boot 
in single user and try reading a Gb or two using /bin/dd. It might 
eliminate or confirm a problem with ZFS.

Regards, Frank.








Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?5202C558.3010305>