/dev/dump

[ Recently, Alasdair Lumsden announced his retirement as leader of the OpenIndiana community.  This is a copy of my response to that. ] Dear Alasdair, Here at the illumos Foundation, we are very sad to hear of your resignation as lead of the OpenIndiana distribution. You have demonstrated great leadership and have been a wonderful friend of the community. We understand that such projects can be very time consuming, and we wish you all the best in your other endeavors.  As a community, many of us share some of your frustrations. At times, progress does appear to be slow. At other times, there may appear to be a lack of interest from many of the former Sun employees. However, although you may feel that there is a lack of support or interest, many of us active in the community feel differently. While OpenIndiana served to carry on the banner of the OpenSolaris distribution, it was obviously a dead end because the desktop wars are over, and even the Linux co...

So, there has been some that have argued vehemently against the advertising policies of GoDaddy , and its ilk.  (See https://twitter.com/bdha/status/211210555577466881 for example of the complaints.) I have a different point of view.  What about sites that always picture a beautiful woman on a headset for their representation of tech support?  Should we also boycott them?  Would you prefer a site with an ugly  person answering the phone?  After all, it's a phone or text chat, so it shouldn't matter at all what the person looks like, right? Conversely, what about all the sites that use men  in their advertising? My hosting provider, bluehost.com , uses both .  Take a look .  Does the pretty blonde in glasses have anything to do with domain names or web hosting?  Of course not.  The guy wearing the headset for the tech support line isn't exactly hideous either, if you swing that way.  Are you likely to talk to this gu...

So, if you're like me, and you've been shopping for a new system lately because you're last one is dying or dead, you might see some fancy looking Intel E3-1200v2 Xeon systems.  (Why Xeon?  Because ECC memory is a good  thing.  I attribute some of my difficulty with my last system to using non-ECC memory.  Because its not ECC, I don't really know  whether the problem was in RAM or CPU, but I digress...) Great, so you pick out a E3-1240v2 Ivy Bridge CPU, and then you look for a System Board. I found the Supermicro X9SCA-F-O.  Looks like a sweet board.  The spec claims support for the E3-1200v2 cpus, and 1600MHz RAM.  It has a separate IPMI LAN support, as well.  Sweet!  (Look closer though....) So, package arrives from NewEgg, and you're ready to go. Assemble the kit.... if you're a software guy like me this might take a couple of hours. Power it on. Beep!  Beep!  Beep!  Beep! WTF does that mean!?  ...

So, I've been trying to setup a system that can build illumos-gate.  Because my old system had a memory DIMM fault, and isn't usable anymore. I thought, hmm... let me try something other  than OpenIndiana. Big mistake. Only OpenIndiana seems able to build vanilla illumos-gate right now. Why?  Because of external dependencies!   I tried building on OmniOS.  The stopper there -- Python 2.4!  On SmartOS, the dependency is IPS itself.  It seems only OpenIndiana is suitable for building stock illumos-gate. The problem is that our build is inherently very sensitive to the build environment.  It makes life incredibly unpleasant if you try to build on any system that is not configured exactly  as we specified. This, IMO, is an unacceptable situation. I will speak loudly against any  attempt to make changes that introduce further external dependencies.  The fact that some already exist is no excuse.  Every external depend...

Yesterday we had our first ever illumos hack-a-thon. About a dozen people from the community showed up, and worked on some very very cool things. At the end of the day, about a half-dozen different demos were done, to show what was worked on. We'll be posting photos shortly. But here are some of the projects that got attention: tab completion for dcmds and data types in mdb ::print for DTrace expanded truss support for ZFS ioctls (nvlist expansion) time-ordered output for DTrace a comment field in the vdev label for ZFS pool devices the ability to change the GUID of a ZFS pool Several other projects were in progress. We selected these projects out of a much larger list of project proposals (which I'll post soon), based on the what people thought was most useful, and the ability to achieve results in a single day hack-a-thon. (And what people we willing to either work on, or mentor.) Most importantly, people got to work on areas that they weren't intimately familiar wi...

After a lon g, and arduous, release cycle, I am pleased to report that NexentaStor 3.1 is available now . Customers running existing 3.0 installations may upgrade at no cost. This release includes a number of key features, including some significant improvements for performance and manageability. Folks using SCSI target mode will probably see the biggest performance boost relative to earlier editions of NexentaStor, especially those folks using NexentaStor to serve up storage to VMware guests -- thanks to the VAAI offload support that is part of this release. And for the record, yes, this release includes the fix the long standing problem with iSCSI timeouts. For ZFS fans, this release also includes the updates for ZFS version 28. (This does mean that folks upgrading need to be cautious -- their pools will not be automatically updated to ZFS version 28, but if they are manually updated then there will be no way to move those pools back to an older release. That also means that poo...

As part of fixing some recent bugs, I integrated the following into illumos : 734 taskq_dispatch_prealloc() desired 943 zio_interrupt ends up calling taskq_dispatch with TQ_SLEEP The interesting one is the first of these. The interface is actually called taskq_dispatch_ent (), and is private to the "consolidation" (i.e. for use within bundled code only). What this interface provides for, however, is a way to bomb-proof your taskq dispatches, if you can arrange for the dispatching state structure ( taskq_ent_t ) to be allocated in advance. This means you never have to worry about the possibility of a dispatch failing due to insufficient resources. What's even cooler, is that the cost of the dispatching is much cheaper; taskq_dispatch () was the hottest piece of code on a very busy storage server. Now it goes much much faster, because it is just twiddling some linked list pointers and sending a signal to wake up the thread processing the taskq. More impor...