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
|

OpenBSD's extremely poor network/disk performance?

Hamdi Akyol
It's 2020 and it's -still- sad to see OpenBSD -still- has the
lowest/poorest (general/overall) performance ever:
https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1

My reference is not -only- that url, of course. My reference is my OpenBSD,
giving ~8 MB/s file transfer/network/disk speed.

A Linux distro, on the same computer (dual boot), providing 89 MB/s speed.

(Longest) sad story of the year: When it comes to OpenBSD; security -
great! Performance - horrible! I truly wish it was much better..

No, I'm not a fan of Calomel.
Reply | Threaded
Open this post in threaded view
|

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

chohag
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?

Brian Brombacher
In reply to this post by Hamdi Akyol
There might be something wrong with your setup.  I routinely get 500+ MB/s disk and full 1 GBit Ethernet.



> On Jan 7, 2020, at 9:38 AM, Hamd <[hidden email]> wrote:
>
> It's 2020 and it's -still- sad to see OpenBSD -still- has the
> lowest/poorest (general/overall) performance ever:
> https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1
>
> My reference is not -only- that url, of course. My reference is my OpenBSD,
> giving ~8 MB/s file transfer/network/disk speed.
>
> A Linux distro, on the same computer (dual boot), providing 89 MB/s speed.
>
> (Longest) sad story of the year: When it comes to OpenBSD; security -
> great! Performance - horrible! I truly wish it was much better..
>
> No, I'm not a fan of Calomel.

Reply | Threaded
Open this post in threaded view
|

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

Joe Greco
In reply to this post by chohag
On Tue, Jan 07, 2020 at 02:47:02PM +0000, [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.

Well, that's kind of ridiculous, that's not generally how threats are
remediated in the real world.

If you take a server down for 15 minutes to apply patches to Insecure-
But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is
performing lots faster during that 99.85%, but admittedly performs at
zero during the patch process.  Redundancy can cover that in many
cases.

A different argument could be that if you require a particular level of
performance, and you have to deploy more compute resources to get it,
that increases capex and opex, and the end result is a greater level of
e-waste down the road, and perhaps a greater amount of pollution if the
power is generated from "bad" sources.

In reality, when you dig down, often you find that there's another
reason for the issue.  I was recently trying to substitute libressl
into an openssl environment.  Performance tanked.  Some checking
showed the speed of "speed -evp aes-256-gcm" was way off.  It looked
to me like it was an issue with not using AES-NI.  I'm not going to
blame libressl for that, I just lacked the time to do a deep dive on
it to figure out what was (hopefully!) configured wrong.  Probably
something with ia32cap or whatever the libressl equivalent is.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Reply | Threaded
Open this post in threaded view
|

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

Antal Ispanovity
In reply to this post by Hamdi Akyol
2020-01-07 15:35 GMT+01:00, Hamd <[hidden email]>:
> It's 2020 and it's -still- sad to see OpenBSD -still- has the
> lowest/poorest (general/overall) performance ever:
> https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1
>
> My reference is not -only- that url, of course. My reference is my OpenBSD,
> giving ~8 MB/s file transfer/network/disk speed.
Maybe if you post a dmesg output and a guide to reproduce it then the
bottleneck can be identified and further steps can be taken.

>
> A Linux distro, on the same computer (dual boot), providing 89 MB/s speed.
>
> (Longest) sad story of the year: When it comes to OpenBSD; security -
> great! Performance - horrible! I truly wish it was much better..
>
> No, I'm not a fan of Calomel.
>

Reply | Threaded
Open this post in threaded view
|

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

Florian Obser-2
In reply to this post by Hamdi Akyol
On Tue, Jan 07, 2020 at 05:35:13PM +0300, Hamd wrote:
> It's 2020 and it's -still- sad to see OpenBSD -still- has the
> lowest/poorest (general/overall) performance ever:

Thank you for your kind and encouraging words.
I will get right on fixing these issues for you.

--
I'm not entirely sure you are real.

Reply | Threaded
Open this post in threaded view
|

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

Karel Gardas
In reply to this post by Hamdi Akyol

It's 2020 and you are sending a link to article from 2018?

Anyway, you (phoronix) compare '90 ffs technology with state of the art
of current storage/fs in linuxes/bsd represented by XFS/Ext4 and ZFS
filesystems and you compare with the winner right? Kind of unfair don't
you think?

And yes, ffs performance sucks, but nor me nor you provide any diff to
change that so we can just shut up and use what's available.


On 1/7/20 3:35 PM, Hamd wrote:
> It's 2020 and it's -still- sad to see OpenBSD -still- has the  > lowest/poorest (general/overall) performance ever: >
https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1 >
 > > My reference is not -only- that url, of course. My reference is my
OpenBSD,
> giving ~8 MB/s file transfer/network/disk speed.  > > A Linux distro, on the same computer (dual boot), providing 89
MB/s > speed. > > (Longest) sad story of the year: When it comes to
OpenBSD; security - > great! Performance - horrible! I truly wish it was
much better.. > > No, I'm not a fan of Calomel.

Reply | Threaded
Open this post in threaded view
|

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

Infoomatic
In reply to this post by Hamdi Akyol
1.) OpenBSD never stated that ultimate performance is their goal, but
clean maintainable code is, and thus in case of a compromise the
developers will choose clean code over performance.

2.) to quote Breandan Gregg: "All benchmarks are wrong until proven
otherwise"

3.) It's 2020 and you quote a benchmark from 2018?

4.) The code is right there, you are invited to improve the situation.


Am 07.01.20 um 15:35 schrieb Hamd:

> It's 2020 and it's -still- sad to see OpenBSD -still- has the
> lowest/poorest (general/overall) performance ever:
> https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1
>
> My reference is not -only- that url, of course. My reference is my OpenBSD,
> giving ~8 MB/s file transfer/network/disk speed.
>
> A Linux distro, on the same computer (dual boot), providing 89 MB/s speed.
>
> (Longest) sad story of the year: When it comes to OpenBSD; security -
> great! Performance - horrible! I truly wish it was much better..
>
> No, I'm not a fan of Calomel.

Reply | Threaded
Open this post in threaded view
|

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

Edgar Pettijohn III-2
In reply to this post by Hamdi Akyol

On Jan 7, 2020 9:18 AM, Joe Greco <[hidden email]> wrote:

>
> On Tue, Jan 07, 2020 at 02:47:02PM +0000, [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.
>
> Well, that's kind of ridiculous, that's not generally how threats are
> remediated in the real world.
>
> If you take a server down for 15 minutes to apply patches to Insecure-
> But-ZippyBSD, once a week, you get 99.85% uptime and presumably it is
> performing lots faster during that 99.85%, but admittedly performs at
> zero during the patch process.  Redundancy can cover that in many
> cases.
>
> A different argument could be that if you require a particular level of
> performance, and you have to deploy more compute resources to get it,
> that increases capex and opex, and the end result is a greater level of
> e-waste down the road, and perhaps a greater amount of pollution if the
> power is generated from "bad" sources.
>
> In reality, when you dig down, often you find that there's another
> reason for the issue.  I was recently trying to substitute libressl
> into an openssl environment.  Performance tanked.  Some checking
> showed the speed of "speed -evp aes-256-gcm" was way off.  It looked
> to me like it was an issue with not using AES-NI.  I'm not going to
> blame libressl for that, I just lacked the time to do a deep dive on
> it to figure out what was (hopefully!) configured wrong.  Probably
> something with ia32cap or whatever the libressl equivalent is.
>
> ... JG

I believe it has something to do with actually zeroing out memory before freeing it. Which seems like a good thing to do for crypto stuff.

Edgar

> --
> Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
> "The strain of anti-intellectualism has been a constant thread winding its way
> through our political and cultural life, nurtured by the false notion that
> democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov
>

Reply | Threaded
Open this post in threaded view
|

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

Karel Gardas
In reply to this post by Hamdi Akyol


On 1/7/20 3:35 PM, Hamd wrote:
> It's 2020 and it's -still- sad to see OpenBSD -still- has the
> lowest/poorest (general/overall) performance ever:
> https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1

Read comments to the article, I already done mine:
https://www.phoronix.com/forums/forum/software/bsd-mac-os-x-hurd-others/1058778-initial-benchmarks-of-openbsd-6-4-dragonflybsd-5-3-freebsd-vs-linux?p=1059046#post1059046


Reply | Threaded
Open this post in threaded view
|

File systems [was Re: OpenBSD's extremely poor network/disk performance?]

Stuart Longland
In reply to this post by Karel Gardas
On 8/1/20 1:25 am, Karel Gardas wrote:
> And yes, ffs performance sucks, but nor me nor you provide any diff to
> change that so we can just shut up and use what's available.

Okay, question is if not ffs, then what?

- Other BSDs have ZFS… is it viable to port that to OpenBSD?  (Maybe
it's been done before?  I didn't check.)
- FreeBSD has UFS2, DragonFlyBSD has HAMMER…  Could we borrow their code?
- 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?
- Or do we implement yet another file system?  (Seems like too much work
for not much gain IMO.)

There's merit in the third option, OpenBSD already supports EXT2 (which
is also 90's vintage like ffs) as there are some platforms (e.g.
loongson) that require it.  I run BTRFS on a lot of my Linux machines,
and aside from some features that are still experimental (quotas being
one such issue), it seems to do the job.  I've also been a big XFS user
in the past.

Performance seems good and XFS in particular has seen widespread
production use, particularly in high-performance computing arenas.  (SGI
didn't exactly do things small!)

EXT4 is also very widespread and stable, and seems to offer decent
performance.

ZFS and BTRFS are much newer, and more complicated with software RAID
functionality built in.  I think these would be harder to implement from
scratch.

DIY file systems doesn't seem like a good plan for success… it'll be a
lot of work, won't be compatible with anything else, and could be as bad
if not worse than what we have now, whilst also being untested.  ffs is
at least mature and stable!

Are any of the "modern" file systems (from a design perspective,
licensing is a different matter) suitable for use as OpenBSD's root fs?
 What would be needed?

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

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

Reply | Threaded
Open this post in threaded view
|

Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]

Tom Smyth
Howdy Stuart,

On Wed, 8 Jan 2020 at 11:17, Stuart Longland <[hidden email]> wrote:
>
> On 8/1/20 1:25 am, Karel Gardas wrote:
> > And yes, ffs performance sucks, but nor me nor you provide any diff to
> > change that so we can just shut up and use what's available.
>
> Okay, question is if not ffs, then what?
>
> - Other BSDs have ZFS… is it viable to port that to OpenBSD?  (Maybe
> it's been done before?  I didn't check.)

As far as im aware there are 2 concerns about ZFS,
1) its license  is not BSD /ISC  you can use it and make money and not be sued,
but it is more restrictive than BSD / ISC
2) then there is the Number of Lines of code, which I believe is far longer than
the OpenBSD code base,  who and what team would manage the
introduction of that code
and the risks that come with that  large a code base.

> - FreeBSD has UFS2, DragonFlyBSD has HAMMER…  Could we borrow their code?
> - If we could clean-room implement a BSD-licensed

as a user I would say sweet...  but someone more knowledgable /
involved in the project would
need to see a diff before a determination can be made.


> EXT3/EXT4/BTRFS/XFS/JFS/whatever, following style(8), would there be
> interest in supporting that in OpenBSD?
what is the story with the license? if the license is not ISC / BSD I
dont think it would be in base..

as a user I would say more filessytems sweet...  but someone more
knowledgeable / involved in the project would
need to see a diff before a determination can be made.

> - Or do we implement yet another file system?  (Seems like too much work
> for not much gain IMO.)

as an OpenBSD user I would say that the performance of Network
is dependent on your hardware. / the specific hardware Driver
compatibility /capability in OpenBSD,
I have had a different performance experience depending on the
hardware I was using, and the
maturity of the Driver support for that hardware.

I have found the em(4) supported nics are pretty good ix(4) has solid
performance
vmx(4) have been good but it is dependent on the Vmware version you are using ,
and then others like vio(4) interfaces I have not had as good a
performance. but that
is more due to the age of the drivers and their capability vs what
newer virtio drivers can do.

But as a number of members of the OpenBSD Project have said to me
Diffs are welcome ...   Good Diffs will be considered....
just bear in mind the the License Requirements and Coding Style  KNF
when submitting a diff and do it off current...

>
> Regards,
> --
> Stuart Longland (aka Redhatter, VK4MSL)
>
> I haven't lost my mind...
>   ...it's backed up on a tape somewhere.
>


--
Kindest regards,
Tom Smyth.

Reply | Threaded
Open this post in threaded view
|

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

ian@
In reply to this post by Stuart Longland
> - 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?

> There's merit in the third option, OpenBSD already supports EXT2 (which
> is also 90's vintage like ffs) as there are some platforms (e.g.
> loongson) that require it.
>...
> EXT4 is also very widespread and stable, and seems to offer decent
> performance.

So send a diff that upgrades the code to ext3 and 4.

> ZFS and BTRFS are much newer, and more complicated with software RAID
> functionality built in.  I think these would be harder to implement from
> scratch.

Persuade the owners to release under an ISC license. Then send a diff.

Reply | Threaded
Open this post in threaded view
|

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

Hamdi Akyol
In reply to this post by Infoomatic
"4.) The code is right there, you are invited to improve the situation."
Simple answer: I'm not a developer, I'm a user. A regular one.

Under less than 24 hours, after my post, the misc has received 2 or 3 brand
new questions/posts regarding slow*. The problem is, well, obviously not
me, personally.
For the Dev Team (All of 'em. Volunteer, beer-teer, pay-teer ones): I
regretfully think, the time of changing that filesystem older than my
2xgrandfather, has arrived.
Ciao a tutti.


infoomatic <[hidden email]>, 7 Oca 2020 Sal, 18:31 tarihinde şunu yazdı:

> 1.) OpenBSD never stated that ultimate performance is their goal, but
> clean maintainable code is, and thus in case of a compromise the
> developers will choose clean code over performance.
>
> 2.) to quote Breandan Gregg: "All benchmarks are wrong until proven
> otherwise"
>
> 3.) It's 2020 and you quote a benchmark from 2018?
>
> 4.) The code is right there, you are invited to improve the situation.
>
>
> Am 07.01.20 um 15:35 schrieb Hamd:
>
> > It's 2020 and it's -still- sad to see OpenBSD -still- has the
> > lowest/poorest (general/overall) performance ever:
> > https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1
> >
> > My reference is not -only- that url, of course. My reference is my
> OpenBSD,
> > giving ~8 MB/s file transfer/network/disk speed.
> >
> > A Linux distro, on the same computer (dual boot), providing 89 MB/s
> speed.
> >
> > (Longest) sad story of the year: When it comes to OpenBSD; security -
> > great! Performance - horrible! I truly wish it was much better..
> >
> > No, I'm not a fan of Calomel.
>
Reply | Threaded
Open this post in threaded view
|

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

Joe Greco
On Wed, Jan 08, 2020 at 05:57:37PM +0300, Hamd wrote:
> Under less than 24 hours, after my post, the misc has received 2 or 3 brand
> new questions/posts regarding slow*.

Well, in the case of my issue, I am reasonably certain that this isn't
an issue with LibreSSL.  I raised it as an issue of simply not knowing
how to get it to do what I need at the speeds it is clearly capable
of, on i386.  It works fine and at approximately OpenSSL speeds on
amd64.

> The problem is, well, obviously not me, personally.

I beg to differ.

Your repurposing my question for your own ends in an attempt to
categorize it as an general OpenBSD performance issue is, in my
opinion, full of **it.

This is not helpful to those of us who are asking legitimate
questions of those who are more familiar with these projects.
I know I've made a dumb mistake of some sort and I was hoping
someone would point it out.

If you do not like the product, don't use it.  Or submit a patch
to fix it.

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"The strain of anti-intellectualism has been a constant thread winding its way
through our political and cultural life, nurtured by the false notion that
democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Drews-3
In reply to this post by Hamdi Akyol

 

Sent: Tuesday, January 07, 2020 at 7:35 AM
From: "Hamd" <[hidden email]>
To: [hidden email]
Subject: OpenBSD's extremely poor network/disk performance?
It's 2020 and it's -still- sad to see OpenBSD -still- has the
lowest/poorest (general/overall) performance ever:
https://www.phoronix.com/scan.php?page=article&item=8-linux-bsd&num=1

My reference is not -only- that url, of course. My reference is my OpenBSD,
giving ~8 MB/s file transfer/network/disk speed.

A Linux distro, on the same computer (dual boot), providing 89 MB/s speed.

(Longest) sad story of the year: When it comes to OpenBSD; security -
great! Performance - horrible! I truly wish it was much better..
 
------------------------------------------------------------------
I did a test using bonnie++ on my T420 ThinkPad. I have softdep inabled for
my /Home filesystem

Here are the results:

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
leo.cats.domain  8G   313  98 25039   5  7747   3   364  98 93950  31  86.6  10
Latency             49275us     315ms    1024ms   58491us   76221us    4459ms

K/sec means KiloBytes/second. If am reading this correctly, it looks like reading
at ~25 Mb/sec. Since it is sequential, it didn't use soft updates.

My abbreviated dmesg:

 OpenBSD 6.6 (GENERIC.MP) #4: Wed Dec 18 06:44:06 MST 2019
    [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4156157952 (3963MB)
avail mem = 4017496064 (3831MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root


cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2492.30 MHz, 06-2a-07
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 2491.92 MHz, 06-2a-07
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0

scsibus1 at ahci0: 32 targets

sd0 at scsibus1 targ 0 lun 0: <ATA, ST320LT007-9ZV14, 0004> naa.5000c500441a1cbd
sd0: 305245MB, 512 bytes/sector, 625142448 sectors


From man 8 mount:

softdep    (FFS only) Mount the file system using soft
                        dependencies.  Instead of metadata being written
                        immediately, it is written in an ordered fashion to
                        keep the on-disk state of the file system consistent.
                        This results in significant speedups for file
                        create/delete operations.  This option is ignored when
                        using the -u flag and a file system is already mounted
                        read/write.

Here is what my fstab looks like

removed.b none swap sw
removed.a / ffs rw 1 1
removed.k /home ffs rw,nodev,nosuid,softdep 1 2
removed.d /tmp ffs rw,nodev,nosuid,softdep 1 2
removed.f /usr ffs rw,nodev,softdep 1 2
removed.g /usr/X11R6 ffs rw,nodev,softdep 1 2
removed.h /usr/local ffs rw,wxallowed,nodev,softdep 1 2
removed.j /usr/obj ffs rw,nodev,nosuid,softdep 1 2
removed.i /usr/src ffs rw,nodev,nosuid,softdep 1 2
removed.e /var ffs rw,nodev,nosuid 1 2



Reply | Threaded
Open this post in threaded view
|

Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]

Karel Gardas
In reply to this post by Tom Smyth


On 1/8/20 12:44 PM, Tom Smyth wrote:
> As far as im aware there are 2 concerns about ZFS,
> 1) its license  is not BSD /ISC  you can use it and make money and not be sued,
> but it is more restrictive than BSD / ISC

Yes, CDDL seems to be a no go based on past CDDL discussion which is
available for example in Star & OpenBSD thread on @tech:

https://marc.info/?l=openbsd-tech&m=110806948606417&w=2
> 2) then there is the Number of Lines of code, which I believe is far longer than
> the OpenBSD code base,  who and what team would manage the
> introduction of that code
> and the risks that come with that  large a code base.

Need to correct you a bit:

ZFS: ~110k lines
XFS: ~95k lines
Ext4: ~38k lines

while OpenBSD src/sys alone:
~3.7mil lines where majority is in dev. But if I subtract drm code which
is probably the biggest contribution in dev (~1.7 mil lines), then I
still get roughly 2 mil lines of code in sys -- which is just part of base.

LInes counted by sloccount.

Reply | Threaded
Open this post in threaded view
|

Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]

Tom Smyth
Hi Karel,

Thanks, for the correction...

I thought zfs was bigger than that ;)
Thanks


On Wednesday, 8 January 2020, Karel Gardas <[hidden email]> wrote:

>
>
> On 1/8/20 12:44 PM, Tom Smyth wrote:
>
>> As far as im aware there are 2 concerns about ZFS,
>> 1) its license  is not BSD /ISC  you can use it and make money and not be
>> sued,
>> but it is more restrictive than BSD / ISC
>>
>
> Yes, CDDL seems to be a no go based on past CDDL discussion which is
> available for example in Star & OpenBSD thread on @tech:
>
> https://marc.info/?l=openbsd-tech&m=110806948606417&w=2
>
>> 2) then there is the Number of Lines of code, which I believe is far
>> longer than
>> the OpenBSD code base,  who and what team would manage the
>> introduction of that code
>> and the risks that come with that  large a code base.
>>
>
> Need to correct you a bit:
>
> ZFS: ~110k lines
> XFS: ~95k lines
> Ext4: ~38k lines
>
> while OpenBSD src/sys alone:
> ~3.7mil lines where majority is in dev. But if I subtract drm code which
> is probably the biggest contribution in dev (~1.7 mil lines), then I still
> get roughly 2 mil lines of code in sys -- which is just part of base.
>
> LInes counted by sloccount.
>
>

--
Kindest regards,
Tom Smyth.
Reply | Threaded
Open this post in threaded view
|

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

Stuart Longland
In reply to this post by ian@
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.

Can't commit to doing anything right away, but it'll be slotted
somewhere in the back-log.

>…

>> ZFS and BTRFS are much newer, and more complicated with software RAID
>> functionality built in.  I think these would be harder to implement from
>> scratch.
>
> Persuade the owners to release under an ISC license. Then send a diff.
>

Yeah, I think there's been discussions about changing the license (to
GPL for Linux kernel use) and those came to a dead end.  I don't see the
copyright holders being receptive to ISC either.

--
Stuart Longland (aka Redhatter, VK4MSL)

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

Reply | Threaded
Open this post in threaded view
|

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

Ingo Schwarze
Hi Stuart,

Stuart Longland wrote on Thu, Jan 09, 2020 at 09:07:38AM +1000:
> Somebody 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?

> I'm hoping it will be more than one person assisting in this,
> and yes, I include myself in that group.

schwarze@cvs $ grep -Fi longland /cvs/CVSROOT/ChangeLog*                      
schwarze@cvs $

And https://stuartl.longlandclan.id.au/ lists a single free software
project, about 190 commits of Python code, with one single contributor.


I'm sorry that i have to use somewhat strong wording here, i'm
generally trying to help making our lists as friendly as possible,
but in this case, a clear answer is really required.

There is few code that is as difficult as a file system.
There is few code that is as closely entangled with the hardest
parts of there kernel like file system code.
There is few code where touching it is as dangerous as touching
file system code.
There are few areas of the system where people get as upset
when you break it as with file systems.  You literally make people
lose their personal data, and when they realize something went wrong,
it's usually too late, the data is usually already gone for good.

You are certainly welcome to contribute if you want to: start with
sending samll bugfix patches.  Progress to small feature additions
or small cleanup patches in areas that are not too dangerous.
Then grow.  Anything beyond that is impossible to predict.

For a newbie, there is really no point in dreaming about
implementing or changing file systems.

You need to learn what you are capable of and then convince others
of your abilities *by getting good patches committed*.  Idle talk
announcing bizarre dreams doesn't really help anyone.

Are you aware that even Bob Beck@ is seriously scared of some
parts of our file system code, and of touching some parts of it?
Yes, this Bob Beck, who isn't really all that easily scared:

  https://www.youtube.com/watch?v=GnBbhXBDmwU

One of our most senior developers, regularly and continuously
contributing since 1997, and among those who understand our
file system code best.  Most recently, he was among the main
driving forces behind unveil(2).


Becoming able to approximately judge the difficulty and size of
tasks relative to your own abilities is extremely important when
you want to contribute to free software.

Even if you had, let's say, a whole year to spend full-time, you
would not really be making any sense right now.  So, could we drop
this thread, please?

Yours,
  Ingo

123