> > I found a clue! The problem occurs with my big data partitions,
> > which are newfs-ed with options intended to improve things.
> >
> > Reading a large file from the normal ad4s5b partition only delays other
> > commands slightly, as expected. Reading a large file from the tuned
> > ad4s11 pa
On Oct 6, 2009, at 10:57 AM, O. Hartmann wrote:
Thomas Backman wrote:
On Oct 5, 2009, at 6:05 PM, Dieter wrote:
In message ,
Thomas Backman writes:
I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an
old
80GB 7200rpm disk.
My problem is that I get completely unacceptable la
On Mon, 5 Oct 2009, Dieter wrote:
I found a clue! The problem occurs with my big data partitions,
which are newfs-ed with options intended to improve things.
Reading a large file from the normal ad4s5b partition only delays other
commands slightly, as expected. Reading a large file from the t
Thomas Backman wrote:
On Oct 5, 2009, at 6:05 PM, Dieter wrote:
In message , Thomas
Backman writes:
I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old
80GB 7200rpm disk.
My problem is that I get completely unacceptable latency on console IO
(both via SSH and serial console
On Oct 5, 2009, at 6:05 PM, Dieter wrote:
In message ,
Thomas Backman writes:
I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old
80GB 7200rpm disk.
My problem is that I get completely unacceptable latency on console
IO
(both via SSH and serial console) when the system i
I found a clue! The problem occurs with my big data partitions,
which are newfs-ed with options intended to improve things.
Reading a large file from the normal ad4s5b partition only delays other
commands slightly, as expected. Reading a large file from the tuned
ad4s11 partition yields the dela
In message , Thomas Backman
writes:
> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old
> 80GB 7200rpm disk.
>
> My problem is that I get completely unacceptable latency on console IO
> (both via SSH and serial console) when the system is performing disk
> IO. The worst
(Note: I hope this reply shows up correctly. I subscribed to the
mailing list after the fact and had to "forge" the subject line.)
Hey everyone,
I'm having serious trouble with the same thing, and just found this
thread while looking for the correct place to post. Looks like I found
it. (I
>From: Dieter
>Subject: Re: A specific example of a disk i/o problem
>To: freebsd-performance@freebsd.org
>Date: Friday, October 2, 2009, 1:07 AM
>
>Updated demo, just to make sure:
>
># big_file is larger than main memory, on same disk as man (/usr)
>time man de
>From: Dieter
>Subject: Re: A specific example of a disk i/o problem
>To: freebsd-performance@freebsd.org
>Date: Friday, October 2, 2009, 1:07 AM
>
>Updated demo, just to make sure:
>
># big_file is larger than main memory, on same disk as man (/usr)
>time man de
> > > >> > My question is why is FreeBSD's disk i/o performance so bad?
> >
> > > > Here is a specific demo of one disk i/o problem I'm seeing. Should be
> > > > easy to reproduce?
> > > >
> > > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html
>
> FYI, I thought I'd
In response to Dieter :
> > >> > My question is why is FreeBSD's disk i/o performance so bad?
>
> > > Here is a specific demo of one disk i/o problem I'm seeing. Should be
> > > easy to reproduce?
> > >
> > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html
FYI, I th
> >> > My question is why is FreeBSD's disk i/o performance so bad?
> > Here is a specific demo of one disk i/o problem I'm seeing. Should be
> > easy to reproduce?
> >
> > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html
> >
> > This was over a year ago, so add 7.1 to
2009/9/30 Dieter :
>> > My question is why is FreeBSD's disk i/o performance so bad?
>>
>> As I mentioned... this was discussed actively in slashdot. You will find
>> there many good comments on this.
>
> All I saw in slashdot was a ffs vs ext comment. I don't believe the problems
> I'm seeing ar
14 matches
Mail list logo