OpenBSD's extremely poor network/disk performance?

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

Re: OpenBSD's extremely poor network/disk performance?

Karel Gardas
On 1/9/20 4:37 PM, Karel Gardas wrote:

> On 1/9/20 3:22 PM, Hamd wrote:
>> FreeBSD:
>> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k
>> count=50000
>> && sync"
>> 50000+0 records in
>> 50000+0 records out
>> 204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
>> 0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w
>>
>> Result: *854.79 MB/s disk speed*
>
> I'm afraid a lot of those data are still in RAM waiting for fs sync.
> At least do sync which is whole sys sync and add time of it to to the
> time of dd. It'll still not be 100% accurate, but at least more
> realistic...

Shit happen. Sorry I've overlooked && sync on another line. Default
setup, does it mean ZFS or UFS? I don't remember the default option
since I've installed 12.1 few weeks ago and has not paid attention.
Looking forward to see your openbsd dmesg anyway.

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Christer Solskogen-3
In reply to this post by Hamdi Akyol
On Thu, Jan 9, 2020 at 3:25 PM Hamd <[hidden email]> wrote:

> Joe, are you a joke? Please stop insulting me, this is not
> my/your_personal_fancy_forum.
>
> This will be my last post here in misc.
>
> Default setups, no config. changes.
> Just patches installed.
> Same hardware.
>
> FreeBSD:
> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000
> && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
> 0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w
>
> Result: *854.79 MB/s disk speed*
>
> freebsd@test:~ # uname -a
> FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
>
> OpenBSD:
> test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 12.303 secs (16645247 bytes/sec)
>     0m12.32s real     0m00.13s user     0m01.28s system
>
> Result: *16.64 MB/s disk speed*
>
> test$ uname -a
> OpenBSD test.local 6.6 GENERIC#3 amd64
>
>
I have no idea what hw you are on, but on my apu2c4*:

tugs$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000"
50000+0 records in
50000+0 records out
204800000 bytes transferred in 1.495 secs (136960919 bytes/sec)
    0m01.51s real     0m00.04s user     0m01.35s system

tugs$ uname -a
OpenBSD tugs.antarctica.no 6.6 GENERIC.MP#584 amd64

Seems pretty damn fast to me.

*) https://pcengines.ch/apu2c4.htm
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Philipp Buehler
In reply to this post by Ingo Schwarze
Am 09.01.2020 16:10 schrieb Ingo Schwarze:
>> https://www.youtube.com/watch?v=HTD9Gow1wTU

And Bob gave a talk about VFS hacking the very same
event. Might be an eye-opener of those "proposing to help".
https://www.youtube.com/watch?v=rVb8jdlP4gE
(somehow the slides didn't made it to /papers/?)


> Cool, i wasn't even aware of thib@'s talk back then.  That was the
> very first year i ever took part in a hackathon, and it wasn't that

And I wasn't aware the 3-line-diff joke is at least that old.. hmm :)

Anyway.. at c2k3 (or was it 2004?) I was looking
into porting linux ciss(4) driver to OpenBSD naively.
As a more or less young gun back then: "all driver code is there, just
some... interfaces and be done!". Nope.

Well, you cannot hack storage/disk drivers without some VFS
knowledge.. mickey@ (bless him!!), art@ and niklas@ walked me
through someof that but hell.. what did I knew.
Long story short: even with help and lotsa beer I ended up with
empty hands. (eventually mickey did the "port" 1-2y later (by manpage
3.8)

So for the "aah, cant be that hard" crowd: it IS a bloody messy
place (even IF you rip NFS out of it....). I'd say hacking in this
area (arena..) requires years of experience to produce something
that can go into the tree.

In other news.. ah no, cut it.

HTH,
--
pb

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Jordan Geoghegan-3
In reply to this post by Hamdi Akyol


On 2020-01-09 06:22, Hamd wrote:

> Joe, are you a joke? Please stop insulting me, this is not
> my/your_personal_fancy_forum.
>
> This will be my last post here in misc.
>
> Default setups, no config. changes.
> Just patches installed.
> Same hardware.
>
> FreeBSD:
> freebsd@test:~ # time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000
> && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 0.239590 secs (854792500 bytes/sec)
> 0.000u 0.195s 0:00.25 76.0%     22+198k 0+1568io 0pf+0w
>
> Result: *854.79 MB/s disk speed*
>
> freebsd@test:~ # uname -a
> FreeBSD test.local 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC  amd64
>
> OpenBSD:
> test$ time sh -c "dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync"
> 50000+0 records in
> 50000+0 records out
> 204800000 bytes transferred in 12.303 secs (16645247 bytes/sec)
>      0m12.32s real     0m00.13s user     0m01.28s system
>
> Result: *16.64 MB/s disk speed*
>
>
[snip]

probook$ dd if=/dev/zero of=test.tmp bs=4k count=50000 && sync
50000+0 records in
50000+0 records out
204800000 bytes transferred in 0.731 secs (280047607 bytes/sec)

I'm getting well over 250MB/s on my laptop.

Is your hard drive attached as an sd or wd device?


Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Marc Espie-2
In reply to this post by Stuart Longland
On Thu, Jan 09, 2020 at 09:07:38AM +1000, Stuart Longland wrote:

> On 9/1/20 12:56 am, Ian Darwin wrote:
> >> - If we could clean-room implement a BSD-licensed
> >> EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be
> >> interest in supporting that in OpenBSD?
> >
> > And which "we" are you referring to here? Did you mean yourself,
> > or are you hoping that "somebody" will do it?
>
> I'm hoping it will be more than one person assisting in this, and yes, I
> include myself in that group.

One useful thing you could do is review the diffs that are routinely
sent to various OpenBSD mailing-lists.

For instance, I have sent a few make-related diffs recently, on
which I'm still awaiting reviews.

How is this related to filesystem work, you may ask ?

Well, it's very related, though indirectly.

See, there aren't that many people actually doing the work
in OpenBSD.  A lot of it is routine work, but vital for
the project.

Queue Ingo and mandoc.
Queue me and make... and various other things.

and lots of other developers at time. Better lld support.
continuing the work started on ctf, etc, etc.


If there were more people actually *helping* instead of talking shit,
that stuff would go forward, and maybe, just maybe, us and other
developers *could* allocate time to do other stuff.

That might (or might not) include filesystem work.

Having the whole infrastructure working better would definitely help.

But no, it's way more fun to just sit there and say "hey, I only want
to do the sexy stuff. Please pre-chew it for me to baby-vomit stage so
I can be smug about it".

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Özgür Kazancci
In reply to this post by Xiyue Deng
On 09/01/2020 05:15, Xiyue Deng wrote:

> Some guy asks whether there's any plan to improve file system
> performance, the answer given is the code is right there if you want to
> contribute.  Then some other guy offers a proposal to start working on
> it, and the answer now becomes you are hardly qualified for such kind
> of
> work.
>
> Sorry but such kinds of answers are not helpful, and gives the
> (potentially wrong) impression that OpenBSD doesn't welcome
> contributions.  It would be better to point out where to start, what
> hard problems to solve, what work has been done in this area that
> people
> can continue to work on.

^^Totally agree on each and every word here. (And yes, noone cares)
*Unsighs

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Marc Espie-2
If you want a useful project related to filesystems,
try the automounter.

Yes, that ancient code.

Look very closely. It has tendrils in NFSv2.

And some people, most prominently Theo, use amd(8).

Write an automounter that does not depend on NFSv2,
and then, most probably we can kill NFSv2.

Small steps...

It's been that way for ages. But no-one volunteered
to work on this.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Consus-2
On 20:06 Thu 09 Jan, Marc Espie wrote:
> It's been that way for ages. But no-one volunteered
> to work on this.

Anyone even knows about this? Aside from OpenBSD developers (who have
their plates full already) how an average person can find out that there
is rusty piece of code that should be taken care of?

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Janne Johansson-3
Den fre 10 jan. 2020 kl 10:55 skrev Consus <[hidden email]>:

> On 20:06 Thu 09 Jan, Marc Espie wrote:
> > It's been that way for ages. But no-one volunteered
> > to work on this.
>
> Anyone even knows about this? Aside from OpenBSD developers (who have
> their plates full already) how an average person can find out that there
> is rusty piece of code that should be taken care of?
>

By using the parts that OpenBSD is made up of, and not automatically moving
to other OSes as soon as you leave the comfort zone.
Guess that is how many ports gets added. $prg exist for $other_os but not
OpenBSD, someone does the work to make it run on OpenBSD and there you go.

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Consus-2
On 11:08 Fri 10 Jan, Janne Johansson wrote:
> By using the parts that OpenBSD is made up of, and not automatically moving
> to other OSes as soon as you leave the comfort zone.

I'm not sure, but it seems like from a user perspective there is nothing
wrong with amd(8). Only that it keeps using legacy code.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Stefan Sperling-5
In reply to this post by Consus-2
On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote:
> On 20:06 Thu 09 Jan, Marc Espie wrote:
> > It's been that way for ages. But no-one volunteered
> > to work on this.
>
> Anyone even knows about this? Aside from OpenBSD developers (who have
> their plates full already) how an average person can find out that there
> is rusty piece of code that should be taken care of?

Don't start looking at other people's problems before you can help yourself.
Rewriting automounter for Theo as a first contribution is not likely to work.
Find something small that annoys *you* and get involved by fixing that first.
Learn how to approach and debug issues that affect you directly.

How did I get into OpenBSD wifi?
Because my OpenBSD access point stopped accepting new associations after
one about week of usage. It turned out this was one of those problems
which had been known for years and all this time people had been switching
to non-OpenBSD APs to work around it. I had lived with the problem for
about a year or two, resetting the wifi interface on the AP whenever it
happened.

Then I noticed that 'ifconfig ath0 scan' showed a very long list of known
MAC addresses whenever the problem occurred. So I looked for a way trigger
the problem faster than in one week and succeeded by running this loop
on the client which made the problem appear after a few minutes:

  ifconfig iwn0 up
  while sleep 5; do ifconfig iwn0 lladdr random; done

Looking at the code I found that known MACs never expired! Once the AP had
reached its limit of learned MACs it accepted no new associations because
no room was made for new MAC addresses. Fix was a 3-line diff, which I
could verify with my above test.

-----------------------------------------------
commit 6bbde753957f0b27c56cfdd15c9af836579d120b
from: stsp <[hidden email]>
date: Wed Jan 18 14:35:34 2012 UTC
 
 Make it possible to free cached nodes which never associated (e.g. nodes
 only scanning for networks). These were never put into COLLECT state and
 were thus never evicted from the node cache in hostap mode.
 ok jsg@
 
diff ae44467745d21c295e8ffe38340d662269578502 d62cb122bc6abf011c13400ea5c3f90c56292854
blob - 893de460bfd2a1509205c4e5d837ba6f8d5c2636
blob + 9435a287862a29a9dc79ea09ce8328b8e054c819
--- sys/net80211/ieee80211_node.c
+++ sys/net80211/ieee80211_node.c
@@ -1507,8 +1507,10 @@ ieee80211_node_leave(struct ieee80211com *ic, struct i
  * If node wasn't previously associated all we need to do is
  * reclaim the reference.
  */
- if (ni->ni_associd == 0)
+ if (ni->ni_associd == 0) {
+ ieee80211_node_newstate(ni, IEEE80211_STA_COLLECT);
  return;
+ }
 
  if (ni->ni_pwrsave == IEEE80211_PS_DOZE)
  ic->ic_pssta--;

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Consus-2
On 11:28 Fri 10 Jan, Stefan Sperling wrote:

> On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote:
> > On 20:06 Thu 09 Jan, Marc Espie wrote:
> > > It's been that way for ages. But no-one volunteered
> > > to work on this.
> >
> > Anyone even knows about this? Aside from OpenBSD developers (who have
> > their plates full already) how an average person can find out that there
> > is rusty piece of code that should be taken care of?
>
> Don't start looking at other people's problems before you can help yourself.
> Rewriting automounter for Theo as a first contribution is not likely to work.
> Find something small that annoys *you* and get involved by fixing that first.
> Learn how to approach and debug issues that affect you directly.
>
> How did I get into OpenBSD wifi?
> Because my OpenBSD access point stopped accepting new associations after
> one about week of usage. It turned out this was one of those problems
> which had been known for years and all this time people had been switching
> to non-OpenBSD APs to work around it. I had lived with the problem for
> about a year or two, resetting the wifi interface on the AP whenever it
> happened.
>
> Then I noticed that 'ifconfig ath0 scan' showed a very long list of known
> MAC addresses whenever the problem occurred. So I looked for a way trigger
> the problem faster than in one week and succeeded by running this loop
> on the client which made the problem appear after a few minutes:
>
>   ifconfig iwn0 up
>   while sleep 5; do ifconfig iwn0 lladdr random; done
>
> Looking at the code I found that known MACs never expired! Once the AP had
> reached its limit of learned MACs it accepted no new associations because
> no room was made for new MAC addresses. Fix was a 3-line diff, which I
> could verify with my above test.

Neat. Though I'm using OpenBSD only for a router and since issues
preventing me from using it on a desktop (or NAS) are pretty huge to be
my "good first issues" that's not an option, sadly. So only donations /
occasional bug reports from me :D

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...]

Marc Espie-2
In reply to this post by Stefan Sperling-5
On Fri, Jan 10, 2020 at 11:28:07AM +0100, Stefan Sperling wrote:

> On Fri, Jan 10, 2020 at 12:52:44PM +0300, Consus wrote:
> > On 20:06 Thu 09 Jan, Marc Espie wrote:
> > > It's been that way for ages. But no-one volunteered
> > > to work on this.
> >
> > Anyone even knows about this? Aside from OpenBSD developers (who have
> > their plates full already) how an average person can find out that there
> > is rusty piece of code that should be taken care of?
>
> Don't start looking at other people's problems before you can help yourself.
> Rewriting automounter for Theo as a first contribution is not likely to work.
> Find something small that annoys *you* and get involved by fixing that first.
> Learn how to approach and debug issues that affect you directly.


Ditto.

There are lots and lots of pieces in OpenBSD that could use some "obvious"
improvements, and not enough developers to do it all these days.

Ask anyone with an OpenBSD account how he got it, you'll get the same
story: use the OS, get annoyed by a small thing, start sending patches.

Very soon, you get to be responsible for some stuff.

No magic, just use the OS and scratch the itches.

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff

Ingo Schwarze
In reply to this post by Consus-2
Hi,

Consus wrote on Fri, Jan 10, 2020 at 12:52:44PM +0300:
> On 20:06 Thu 09 Jan, Marc Espie wrote:

>> It's been that way for ages. But no-one volunteered
>> to work on this.

> Anyone even knows about this? Aside from OpenBSD developers (who
> have their plates full already) how an average person can find out
> that there is rusty piece of code that should be taken care of?

I believe it was said before, but it appears to be easily forgotten:
Maintaining TODO lists consumes time.  For a small system that you do
a lot of work on, the time required for the maintenance of a TODO
list is not prohibitive; that's why

  https://cvsweb.bsd.lv/mandoc/TODO

exists.  But for a large sytem (like OpenBSD as a whole), maintaining
a high-quality TODO list is much harder, in particular for a person
who doesn't know the details of all the parts inside out.  And those
few developers who do know (almost) all the parts inside out are
those who can least afford to take on yet another job.

Besides, the usefulness of public TODO lists is usually vastly
overestimated.  I have some actual data on that.  The above TODO
list concerns the implementation of a POSIX.1 utility that, as of
today, is included and used by default in eight operating systems
(OpenBSD, Alpine Linux, Void Linux, Unleashed, Termux, FreeBSD,
NetBSD, illumos), included by default in two more (DragonFly BSD,
Minix 3) and available as an optional package for ten more (Debian,
Ubuntu, NixOS, Gentoo, Fedora, Arch, Slackware, Crux, openSUSE,
MacOS).  So it does have a substantial user base.  The TODO list
has been available online and continuously maintained for more than
nine years now, since May 2010.  Since October 2013, see below for
a complete list of committed patches that were sent in by developers
other than Kristaps and myself.  The metric that i can easily extract
from this data is contributors times releases: if a contributor
sent patches during multiple release cycles, they are counted
multiple times, but if a contributor sent multiple patches for the
same release (which were never more than a handful from anyone)
that's counted as just one contribution, simply because i don't
have more fine-grained data easily available.

There were 34 such contributions for 11 releases during these six
years, i.e. on average three outside contributors per release or
about five per year.  The vast majority came from developers
already working on other free software projects:

 * 22 from (non-mandoc) OpenBSD developers (that's 65%, btw.!)
 * 3 from FreeBSD developers
 * 1 from NetBSD developers
 * 1 from Debian Linux developers
 * 1 from Void Linux developers
 * 1 from Alpine Linux developers
 * 2 from Crux Linux developers
 * and only 3 from other people

As far as i remember, all of these went like "i noticed this bug,
here is a patch to fix it" or "i had the idea that this feature
addition might be useful, do you like this patch?"  I can't remeber
a single case that went like "i looked at your TODO list and decided
to resolve this item, here is the patch".  Not one in ten years as
far as i can remember.

In conclusion, i'm keeping the TODO list purely for myself.  Myself,
i do regularly look at it and decide to tackle an item to shorten
the list.  The only reason for making it public is such that users
can distinguish between known and unknown issues in case they find
some.  Experience shows that it is neither needed nor indeed useful
for encouraging contributions.

As stsp@ and espie@ already said, that's probably because for people
who are able to contribute, it's easy to find the issues they want
to fix all by themselves, without any help from me.

Yours,
  Ingo


1.12.3 Dec 13 (2)
 * Franco Fichtner for a patch to add a minor missing feature.
 * Tsugutomo ENAMI for a patch to add a minor missing feature.
1.13.1 Aug 14 (0)
1.13.2 Dec 14 (7)
 * Anthony Bentley (OpenBSD), Baptiste Daroussin (FreeBSD), Daniel
   Dickman, Doug Hogan, Jason McIntyre, Theo de Raadt (OpenBSD),
   and Martin Natano (OpenBSD) for source code patches.
1.13.3 Mar 15 (3)
 * Anthony Bentley, Daniel Dickman, and Ted Unangst (OpenBSD)
   for source code patches and bug reports.
1.13.4 Jul 16 (7)
 * Anthony Bentley (OpenBSD) for unifying mandoc.css, two nice
   patches for man.cgi(8), some documentation patches, some bug
   reports, and various useful discussions.
 * Todd Miller (OpenBSD) for lots of help with process group and
   signal handling, a few patches, some bug reports and some useful
   discussions.
 * Svyatoslav Mishyn (Crux Linux) for some patches, several bug
   reports, and extensive release testing.
 * Leah Neukirchen (Void Linux) for a number of compatibility
   patches and suggestions and several bug reports.
 * Christos Zoulas (NetBSD) for a bug fix patch and some useful
   suggestions for cleanup.
 * Florian Obser (OpenBSD) for a bugfix patch and some bug reports.
 * Michael McConville (OpenBSD) for some simple cleanup patches.
1.14.1 Feb 17 (3)
 * Michael Stapelberg (Debian) for designing the new mandocd(8)
   and parts of the new catman(8), for release testing, and for a
   number of patches and bug reports.
 * Ed Maste (FreeBSD) for an important patch improving reproducibility
   of builds in makewhatis(8), and for a few bug reports.
 * Svyatoslav Mishyn (Crux Linux) for an initial version of the
   patch to autodetect a suitable locale for -Tutf8 mode
   and for release testing.
1.14.2 Jul 17 (2)
 * Sebastien Marie (OpenBSD) for two source code patches and
   for some useful discussions.
 * Florian Obser (OpenBSD) for a bugfix patch and a bug report.
1.14.3 Aug 17 (0)
1.14.4 Aug 18 (2)
 * Marc Espie (OpenBSD) for implementing the size reduction of
   PostScript files, one additional patch for code simplification,
   and two bug reports.
 * Theo Buehler (OpenBSD) for a bugfix patch.
1.14.5 Mar 19 (6)
 * Alexander Bluhm, Raphael Graf, Ted Unangst (OpenBSD)
   and Daniel Sabogal (Alpine Linux) for patches.
 * Kyle Evans and Baptiste Daroussin (FreeBSD) for minor patches.
1.14.6 XXX 20 (2)
 * Marc Espie (OpenBSD) for a patch and for suggesting a feature impovement
 * Anton Lindqvist (OpenBSD) for a patch

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Hamdi Akyol
In reply to this post by chohag
"Can't say much for the performance of a suite of servers which have
all been taken down to handle the security threat du jour."

Repeat it again?
https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt?_ga=2.120267019.2069438099.1580381821-1178380388.1580381821




<[hidden email]> adresine sahip kullanıcı 7 Oca 2020 Sal, 17:48 tarihinde
şunu yazdı:

> Hamd writes:
> > It's 2020 and it's -still- sad to see OpenBSD -still- has the
> > ... lists full of the uninteresting type of wine and that their
> > twitterings -still- don't include any code.
>
> Yes. Yes it is.
>
> Can't say much for the performance of a suite of servers which have
> all been taken down to handle the security threat du jour.
>
> Matthew
>
>
Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

Kevin Chadwick-4
On 2020-01-30 10:57, Handreas wrote:
> "Can't say much for the performance of a suite of servers which have
> all been taken down to handle the security threat du jour."
>
> Repeat it again?
> https://www.qualys.com/2020/01/28/cve-2020-7247/lpe-rce-opensmtpd.txt?_ga=2.120267019.2069438099.1580381821-1178380388.1580381821

syspatch
rcctl restart smtpd

Also, I have seen ~147 megabytes per second of data read from disk and from
/dev/urandom without issue at almost any time!

Reply | Threaded
Open this post in threaded view
|

Re: OpenBSD's extremely poor network/disk performance?

slackwaree
In reply to this post by chohag
And you link a report from 2018 in 2020, currently we are at OpenBSD 6.6. Maybe instead of spamming stupidity on the mailing list do the benchmarks yourself with current systems on the same hardware and publish those results.

I personally don't have any issues with OpenBSD being drastically slower for some tasks than Linux, except MySQL server, so I run that on netbsd and problem is solved.



‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, January 7, 2020 3:47 PM, <[hidden email]> wrote:

> Hamd writes:
>
> > It's 2020 and it's -still- sad to see OpenBSD -still- has the
> > ... lists full of the uninteresting type of wine and that their
> > twitterings -still- don't include any code.
>
> Yes. Yes it is.
>
> Can't say much for the performance of a suite of servers which have
> all been taken down to handle the security threat du jour.
>
> Matthew


Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...] Probably not gonna happen anyway

jeanfrancois
In reply to this post by Theo de Raadt-2
Good evening,

Very good videos are available from one of the developer of EXT2/3/4
recommended to see.

https://www.youtube.com/watch?v=2mYDFr5T4tY

OpenBSD's FFS code looks awesome.


Jean-François


Le 09/01/2020 à 03:25, Theo de Raadt a écrit :

> Xiyue Deng <[hidden email]> wrote:
>
>> It would be better to point out where to start, what
>> hard problems to solve, what work has been done in this area that people
>> can continue to work on.
> Looking at that list, noone here owes you any of those.
>
> Do your own homework.
>
> Re-reading the thread is remarkable.  It's a bunch of people who
> won't do the work telling us that we need to tell them what work
> to do.  A bunch of garbage is coming out of your mouths.
>

Reply | Threaded
Open this post in threaded view
|

Re: Awaiting a diff [was: Re: File systems...] Probably not gonna happen anyway

Stuart Longland
On 13/2/20 5:17 am, jeanfrancois wrote:
> Good evening,
>
> Very good videos are available from one of the developer of EXT2/3/4
> recommended to see.
>
> https://www.youtube.com/watch?v=2mYDFr5T4tY
>
> OpenBSD's FFS code looks awesome.

It's mature, and not worth chucking out anytime soon as it'll be much
more stable than any effort to port ${FANCYFS} will be.

About the only big complaint I've heard about it is that there's no
journaling which slows down boot times after an unclean shut-down
(particularly for larger volumes).  This does concern me, but not
greatly at this point.

It's on my rather large back-log to look at, some time in the future
unless someone beats me to it.  (Contrary to others' research, pet
Python projects is not my sole software development experience.)

As it happens there's two ways I can scratch my itch (management of
OpenBSD disk partitions):

1. get OpenBSD to run on a FS that the tools I have¹ understand
   (side-benefit: OpenBSD gains support for a journalled FS)
2. get the tools I have to understand OpenBSD disklabels + ffs
   (side-benefit: people would be able to re-arrange² partitions)

As this thread already struck a few raw nerves last time, I would
suggest if there's any interest, we can collectively discuss it off-list.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

¹. Mainly what I miss is a tool for re-arranging partitions.  gparted
has served me well for this purpose.
². Primarily the goal here being that a user can "move" partitions
around to re-organise free space.  Right now one can "grow" a partition,
but shuffling the partitions around is not easily possible without
daring unsupported and dangerous acts using `dd`, `disklabel` and `growfs`.

123