Re: Awaiting a diff [was: Re: File systems...] Probably not gonna happen anyway
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`.
Re: Awaiting a diff [was: Re: File systems...] Probably not gonna happen anyway
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 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.
Re: Awaiting a diff [was: Re: File systems...]
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.
Re: Awaiting a diff [was: Re: File systems...]
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
Re: Awaiting a diff [was: Re: File systems...]
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
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--;
Re: Awaiting a diff [was: Re: File systems...]
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.
Re: Awaiting a diff [was: Re: File systems...]
Den fre 10 jan. 2020 kl 10:55 skrev Consus : > 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.
Re: Awaiting a diff [was: Re: File systems...]
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?
Re: Awaiting a diff [was: Re: File systems...]
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.
Re: Awaiting a diff [was: Re: File systems...]
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
Re: Awaiting a diff [was: Re: File systems...]
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".
Re: Awaiting a diff [was: Re: File systems...]
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
Re: Awaiting a diff [was: Re: File systems...]
Hi Janne, Janne Johansson wrote on Thu, Jan 09, 2020 at 09:49:43AM +0100: > Den tors 9 jan. 2020 kl 02:11 skrev Ingo Schwarze : >> 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. > And here I thought you would post thib@s talk literally named > "Things that makes Bob scream" from the f2k9/Slackathon conf: > > https://www.youtube.com/watch?v=HTD9Gow1wTU 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 one. But yeah, that talk certainly relates to the point i was trying to make. Not my area of work really, but as far as i understand, some things mentioned in the talk have changed a lot, while others didn't at all, and Bob certainly still has plenty of opportunity for screaming. Loudly. Even though that talk was certainly hilarious, file systems still aren't a laughing matter. Thanks for the link, Ingo
Re: Awaiting a diff [was: Re: File systems...]
On Thu, Jan 09, 2020 at 12:47:31PM +0300, Consus wrote: > Relax, it was a joke. Whatever, what I wrote wasn't just directed at you. misc@ sucks a lot lately.
Re: Awaiting a diff [was: Re: File systems...]
On 01/08/2020 09:25 PM, Theo de Raadt wrote: > Xiyue Deng 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. > The average user probably knows nothing about the hard work it takes to make an OS. Don't get me wrong, I disagree with BSD on some stances, but I am not the one who has to do the hard work. So there's that...
Re: Awaiting a diff [was: Re: File systems...]
On 10:45 Thu 09 Jan, Stefan Sperling wrote:
> On Thu, Jan 09, 2020 at 11:02:17AM +0300, Consus wrote:
> > On 18:15 Wed 08 Jan, Xiyue Deng 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.
> >
> > They don't remember as there is no bugtracker.
>
> When people report actual bugs, they get fixed so fast that tracking
> them over days or weeks would be pointless.
>
> """
> We thank Theo de Raadt and the OpenBSD developers for their incredibly
> quick response: they published patches for these vulnerabilities less
> than 40 hours after our initial contact.
> """ -- Qualys
>
> Any non-critical stuff which gets reported ("my printer/wifi/usb doesn't
> work",
> "kernel does not boot on my new laptop", "my system works but is slow") just
> lands in an endless pile of problems that someone might eventually decide to
> work on if they run into it again. Such issues happen over and over again,
> all the time. Any developer picking them up ASAP over and over would burn out,
> just like they do in companies with issue-tracker driven workflows. That's why
> people demanding loudly to get such issues fixed are told to shut up.
>
> And keep in mind that at any given moment there are only about 50 to 100
> people doing actual work here. The rest of the world is busy elsewhere or
> slacking.
Relax, it was a joke.
Re: Awaiting a diff [was: Re: File systems...]
On Thu, Jan 09, 2020 at 11:02:17AM +0300, Consus wrote:
> On 18:15 Wed 08 Jan, Xiyue Deng 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.
>
> They don't remember as there is no bugtracker.
When people report actual bugs, they get fixed so fast that tracking
them over days or weeks would be pointless.
"""
We thank Theo de Raadt and the OpenBSD developers for their incredibly
quick response: they published patches for these vulnerabilities less
than 40 hours after our initial contact.
""" -- Qualys
Any non-critical stuff which gets reported ("my printer/wifi/usb doesn't work",
"kernel does not boot on my new laptop", "my system works but is slow") just
lands in an endless pile of problems that someone might eventually decide to
work on if they run into it again. Such issues happen over and over again,
all the time. Any developer picking them up ASAP over and over would burn out,
just like they do in companies with issue-tracker driven workflows. That's why
people demanding loudly to get such issues fixed are told to shut up.
And keep in mind that at any given moment there are only about 50 to 100
people doing actual work here. The rest of the world is busy elsewhere or
slacking.
Re: Awaiting a diff [was: Re: File systems...]
Den tors 9 jan. 2020 kl 02:11 skrev Ingo Schwarze : > > 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. > And here I thought you would post thib@s talk literally named "Things that makes Bob scream" from the f2k9/Slackathon conf: https://www.youtube.com/watch?v=HTD9Gow1wTU -- May the most significant bit of your life be positive.
Re: Awaiting a diff [was: Re: File systems...]
On 18:15 Wed 08 Jan, Xiyue Deng 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. They don't remember as there is no bugtracker.
Re: Awaiting a diff [was: Re: File systems...]
gwes writes: > Suggestion: to improve file system performance, > first document the bad behavior in detail. > > Begin with examples of traces/logs of disk accesses associated > with file system operations. > > Include scenarios (one hopes reproducible ones) to provoke > bad behavior. > > Are reads worse than writes? Sequential vs. random? > Interleaved r/w on one file? On more than one file simultaneously? > > Examples from other O/S which are better or worse? > > Without this very detailed data it's all noise. > > Being able to get good traces & correlate them with OS activity > shows at least some competence dealing with OS internals. > > geoff steckel Thanks Geoff! I was looking for this kind of guide so that I can do something not noisy. signature.asc Description: PGP signature
Re: Awaiting a diff [was: Re: File systems...]
Suggestion: to improve file system performance, first document the bad behavior in detail. Begin with examples of traces/logs of disk accesses associated with file system operations. Include scenarios (one hopes reproducible ones) to provoke bad behavior. Are reads worse than writes? Sequential vs. random? Interleaved r/w on one file? On more than one file simultaneously? Examples from other O/S which are better or worse? Without this very detailed data it's all noise. Being able to get good traces & correlate them with OS activity shows at least some competence dealing with OS internals. geoff steckel
Re: Awaiting a diff [was: Re: File systems...]
"Theo de Raadt" writes: > Xiyue Deng wrote: > >> Ingo Schwarze writes: >> >> > 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 >> >> 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. > > We (the project developers) did not provide that answer. One of you > typical "posers" suggested it. > >> Then some other guy offers a proposal to start working on >> it, > > Wow. He did not offer to start anything like that. Maybe he'll create > a wiki, or write some words on a mailing list? > >> and the answer now becomes you are hardly qualified for such kind of >> work. > > I suspect you are also unqualified. I am, which is why I didn't propose anything yet. > >> 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. > > Cut the crap. Those of you posting in this thread are only capable of > writing words of text to a mailing list. I was hoping that Stuart's email was the a new start aside from that troll thread. But well. signature.asc Description: PGP signature
Re: Awaiting a diff [was: Re: File systems...]
On 9/1/20 12:20 pm, Theo de Raadt wrote: >> and the answer now becomes you are hardly qualified for such kind of >> work. > I suspect you are also unqualified. > You don't become qualified by writing words on a mailing list… and while I acknowledge a lack of experience in the area, I do understand the risks involved and I am willing to give it a try. ffs is not going anywhere any time soon. Contrary to recently-expressed opinion, I have done kernel-level and bare-metal coding before. OpenBSD isn't the only OS kernel in existence. Those interested in helping out: contact me off list, there is little to be gained by discussing it here. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Awaiting a diff [was: Re: File systems...]
Xiyue Deng 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.
Re: Awaiting a diff [was: Re: File systems...]
Xiyue Deng wrote: > Ingo Schwarze writes: > > > 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 > > 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. We (the project developers) did not provide that answer. One of you typical "posers" suggested it. > Then some other guy offers a proposal to start working on > it, Wow. He did not offer to start anything like that. Maybe he'll create a wiki, or write some words on a mailing list? > and the answer now becomes you are hardly qualified for such kind of > work. I suspect you are also unqualified. > 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. Cut the crap. Those of you posting in this thread are only capable of writing words of text to a mailing list.
Re: Awaiting a diff [was: Re: File systems...]
Ingo Schwarze writes: > 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 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. signature.asc Description: PGP signature
Re: Awaiting a diff [was: Re: File systems...]
Ingo Schwarze wrote: > 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? Ingo, you know that's impossible. These are people on misc, their self-importance and optimism knows no bounds.
Re: Awaiting a diff [was: Re: File systems...]
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
Re: Awaiting a diff [was: Re: File systems...]
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.
