OpenBSD and disk slowliness

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenBSD and disk slowliness

Jorge Gabriel Lopez Paramount
Hi all,

A few months ago I tried to install OpenBSD 5.5 in a KVM virtual  
machine running Linux in an amd64 computer. First tried to install the  
i386 version since my Linux virtual machines are i686 and was  
painfully slow, so much that I almost decided to not use OpenBSD. Then  
I tried with the amd64 version and ran blazingly fast, was so  
impressed that I'm here.

Time passed and installed some i386 virtual machines running in atom  
chips without issues and so far have been running fine so I forgot the  
issue, but last week started to upgrade them to 5.6 and was again  
painfully slow, one hour to upgrade each one. And since the slow part  
of upgrading was at untarring and the LED of the disk was blinking  
like crazy I supposed it was some issue with the virtual hard disk.

Now that I know more about OpenBSD tried again to install the same 5.5  
version in the same amd64 computer, but this time using the virtio  
drivers, and in less than 5 minutes installed a new OpenBSD server  
with no issues at all. As reference this is the kvm command I used:

kvm -vnc :15 -m 256 -name openbsd -pidfile /qemu/OpenBSD/OpenBSD.pid  
-k es -net nic,macaddr=52:54:00:12:34:84,model=virtio -net  
tap,ifname=tap17 -drive  
file=/dev/eliseos/qemu-004,cache=none,if=virtio -cdrom  
/software/OpenBSD/5.5/i386/install55.iso -boot d -daemonize

I would like to share this because I have read in many places about  
hard disk slowliness with OpenBSD, verly likely dissapointing new  
users when in fact OpenBSD is very good.

--
Best regards,
Jorge Lopez.





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Mikolaj Kucharski-3
Hi,

This problem looks very similar as:

        https://marc.info/?l=openbsd-misc&m=140288534929223&w=2

On my i386 KVM after each upgrade I run this:

#!/bin/sh

for kernel in /bsd /bsd.mp
do
        config -fe $kernel << EOF
find mpbios
disable mpbios
find mpbios
find acpimadt
disable acpimadt
find acpimadt
quit
EOF
done


Please CC me in any replies, I'm not receiving mails from `misc`


On Thu, Jan 08, 2015 at 05:21:48PM -0600, Jorge Gabriel Lopez Paramount wrote:

> Hi all,
>
> A few months ago I tried to install OpenBSD 5.5 in a KVM virtual machine
> running Linux in an amd64 computer. First tried to install the i386 version
> since my Linux virtual machines are i686 and was painfully slow, so much
> that I almost decided to not use OpenBSD. Then I tried with the amd64
> version and ran blazingly fast, was so impressed that I'm here.
>
> Time passed and installed some i386 virtual machines running in atom chips
> without issues and so far have been running fine so I forgot the issue, but
> last week started to upgrade them to 5.6 and was again painfully slow, one
> hour to upgrade each one. And since the slow part of upgrading was at
> untarring and the LED of the disk was blinking like crazy I supposed it was
> some issue with the virtual hard disk.
>
> Now that I know more about OpenBSD tried again to install the same 5.5
> version in the same amd64 computer, but this time using the virtio drivers,
> and in less than 5 minutes installed a new OpenBSD server with no issues at
> all. As reference this is the kvm command I used:
>
> kvm -vnc :15 -m 256 -name openbsd -pidfile /qemu/OpenBSD/OpenBSD.pid -k es
> -net nic,macaddr=52:54:00:12:34:84,model=virtio -net tap,ifname=tap17 -drive
> file=/dev/eliseos/qemu-004,cache=none,if=virtio -cdrom
> /software/OpenBSD/5.5/i386/install55.iso -boot d -daemonize
>
> I would like to share this because I have read in many places about hard
> disk slowliness with OpenBSD, verly likely dissapointing new users when in
> fact OpenBSD is very good.
>

--
best regards
q#

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Martin Pieuchot-2
Dear Mikolaj,

On 09/01/15(Fri) 00:30, Mikolaj Kucharski wrote:

> Hi,
>
> This problem looks very similar as:
>
> https://marc.info/?l=openbsd-misc&m=140288534929223&w=2
>
> On my i386 KVM after each upgrade I run this:
>
> #!/bin/sh
>
> for kernel in /bsd /bsd.mp
> do
>         config -fe $kernel << EOF
> find mpbios
> disable mpbios
> find mpbios
> find acpimadt
> disable acpimadt
> find acpimadt
> quit
> EOF
> done
>
>
> Please CC me in any replies, I'm not receiving mails from `misc`

Your email makes me really sad.

It makes me really sad because I want to believe that you sent it in
order to help somebody.  However you're doing the contrary and you are
doing it publicly.  That means other people will later find your email
and, believing that you are trying to help, do what you recommend.

Please do not recommend to *disable* anything in a kernel.

Disabling something that you don't understand might be good enough for
you.  But it does not help me, or I believe anyone else, to fix the
damn problem people are having.

Instead of giving such advices, I'd suggest you to read sendbug(1) and
fill a bug report as complete as possible such that competent people
might have a chance to help you fix your problem.  If you do that you
might be able to run a GENERIC kernel without disabling anything.  You
might also prevent other people to send other bug reports for the same
problem.

Think about it, the system you're running is good because *a lot* of
other people did not deactivate anything but instead sent good or not
so good bug reports.

Sadly you've just answered to yet another bug report without information,
giving a bad advice and nobody can improve OpenBSD.

I hope I didn't sound to harsh and I hope to see a nice bug report from
you in bugs@ soon.

Best regards,
Martin

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Theo de Raadt
In reply to this post by Jorge Gabriel Lopez Paramount
> This problem looks very similar as:
>
> https://marc.info/?l=openbsd-misc&m=140288534929223&w=2
>
> On my i386 KVM after each upgrade I run this:
>
> #!/bin/sh
>
> for kernel in /bsd /bsd.mp
> do
>         config -fe $kernel << EOF
> find mpbios
> disable mpbios
> find mpbios
> find acpimadt
> disable acpimadt
> find acpimadt
> quit
> EOF
> done
>
>
> Please CC me in any replies, I'm not receiving mails from `misc`

Mikolaj,

This kind of mail wants me want to push for removal of the config -e
support.

It is incredibly bad advice.

Yes, there are bugs in the interrupt handling code, every operating
system on PCs has this because it is very difficult code to debug.
And machines are slowly changing in behaviour.  But advising users to
all run different code paths leads to a fragmented userbase running
different kernel code paths, which lead them to all submit different
misleading bug reports and as a result, more pressure on fewer
developers.  Who might eventually stop caring as much.

If as a general rule we all want better code running on our systems,
where do you fit in?

Let me be blunt.  Your advice is bad.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Mikolaj Kucharski-3
In reply to this post by Jorge Gabriel Lopez Paramount
Martin, Theo,

I would like to apologize you and other developers for spreading unhelpful
advises which hurt the project.

I truly regret that and I am very sorry.

Regards,
 Mikolaj

On Fri, Jan 09, 2015 at 02:34:36AM +0100, Martin Pieuchot wrote:

> Dear Mikolaj,
>
> On 09/01/15(Fri) 00:30, Mikolaj Kucharski wrote:
> > Hi,
> >
> > This problem looks very similar as:
> >
> > https://marc.info/?l=openbsd-misc&m=140288534929223&w=2
> >
> > On my i386 KVM after each upgrade I run this:
> >
> > #!/bin/sh
> >
> > for kernel in /bsd /bsd.mp
> > do
> >         config -fe $kernel << EOF
> > find mpbios
> > disable mpbios
> > find mpbios
> > find acpimadt
> > disable acpimadt
> > find acpimadt
> > quit
> > EOF
> > done
> >
> >
> > Please CC me in any replies, I'm not receiving mails from `misc`
>
> Your email makes me really sad.
>
> It makes me really sad because I want to believe that you sent it in
> order to help somebody.  However you're doing the contrary and you are
> doing it publicly.  That means other people will later find your email
> and, believing that you are trying to help, do what you recommend.
>
> Please do not recommend to *disable* anything in a kernel.
>
> Disabling something that you don't understand might be good enough for
> you.  But it does not help me, or I believe anyone else, to fix the
> damn problem people are having.
>
> Instead of giving such advices, I'd suggest you to read sendbug(1) and
> fill a bug report as complete as possible such that competent people
> might have a chance to help you fix your problem.  If you do that you
> might be able to run a GENERIC kernel without disabling anything.  You
> might also prevent other people to send other bug reports for the same
> problem.
>
> Think about it, the system you're running is good because *a lot* of
> other people did not deactivate anything but instead sent good or not
> so good bug reports.
>
> Sadly you've just answered to yet another bug report without information,
> giving a bad advice and nobody can improve OpenBSD.
>
> I hope I didn't sound to harsh and I hope to see a nice bug report from
> you in bugs@ soon.
>
> Best regards,
> Martin


On Thu, Jan 08, 2015 at 06:56:46PM -0700, Theo de Raadt wrote:

> > This problem looks very similar as:
> >
> > https://marc.info/?l=openbsd-misc&m=140288534929223&w=2
> >
> > On my i386 KVM after each upgrade I run this:
> >
> > #!/bin/sh
> >
> > for kernel in /bsd /bsd.mp
> > do
> >         config -fe $kernel << EOF
> > find mpbios
> > disable mpbios
> > find mpbios
> > find acpimadt
> > disable acpimadt
> > find acpimadt
> > quit
> > EOF
> > done
> >
> >
> > Please CC me in any replies, I'm not receiving mails from `misc`
>
> Mikolaj,
>
> This kind of mail wants me want to push for removal of the config -e
> support.
>
> It is incredibly bad advice.
>
> Yes, there are bugs in the interrupt handling code, every operating
> system on PCs has this because it is very difficult code to debug.
> And machines are slowly changing in behaviour.  But advising users to
> all run different code paths leads to a fragmented userbase running
> different kernel code paths, which lead them to all submit different
> misleading bug reports and as a result, more pressure on fewer
> developers.  Who might eventually stop caring as much.
>
> If as a general rule we all want better code running on our systems,
> where do you fit in?
>
> Let me be blunt.  Your advice is bad.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Kent Fritz
In reply to this post by Jorge Gabriel Lopez Paramount
Hopefully this is not too bad advice...

I've found the performance with cache=none to be unacceptable as well.
I'm using cache=writeback.  Of course you'll get much better
performance if you remove Linux/KVM.  :)

On Thu, Jan 8, 2015 at 3:21 PM, Jorge Gabriel Lopez Paramount
<[hidden email]> wrote:

> Hi all,
>
> A few months ago I tried to install OpenBSD 5.5 in a KVM virtual machine
> running Linux in an amd64 computer. First tried to install the i386 version
> since my Linux virtual machines are i686 and was painfully slow, so much
> that I almost decided to not use OpenBSD. Then I tried with the amd64
> version and ran blazingly fast, was so impressed that I'm here.
>
> Time passed and installed some i386 virtual machines running in atom chips
> without issues and so far have been running fine so I forgot the issue, but
> last week started to upgrade them to 5.6 and was again painfully slow, one
> hour to upgrade each one. And since the slow part of upgrading was at
> untarring and the LED of the disk was blinking like crazy I supposed it was
> some issue with the virtual hard disk.
>
> Now that I know more about OpenBSD tried again to install the same 5.5
> version in the same amd64 computer, but this time using the virtio drivers,
> and in less than 5 minutes installed a new OpenBSD server with no issues at
> all. As reference this is the kvm command I used:
>
> kvm -vnc :15 -m 256 -name openbsd -pidfile /qemu/OpenBSD/OpenBSD.pid -k es
> -net nic,macaddr=52:54:00:12:34:84,model=virtio -net tap,ifname=tap17 -drive
> file=/dev/eliseos/qemu-004,cache=none,if=virtio -cdrom
> /software/OpenBSD/5.5/i386/install55.iso -boot d -daemonize
>
> I would like to share this because I have read in many places about hard
> disk slowliness with OpenBSD, verly likely dissapointing new users when in
> fact OpenBSD is very good.
>
> --
> Best regards,
> Jorge Lopez.
>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

RichardET
I am using OpenBSD 5.6 in a VMware 64 bit VM as guest, Ubuntu 14.10 as
host, and performance seems quite acceptable.  How do you know that there
are any bugs or issues which need to be addressed?


On Fri, 9 Jan 2015, Kent Fritz wrote:

> Hopefully this is not too bad advice...
>
> I've found the performance with cache=none to be unacceptable as well.
> I'm using cache=writeback.  Of course you'll get much better
> performance if you remove Linux/KVM.  :)
>
> On Thu, Jan 8, 2015 at 3:21 PM, Jorge Gabriel Lopez Paramount
> <[hidden email]> wrote:
> > Hi all,
> >
> > A few months ago I tried to install OpenBSD 5.5 in a KVM virtual machine
> > running Linux in an amd64 computer. First tried to install the i386 version
> > since my Linux virtual machines are i686 and was painfully slow, so much
> > that I almost decided to not use OpenBSD. Then I tried with the amd64
> > version and ran blazingly fast, was so impressed that I'm here.
> >
> > Time passed and installed some i386 virtual machines running in atom chips
> > without issues and so far have been running fine so I forgot the issue, but
> > last week started to upgrade them to 5.6 and was again painfully slow, one
> > hour to upgrade each one. And since the slow part of upgrading was at
> > untarring and the LED of the disk was blinking like crazy I supposed it was
> > some issue with the virtual hard disk.
> >
> > Now that I know more about OpenBSD tried again to install the same 5.5
> > version in the same amd64 computer, but this time using the virtio drivers,
> > and in less than 5 minutes installed a new OpenBSD server with no issues at
> > all. As reference this is the kvm command I used:
> >
> > kvm -vnc :15 -m 256 -name openbsd -pidfile /qemu/OpenBSD/OpenBSD.pid -k es
> > -net nic,macaddr=52:54:00:12:34:84,model=virtio -net tap,ifname=tap17 -drive
> > file=/dev/eliseos/qemu-004,cache=none,if=virtio -cdrom
> > /software/OpenBSD/5.5/i386/install55.iso -boot d -daemonize
> >
> > I would like to share this because I have read in many places about hard
> > disk slowliness with OpenBSD, verly likely dissapointing new users when in
> > fact OpenBSD is very good.
> >
> > --
> > Best regards,
> > Jorge Lopez.
> >
> >
> >
> >
> >
> > ----------------------------------------------------------------
> > This message was sent using IMP, the Internet Messaging Program.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Mark Kettenis
In reply to this post by Jorge Gabriel Lopez Paramount
The way OpenBSD/i386 uses the xAPIC interrupt controller gives KVM
(and other virtualization software) a hard time.  OpenBSD/amd64 does
things in a KVM-friendlier way, and we're trying to make it even
friendlier.  Fixing the interrupt handling on OpenBSD/i386 isn't very
high on my priority list.  I really recommend that people use
OpenBSD/amd64 .  You'll get much better address space randomization
and NX bit support that way.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Jorge Gabriel Lopez Paramount
Hi all,

Just for the record, I do not think that OpenBSD/i386 behavior with  
virtual disks running on KVM is a bug. Virtio was designed specially  
for virtual machines and all modern Linux distros and other modern  
operating systems support it, therefore the only good reason for not  
using virtio is having a legacy OS that does not support it.

Since the default in QEMU/KVM is NOT virtio and there are people  
getting hit with this like myself I considered a good idea to share  
this, but I do not consider this a bug, maybe a nice-to-have. OpenBSD  
runs fine with virtio and virtio is the fastest interface for any OS,  
better to use it than not.

--
Best regards,
Jorge Lopez.


Quoting Mark Kettenis <[hidden email]>:

> The way OpenBSD/i386 uses the xAPIC interrupt controller gives KVM
> (and other virtualization software) a hard time.  OpenBSD/amd64 does
> things in a KVM-friendlier way, and we're trying to make it even
> friendlier.  Fixing the interrupt handling on OpenBSD/i386 isn't very
> high on my priority list.  I really recommend that people use
> OpenBSD/amd64 .  You'll get much better address space randomization
> and NX bit support that way.
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD and disk slowliness

Jorge Gabriel Lopez Paramount
In reply to this post by Kent Fritz
Quoting Kent Fritz <[hidden email]>:

> Hopefully this is not too bad advice...
>
> I've found the performance with cache=none to be unacceptable as well.
> I'm using cache=writeback.  Of course you'll get much better
> performance if you remove Linux/KVM.  :)

It might be the case for OpenBSD/i386, but in general cache=writeback  
is discouraged because you get double caching (guest OS and host OS),  
performance is usually better with direct access, and it might not be  
desirable that the guest OS behaves like data has been written into  
disk when in reality the data is still lingering in the host OS cache.

--
Best regards,
Jorge Lopez.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.