Re: OpenBSD's extremely poor network/disk performance?
On Wed, 8 Jan 2020 17:57:37 +0300 Hamd wrote: > 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. Just speaking anecdotally for myself: I've never noticed especially slow disk performance with OpenBSD. If OpenBSD's disk performance really is 5 or 10 times slower than Linux, perhaps in most situations disk caching makes the difference negligible. If you really want to see an OS with slow disks that dramatically slow down the whole system, get yourself a copy of OpenSolaris and load it on a PC. Very nice, very stable, but everything takes 4 times as long. SteveT Steve Litt January 2020 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust
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.
Re: Iked dead-peer-detection and DynDNS
On Thu, Jan 9, 2020 at 9:09 AM List wrote: > > Hi, > I am using Iked to tunnel to my home router from an openbsd machine. > Everything works fine that far. Problems occur when my router reboots at > night and gets a new IP assigned. (DSL) > Afer receiving the new IP the tunnel is not rebuilt. Because the active > part doesn't recognize that the IP has changed. > How do you guys handle that ? Is there a builtin mechanism? > I've got the impression that once iked startup it reads the hostname of the > destination server > (FQDN && DynDNS) and saves that permanently and doesn't recheck untils > it is manually killed and restarted. > > And is second part of the problem. Is there a way to do > Dead-peer-detection as part of ikeds builtin mechanism? > > How do you guys handle all of that ? > > Enlighten me ! > > > I'd greatly appreciate any help ! > > Best regards, > Stephan > Maybe try using ifstated(8) to ping a host on your home network and restart iked to re-establish the tunnel when the tunnel falls over. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Iked dead-peer-detection and DynDNS
Hi, I am using Iked to tunnel to my home router from an openbsd machine. Everything works fine that far. Problems occur when my router reboots at night and gets a new IP assigned. (DSL) Afer receiving the new IP the tunnel is not rebuilt. Because the active part doesn't recognize that the IP has changed. How do you guys handle that ? Is there a builtin mechanism? I've got the impression that once iked startup it reads the hostname of the destination server (FQDN && DynDNS) and saves that permanently and doesn't recheck untils it is manually killed and restarted. And is second part of the problem. Is there a way to do Dead-peer-detection as part of ikeds builtin mechanism? How do you guys handle all of that ? Enlighten me ! I'd greatly appreciate any help ! Best regards, Stephan
Re: Leaving OpenBSD (with patch)
On Thu, Jan 9, 2020 at 3:54 AM Roderick wrote: > > > Theo, please, give him the travel blessing, before departure. > > Rod. > > > On Wed, 8 Jan 2020, cho...@jtan.com wrote: > > > Some people have needs that OpenBSD doesn't meet. Of course the > > logical thing to do is to adapt it to meet them or to use something > > which does but to some -- in line with the general complexication > > that's progressing nowadays -- this simple solution is not enough > > and the need to announce one's inadequacy to the world in passive > > aggressive tones arises. > > > > Indeed this happens so commonly that it has become something on the > > order of a FAQ, and in order not to have to eat my own words from > > the other day I've spent actual time in the other text editor doing > > some actual hacking (I know, right?!?) and include this diff for > > the developers' consideration. > > > > I have taken the liberty of assuming you want to be at least > > moderately polite as you tell people to kindly fuck off. My apologies > > if that's an oversight; I can re-do it if you wish. > > > > Matthew > > > > > > cvs diff: Diffing . > > Index: faq1.html > > === > > RCS file: /home/flask/src/openbsd/cvsync/www/faq/faq1.html,v > > retrieving revision 1.238 > > diff -u -p -r1.238 faq1.html > > --- faq1.html 2 Oct 2019 15:40:06 - 1.238 > > +++ faq1.html 8 Jan 2020 16:12:30 - > > [SNIP] > > > > > I'd probably add a note to say something along the lines of "this isn't the airport, no need to announce your departure". Though the Venn diagram of "people who loudly leave an open source project's mailing list because said project didn't do 'X'" and "people who don't RTFM" is probably a circle... -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]
Hi Karel, Thanks, for the correction... I thought zfs was bigger than that ;) Thanks On Wednesday, 8 January 2020, Karel Gardas 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=110806948606417=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.
Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]
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=110806948606417=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.
Re: OpenBSD's extremely poor network/disk performance?
Sent: Tuesday, January 07, 2020 at 7:35 AM From: "Hamd" To: misc@openbsd.org 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=8-linux-bsd=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-- MachineSize 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 315ms1024ms 58491us 76221us4459ms 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 clee...@leo.cats.domain:/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: 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
Re: Thinking of changing DNS Service provider, looking for recommendations
I've used Hurricane Electric's free DNS service for years now along with their Tunnelbroker since my ISP still does not support IPv6 yet. They also support dynamic updates which works with "ddclient" from the OpenBSD package repo. https://dns.he.net/ On Thu, Jan 2, 2020 at 8:25 AM Jay Hart wrote: > Hey all, and Happy New Years!!! > > I am currently using DYN.COM for DNS service. A few months back they > changed there payment > methodology and I am now considering finding another solution. DYN charges > me $5 US monthly so its > not a huge financial burden. That said, if I could find a free service > provider, all the better. > > My only real requirement is they must be able to support OpenBSD based > system. Currently using > DDclient. It works fine, has been for years. > > This would be for a residential connection. > > Guess what I'm really looking for, from the list, is a OpenBSD friendly > provider, and a brief > write up on how you are connected. I've looked over a few sites but > nothing stood out as being > OpenBSD friendly. > > Thanks in Advance, > > Jay > >
Re: Leaving OpenBSD (with patch)
Theo, please, give him the travel blessing, before departure. Rod. On Wed, 8 Jan 2020, cho...@jtan.com wrote: > Some people have needs that OpenBSD doesn't meet. Of course the > logical thing to do is to adapt it to meet them or to use something > which does but to some -- in line with the general complexication > that's progressing nowadays -- this simple solution is not enough > and the need to announce one's inadequacy to the world in passive > aggressive tones arises. > > Indeed this happens so commonly that it has become something on the > order of a FAQ, and in order not to have to eat my own words from > the other day I've spent actual time in the other text editor doing > some actual hacking (I know, right?!?) and include this diff for > the developers' consideration. > > I have taken the liberty of assuming you want to be at least > moderately polite as you tell people to kindly fuck off. My apologies > if that's an oversight; I can re-do it if you wish. > > Matthew > > > cvs diff: Diffing . > Index: faq1.html > === > RCS file: /home/flask/src/openbsd/cvsync/www/faq/faq1.html,v > retrieving revision 1.238 > diff -u -p -r1.238 faq1.html > --- faq1.html 2 Oct 2019 15:40:06 - 1.238 > +++ faq1.html 8 Jan 2020 16:12:30 - > @@ -29,6 +29,7 @@ FAQ - Introduction to OpenBSD >Migrating to OpenBSD >Reporting Bugs >Supporting the Project > + Flouncing Out > > > > @@ -415,3 +416,46 @@ contribute. >If you're a student, talk to your professors about using OpenBSD as a >learning tool for Computer Science or Engineering courses. > > + > +Flouncing Out > + > + > +If the bug or other general but il-described annoyance you've recently > +encountered has not been immediately fixed by the volunteers who > +create OpenBSD and provide it for free and at their own expense for > +your personal and frequently unthanked benefit, you may feel that > +simply leaving quietly and using whatever system you wish because it's > +not as if anyone even wants to stop you is not enough. In > +that case you can post a goodbye message to one or more mailing lists > +expressing your feelings in a last-ditch passive aggressive attempt to > +make developers, by-standers and the peanut gallery such as your's > +truly feel sorry for your self-imposed plight or whatever it is you're > +after (nb. although cross-posting is usually considered bad > +netiquette, a blind-eye is turned to it when flouncing out in a huff > + in the case of extreme outrage non-OpenBSD mailing lists may > +be copied in). > + > + > +The most common variants on this theme, which the OpenBSD project > +provides free of charge for you to use or adapt as you wish for this > +or indeed any other purpose, are included here. A popular adaptation > +is to refer to the alternative obliquely with terms such as "the other > +camp" or "the enemy". > + > + > + If OpenBSD won't adopt thing then I will have to > + use alternative instead > + (a popular variants on this reads "won't make thing > + the default"). > + Other people feel the same; I can't put up with it and have to > + use alternative instead. > + It's presumed that the popularity of this variant is the hinted > + suggestion that more users will eventually bugger off and is > + being offered as a good-will gesture a reminder to the > + developers that things will eventually get better. > + I would prefer to use OpenBSD but I can't because reason. > + unsubscribe > + > + > + > +Good-bye. Your help has certainly been appreciated. > >
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
lu hu writes: > So I think ChallengeResponseAuthentication should be set to NO, since > it is not used by anything by default (you need manual steps as root > to use ex.: skey). If you want it set to NO, if you feel safer that way, set it to NO on your systems. IMHO Allan
Leaving OpenBSD (with patch)
Some people have needs that OpenBSD doesn't meet. Of course the logical thing to do is to adapt it to meet them or to use something which does but to some -- in line with the general complexication that's progressing nowadays -- this simple solution is not enough and the need to announce one's inadequacy to the world in passive aggressive tones arises. Indeed this happens so commonly that it has become something on the order of a FAQ, and in order not to have to eat my own words from the other day I've spent actual time in the other text editor doing some actual hacking (I know, right?!?) and include this diff for the developers' consideration. I have taken the liberty of assuming you want to be at least moderately polite as you tell people to kindly fuck off. My apologies if that's an oversight; I can re-do it if you wish. Matthew cvs diff: Diffing . Index: faq1.html === RCS file: /home/flask/src/openbsd/cvsync/www/faq/faq1.html,v retrieving revision 1.238 diff -u -p -r1.238 faq1.html --- faq1.html 2 Oct 2019 15:40:06 - 1.238 +++ faq1.html 8 Jan 2020 16:12:30 - @@ -29,6 +29,7 @@ FAQ - Introduction to OpenBSD Migrating to OpenBSD Reporting Bugs Supporting the Project + Flouncing Out @@ -415,3 +416,46 @@ contribute. If you're a student, talk to your professors about using OpenBSD as a learning tool for Computer Science or Engineering courses. + +Flouncing Out + + +If the bug or other general but il-described annoyance you've recently +encountered has not been immediately fixed by the volunteers who +create OpenBSD and provide it for free and at their own expense for +your personal and frequently unthanked benefit, you may feel that +simply leaving quietly and using whatever system you wish because it's +not as if anyone even wants to stop you is not enough. In +that case you can post a goodbye message to one or more mailing lists +expressing your feelings in a last-ditch passive aggressive attempt to +make developers, by-standers and the peanut gallery such as your's +truly feel sorry for your self-imposed plight or whatever it is you're +after (nb. although cross-posting is usually considered bad +netiquette, a blind-eye is turned to it when flouncing out in a huff + in the case of extreme outrage non-OpenBSD mailing lists may +be copied in). + + +The most common variants on this theme, which the OpenBSD project +provides free of charge for you to use or adapt as you wish for this +or indeed any other purpose, are included here. A popular adaptation +is to refer to the alternative obliquely with terms such as "the other +camp" or "the enemy". + + + If OpenBSD won't adopt thing then I will have to + use alternative instead + (a popular variants on this reads "won't make thing + the default"). + Other people feel the same; I can't put up with it and have to + use alternative instead. + It's presumed that the popularity of this variant is the hinted + suggestion that more users will eventually bugger off and is + being offered as a good-will gesture a reminder to the + developers that things will eventually get better. + I would prefer to use OpenBSD but I can't because reason. + unsubscribe + + + +Good-bye. Your help has certainly been appreciated.
Re: Odd /tmp behavior
Thanks for the input on softdep. I read a lot on the pros and cons. This certainly pushes me in the "con" direction. I forgot to mention that I am using 6.6 stable, not current, so the latest updates to softdep shouldn't be an issue. Dave Raymond On 1/8/20, Jan Stary wrote: > On Jan 08 08:31:26, n...@holland-consulting.net wrote: >> Another place where softdeps will sometimes bite you is when you >> unpack tar balls that overwrite existing files -- simple thought >> process says, "as long as you have enough space to cover the growth, >> fine". Softdeps might surprise you. You may get an "out of disk >> space" error, and a minute later, see much more space than you >> thought you could ever need to accomplish the task, once the deletions >> have time to take effect. > > Another case of the same (imho) > is pkg_add -u when /usr/local is tight. > > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: OpenBSD's extremely poor network/disk performance?
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
Re: Odd /tmp behavior
On 2020-01-08, Nick Holland wrote: > Weird stuff happens when Softdeps are working as designed. To put it simply: Meta-data writes are delayed. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: OpenBSD's extremely poor network/disk performance?
"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 , 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=8-linux-bsd=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. >
Awaiting a diff [was: Re: File systems...]
> - 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.
Re: Why isn't ChallengeResponseAuthentication NO in sshd_config?
Hello, even the very first remote hole for OpenBSD, back in 2002 was about that the: https://web.archive.org/web/20160915002152/http://www.iss.net/threats/advise123.html https://www.cvedetails.com/cve/CVE-2002-0639/ "ChallengeResponseAuthentication" was set to yes.. (it was more, but it would be mitigated with setting to "NO") So I think ChallengeResponseAuthentication should be set to NO, since it is not used by anything by default (you need manual steps as root to use ex.: skey). But please, correct me, I just want to point out an attack surface reduction in OpenSSH + OpenBSD. Many thanks. > Sent: Sunday, December 29, 2019 at 6:07 PM > From: "lu hu" > To: misc@openbsd.org > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > Hello: > > 66# grep -i challenge /etc/ssh/sshd_config > #ChallengeResponseAuthentication yes > 66# sshd -T|grep -i challenge > challengeresponseauthentication yes > 66# > > it doesn't counts if it is commented out, since it is by default YES as I > started the thread with: > > > > > > > # what am I talking about? > > > > > > https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > > > > > ChallengeResponseAuthentication > > > Specifies whether challenge-response authentication is allowed. All > > > authentication styles from login.conf(5) are supported. The default is > > > yes. > > > > anyone in this world that understands what am I trying to point out? :) > > with all the infos so far I have, the "ChallengeResponseAuthentication" > should be by default NO. but it isn't currently. > > maybe someone from the devs? or sorry, am I posting to the wrong list? > > Really Many Thanks. > > Happy New Year! > > > > > Sent: Monday, December 23, 2019 at 1:58 PM > > From: "Jan Betlach" > > To: "lu hu" > > Cc: misc@openbsd.org > > Subject: Re: Why isn't ChallengeResponseAuthentication NO in sshd_config? > > > > > > Isn’t it commented out by default? > > > > Jan > > > > > > > Hello, > > > > > > nobody about the $subject? :) > > > > > > Why isn't ChallengeResponseAuthentication NO in sshd_config by > > > default? > > > > > > It would be more secure, afaik. > > > > > > Many thanks. > > > > > > > > >> Sent: Thursday, December 19, 2019 at 7:58 PM > > >> From: "lu hu" > > >> To: misc@openbsd.org > > >> Subject: Re: Why isn't ChallengeResponseAuthentication NO in > > >> sshd_config? > > >> > > >>> Sent: Wednesday, December 18, 2019 at 9:49 PM > > >>> From: "Bodie" > > >>> To: misc@openbsd.org, owner-m...@openbsd.org > > >>> Subject: Re: Why isn't ChallengeResponseAuthentication NO in > > >>> sshd_config? > > >>> > > >>> > > >>> > > >>> On 18.12.2019 18:48, lu hu wrote: > > Hello, > > > > > > # what am I talking about? > > > > https://man.openbsd.org/sshd_config#ChallengeResponseAuthentication > > > > ChallengeResponseAuthentication > > Specifies whether challenge-response authentication is allowed. > > All > > authentication styles from login.conf(5) are supported. The default > > is > > yes. > > > > > > # what does linux distros use: > > > > If I ex.: read: > > > > https://access.redhat.com/solutions/336773 > > > > then I can see ChallengeResponseAuthentication is NO for security > > reasons. Ubuntu too. > > > > > > # what else says ChallengeResponseAuthentication should be NO? > > > > https://www.openwall.com/lists/oss-security/2019/12/04/5 > > -> > > >>> > > >>> These issues were quickly fixed in OpenBSD as you can see in > > >>> Security > > >>> > > >> > > >> This isn't related to the subject. > > >> > > >>> > > 1. CVE-2019-19521: Authentication bypass > > > > this attack should be more mitigated if > > ChallengeResponseAuthentication would be by default set to NO. > > > > > > # FIX: > > > > from this: > > cat /etc/ssh/sshd_config > > ... > > # Change to no to disable s/key passwords > > #ChallengeResponseAuthentication yes > > ... > > > > to this: > > vi /etc/ssh/sshd_config > > cat /etc/ssh/sshd_config > > ... > > # Change to no to disable s/key passwords > > ChallengeResponseAuthentication no > > ... > > > > But of course by default, without fixing sshd_config it should be > > NO. > > > > Who the hell uses s/key with sshd nowadays? > > > > >>> > > >>> And you are aware that this option is not there just for S/Key, > > >>> right? > > >>> It's for example PAM Google authenticator too on Linux and > > >>> others > > >>> > > >>> I think you missed couple of points. Eg.: > > >>> > > >>> https://www.openbsd.org/faq/faq10.html#SKey > >
Re: Odd /tmp behavior
On Jan 08 08:31:26, n...@holland-consulting.net wrote: > Another place where softdeps will sometimes bite you is when you > unpack tar balls that overwrite existing files -- simple thought > process says, "as long as you have enough space to cover the growth, > fine". Softdeps might surprise you. You may get an "out of disk > space" error, and a minute later, see much more space than you > thought you could ever need to accomplish the task, once the deletions > have time to take effect. Another case of the same (imho) is pkg_add -u when /usr/local is tight.
Re: Odd /tmp behavior
On 2020-01-07 14:06, Karel Gardas wrote: > > > On 1/7/20 7:38 PM, Jordan Geoghegan wrote: >> > Using softdep on /tmp is a silly idea. > > Why? To naive eyes it may look like a natural solution: e.g. before temp > file is even created (on drive), it may be deleted which means there is > no meta-data change hence speedup of operation on /tmp. In case of > classical ffs, you will need to create file (sync meta-data update), > save some data (async), delete file (sync meta-data update). But > honestly still need to read the code... > I'm not going to go nearly as far as to say it's a silly idea (as I do it myself) but ... be aware softdep is funky. Weird stuff happens when Softdeps are working as designed. When you do things out of order, things happen...well, out of order. So ... create file delete file create file delete file create file delete file create file delete file create file delete file sounds perfectly safe, as long as "file" is smaller than available disk space, right? Softdeps...no so much. This can actually result in running out of disk space, as the deletes may not happen until after the creates. Another place where softdeps will sometimes bite you is when you unpack tar balls that overwrite existing files -- simple thought process says, "as long as you have enough space to cover the growth, fine". Softdeps might surprise you. You may get an "out of disk space" error, and a minute later, see much more space than you thought you could ever need to accomplish the task, once the deletions have time to take effect. So ... make sure you have lots of extra disk space...if things are snug, it's a bad place to use softdeps. Nick.
Re: Boot fail using internal SATA port, success using USB port.
On 2020-01-07 15:16, Nick Holland wrote: hardware: DELL Latitude e5440 Pretty sure I've tested one of those, they work. As I recall, the E5440 is a few years old, and if I recall properly, the battery wasn't very long-lived in it. And the Dells of that vintage had a really wacked default -- someone decided it would be best to default to "RAID" for disk mode. Yes, on a one drive laptop. For safety reasons, OpenBSD (and many other non-windows OSs) disable disk access if the disk controller is in RAID mode rather than ACHI or "legacy" mode. Even on AHCI, same happens. So ... is it possible the CMOS battery is bad on your machine? This would explain a "Power up, set up machine, install, reboot -- ok". "power off, power back on later, won't successfully boot" (the kernel would load, but be unable to access the disks and then panic). I'm not convinced this is the problem, but might be. No it does not reboot successfully, not even once. On the E5540 it goes like this: -power-up. -setup & install. -after done install prompts to [reboot]. -it reboots and "bricks"(i never get to see OpenBSD booting). -OpenBSD boots only through USB port. I have screwed and unscrewed about 30 times to try to get it to boot from the internal port but nothing worked. I have settled with another laptop instead until I familiarize with BSD and see where that takes me.
Re: File systems [was Re: OpenBSD's extremely poor network/disk performance?]
Howdy Stuart, On Wed, 8 Jan 2020 at 11:17, Stuart Longland 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.
Re: possible SSH algorithm issues?
On 2020-01-08, "lu hu" wrote: > are these real issues? No. -- Christian "naddy" Weisgerber na...@mips.inka.de
File systems [was Re: OpenBSD's extremely poor network/disk performance?]
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.
usb disk panic on ALIX.1E
This is 6.6-current on an ALIX (dmesg below), serving as my home server.
It's where I store the daily.local dumps, into /backup on a big USB disk.
The machine often crashes into a ddb when saving those dumps.
I only have lame screenshots now (will plug a cereal in):
http://stare.cz/dmesg/alix1e.20191128-panic-trace.jpg
http://stare.cz/dmesg/alix1e.20191128-panic-ps1.jpg
http://stare.cz/dmesg/alix1e.20191128-panic-ps2.jpg
http://stare.cz/dmesg/alix1e.20191128-panic-ps3.jpg
http://stare.cz/dmesg/alix1e.20191128-panic-ps4.jpg
http://stare.cz/dmesg/alix1e.20191128-panic-uvm.jpg
http://stare.cz/dmesg/alix1e.20191128-panic-bcstats.jpg
It always happens during the nightly heavy writes.
The machine itself is dumping local fs's into /backup,
and a few other machines rsync their dumps into there.
All of that is run from daily.local (on each of the machines).
These crashes have become less frequent
since I disabled softdep on the fs.
$ cat /etc/fstab
bf940e6c7aaf2c50.a / ffs rw 1 1
bf940e6c7aaf2c50.d /usrffs rw,nodev,noatime 1 2
bf940e6c7aaf2c50.e /usr/local ffs rw,nodev,noatime,wxallowed 1 2
bf940e6c7aaf2c50.f /varffs rw,nodev,noatime,nosuid1 2
bf940e6c7aaf2c50.g /var/logffs rw,nodev,noatime,nosuid1 2
bf940e6c7aaf2c50.h /var/wwwffs rw,nodev,noatime,nosuid1 2
bf940e6c7aaf2c50.i /var/mail ffs rw,nodev,noatime,nosuid1 2
bf940e6c7aaf2c50.j /var/postgresql ffs rw,nodev,noatime,nosuid1 2
bf940e6c7aaf2c50.k /tmpffs rw,nodev,noatime,nosuid1 2
bf940e6c7aaf2c50.l /home ffs rw,nodev,noatime,nosuid1 2
31efc37173c4c30f.a /backup ffs rw,nodev,noatime,nosuid
$ mount -v
/dev/wd0a (bf940e6c7aaf2c50.a) on / type ffs (rw, local, ctime=Wed Jan 8
07:43:39 2020)
/dev/wd0d (bf940e6c7aaf2c50.d) on /usr type ffs (rw, local, noatime, nodev,
ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0e (bf940e6c7aaf2c50.e) on /usr/local type ffs (rw, local, noatime,
nodev, wxallowed, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0f (bf940e6c7aaf2c50.f) on /var type ffs (rw, local, noatime, nodev,
nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0g (bf940e6c7aaf2c50.g) on /var/log type ffs (rw, local, noatime, nodev,
nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0h (bf940e6c7aaf2c50.h) on /var/www type ffs (rw, local, noatime, nodev,
nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0i (bf940e6c7aaf2c50.i) on /var/mail type ffs (rw, local, noatime,
nodev, nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0j (bf940e6c7aaf2c50.j) on /var/postgresql type ffs (rw, local, noatime,
nodev, nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0k (bf940e6c7aaf2c50.k) on /tmp type ffs (rw, local, noatime, nodev,
nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/wd0l (bf940e6c7aaf2c50.l) on /home type ffs (rw, local, noatime, nodev,
nosuid, ctime=Wed Jan 8 07:43:29 2020)
/dev/sd0a (31efc37173c4c30f.a) on /backup type ffs (rw, local, noatime, nodev,
nosuid, ctime=Wed Jan 8 08:23:32 2020)
Is it the disk? I did a complete dd read and a complete dd write
before I put it to use, and it didn't show any problem. No signs
of failed io in messages either.
Is it the USB cable? I replaced it a couple of times.
Is it the USB interface on the ALIX?
Is it the small amount of memory? I tried using openrsync,
which would fail on malloc (it mmaps the files).
Could it be the rsync over ssh? (I will try to run just
local backup for some time, without rsyncing the others).
How can I debug this further?
Jan
$ dmesg
OpenBSD 6.6-current (GENERIC) #404: Thu Nov 28 12:47:25 MST 2019
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
real mem = 259207168 (247MB)
avail mem = 238825472 (227MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 07/19/10, BIOS32 rev. 0 @ 0xfa950
apm0 at bios0: Power Management spec V1.2 (slowidle)
pcibios0 at bios0: rev 2.1 @ 0xf/0xdfb4
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/128 (6 entries)
pcibios0: PCI Exclusive IRQs: 5 10 11
pcibios0: no compatible PCI ICU found: ICU vendor 0x1022 product 0x2090
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0xa800 0xef000/0x1000!
cpu0 at mainbus0: (uniprocessor)
cpu0: Geode(TM) Integrated Processor by AMD PCS ("AuthenticAMD" 586-class) 499
MHz, 05-0a-02
cpu0: FPU,DE,PSE,TSC,MSR,CX8,SEP,PGE,CMOV,CFLUSH,MMX,MMXX,3DNOW2,3DNOW
mtrr: K6-family MTRR support (2 registers)
amdmsr0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 1 function 0 "AMD Geode LX" rev 0x33
vga1 at pci0 dev 1 function 1 "AMD Geode LX Video" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
glxsb0 at pci0 dev 1 function 2 "AMD Geode LX Crypto" rev 0x00: RNG AES
vr0 at pci0 dev 13 function 0 "VIA VT6105M RhineIII" rev 0x96: irq 11, address
OpenSSH ignoring login.conf and ypbind (LDAP) config.
I'm trying to log into my OpenBSD server with an LDAP user and it's not working: Jan 8 10:41:57 aagico-postgres-nextcloud sshd[15381]: Failed password for dcorbe from 73.57.99.182 port 45222 ssh2 Although login.conf is configured properly: # /usr/libexec/auth/login_-ldap -d -s login dcorbe ldap Password: ... authorize And so is ypbind: aagico-postgres-nextcloud# getent group | grep dcorbe _dcorbe:*:2001:dcorbe aagico-postgres-nextcloud# getent passwd | grep dcorbe dcorbe:*:2001:2001:Daniel Corbe:/home/dcorbe:/bin/sh What do I need to change about OpenSSH to get this working?
possible SSH algorithm issues?
Hello, used https://www.sshaudit.com/ + ssh-audit package ### by default OpenBSD 6.6 ssh client (SSH-2.0-OpenSSH_8.1) has issues: Host Key Types: nistp should be removed Key Exchange Algorithms: nistp should be removed, also diffie-hellman-group14-sha1: SHA-1 has exploitable weaknesses. Message Authentication Codes: umac-64-...@openssh.com MAC uses small tag size. + hmac-sha1-...@openssh.com SHA-1 has exploitable weaknesses. + umac...@openssh.com MAC uses small tag size. + hmac-sha1 SHA-1 has exploitable weaknesses. ### by default OpenBSD 6.6 sshd server (SSH-2.0-OpenSSH_8.1) has issues: # key exchange algorithms (kex) ecdh-sha2-nistp256-- [fail] using weak elliptic curves (kex) ecdh-sha2-nistp384-- [fail] using weak elliptic curves (kex) ecdh-sha2-nistp521-- [fail] using weak elliptic curves # host-key algorithms (key) ecdsa-sha2-nistp256 -- [fail] using weak elliptic curves ### are these real issues? nistp + weak macs. that are advised to be removed by ssh-audit? Googled misc archives, didn't found any discussion about these! (yet) Many thanks.
Re: ifconfig behavior
On Tue, Jan 07, 2020 at 10:19:36PM +, Pedro Caetano wrote: > Hi misc@ happy new year! > > While running snapshot #584 on amd64 I noticed setting addresses using > ifconfig is not consistent for ipv4 and ipv6. > > Is this expected behavior? I wasn't able to find anything in the FAQ. > It has been like that for ages and, for me, it is expected.
