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%2BHhuD9GaBh%2Bw@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: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5202C558.3010305>