OpenBSD Journal

krw@ adventures at p2k19

Contributed by Peter N. M. Hansteen on from the look at all these scsis dept.

Next up in the series of p2k19 reports is Ken Westerback (krw@), who writes:

tl;dr - Great City, Great Coffee, Great Hacking. I already miss Bucharest.

Lufthansa got me to Frankfurt early, albeit a bit puzzled at their new boarding procedure which had me boarding after a lot of the hoi polloi. After a bit of "gate, gate, who's got the gate?" and a shuttle trip to the other terminal I settled in for a short refresher in the lounge before meeting naddy@ at the gate. stsp@ had not appeared by the time I boarded but apparently showed up as he was on the plane when we arrived at OTP.

After all the luggage was disgorged it turned out the t-shirts had not made the connection and stsp@ had to make a report. The t-shirts were promised for the next day at the hackroom. After a brief examination of the many buttons one could push to summon a taxi, we took the advice naddy@ had found on the web, wandered over to the departures part of the airport and snagged a taxi that had just disgorged a load. Quick trip to the University for less than 40 lei!

The building we landed at said Geography and we knew we were looking for Mathematics, so after consulting stsp@'s phone we set off. In the wrong direction. Came back. Poked at the map, set off in the other wrong direction. Came back, tried again. Came back and just called pirofti@ for help. He kindly arrived, pointed out we were just at the wrong end of the building and herded us to the hackroom. Whew.

Various subtle signs that I had been up for about 36 hours led me to decide to retire and start hacking the next day. I met a roving band of french hackers on the way to the hotel, warned pirofti@ via text and went to sleep hoping the room would survive the invasion.

My p2k19 hacking focused on SCSI and dhclient.

To warm up I committed some SCSI diffs to clean up disk geometry and size calculations.

The real SCSI concerns were driven by robert@'s complaints about poor tape performance. These were not new, but recent success on another tape related matter had led me to revisit our SCSI code and robert@ promised to provide access to an actual tape drive. Unfortunately his supplier managed to twice ship him tape libraries without securing the tape drive therein. Which bounced around a few time in transit and rendered the libraries inoperable. For some reason he did not allow me unrestricted access to his employers' production tape backup server. Weird. So I was forced to feed diffs through him.

As part of the previous tape problem investigation I had put a lot of effort into improving the information provided by a kernel compiled with SCSIDEBUG. So the first request I made of Robert was to do some i/o to the tape drive with a SCSIDEBUG kernel, and send me the resulting output. This immediately showed an oddity. Why were the SDEV_NOWIDE and SDEV_NOSYNC flags being set for his very modern LTO tape device? Investigation showed that 1) these flags were based on SCSI INQUIRY flags that were now obsolete; 2) overly clever code in the device probing process was leaving these flags set when they should have been cleared; and 3) mpi(4) was almost unique in taking these flags seriously. And the tape device was connected to an mpi(4) controller.

A bunch of code shuffling later a diff was passed to Robert for testing. No improvement. Drat. On the other hand sthen@ found that the diff improved his disk performance by about 700% (!!). Committed!

Taking a breather I managed to discover and nuke an unused SCSI file, scsi_scanner.c. Well, patrick@ actually nuked it for me.

The next tilt at the tape windmill was discovering that mpi(4) was incorrectly setting the limit on the number of simultaneous i/o's that could be submitted to a device. Diff … test … no impact. Double Drat. This improvement was later committed after the hackathon.

At this point Robert was inspired to try fiddling with MAXPHYS, the limit on the size of i/o's. Bingo! Bumping this up to larger values led to massive improvements. Unfortunately changing MAXPHYS has major implications. Therefore the correct way to provide larger values to sequential devices is now an active area of investigation with no easy solution in sight.

I then moved on to answer pleas from florian@ for some dhclient(4) enhancements to provide unwind(1) with information. My resulting diff was unfortunately only proof I was not up to speed on unwind, and I went back to the drawing board.

While in dhclient I realized the hackroom network reliably reproduced a problem I had previously only sporadically encountered. When both wireless and wired interfaces were configured, unplugging the wired interface was not switching resolv.conf back to the wireless setup. With a reliable failure I was able to quickly track down the problem and fix it.

This in turn lead to discovering problems in the way dhclient was handling the deletion of existing routes when applying a new lease. I cleaned this up and constrained route deletion to the static routes dhclient adds. I also repaired the comparison of routes provided in a lease and the routes provided from the routing stack. Together these changes fixed some "route contains no arp information" errors that had been reported on bugs@.

The final tweak to dhclient was to reduce resolv.conf churn by not overwriting it when beginning the process to get a new lease or when the AUTOCONF4 flag is cleared.

A final hack was fixing a possible NULL dereference in the routing stack when deleting a route. A problem I discovered by making a typo entering a particular route(4) command.

Unfortunately a tight schedule prevented my usual plan of sticking around for a few days, and in concert with the Bucharest plan of closing many museums on BOTH Mondays and Tuesdays significantly reduced my usual museum bagging. Next time!

The food was excellent. The coffee plentiful and superb. The overall organization was wonderful. Many thanks to the eminent mathematics professor who set it all up, the University of Bucharest for the facilities and the OpenBSD Foundation for funding. I look forward to another visit!


I left Bucharest at 17C, I landed in Montreal at -7C. I had to drink something called Starbucks coffee. My flight to Toronto was delayed by having to run the aircraft through the de-icing station. I missed Bucharest very much.

(Comments are closed)



Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]