Hurray. I now have something you might almost call fast internet to my home - and hence to this server...
Thanks to eXeTeL.com.au and Optus I now have ADSL2. It seems to be about 4Mbit/sec downstream and 800Kbit/sec down, but that is a lot better than 1500/256!
So you might find this site slightly faster now... for those who look.
The change over took about 2 days :-( So if you thought my site was down for a long time, you were right!!
Back now.
A couple of people actually left comments (woo-hoo!!).
This helped me see a number of problems with the comment feature.
So I've fixed some things.
I still need to record and display the date/time when the comment was made, and maybe even make an 'atom' feed of comments....
I love todo-lists. They are liberating. If you don't know what to work on next, you write a TODO list. Then you just work through the things on the list. Or maybe you don't, but having written them all down, they no longer rattle around in your brain and distract you from more important things.
Anyway, to the point. Someone recently asked me what my priorities for the Linux NFS server were and while I'm not spending a lot of time on it at the moment, there are things that I would like to see done, so I wrote a little todo list. And having written it, I might as well share it. So here it is...
BULLET - auto-adjust the number of nfsd threads. I'd really like the sysadmin not to have to choose a number, but it should still be possible to set a maximum. I imagine: BULLET - slow growth when there is high load and we have never had this many running before BULLET - slow decay in numbers when <50% are in use fast growth when we have dropped below the highwater mark and load is high BULLET - A maximum that is somehow based on the requested number of threads BULLET - Some way of measuring if extra threads in actually improving throughput, and feed that in to the growth calculations.
BULLET - Find a way to overcome the current bottle neck when replying to requests on a udp socket.
BULLET - explore whether it would help to make the scheduling of nfsd threads more SMP (and NUMA) aware.
BULLET - Finalise and implement upcall changes to support new NFSv4 features like auth-type selection and fs_locations
BULLET - make exporting of filesystem via NFSv4 work more smoothly (mountd should automatically create the 'virtual filesystem' thing).
As I progress in winding up my position at the Computing Support Group at cse.unsw I'm looking for programs that I wrote which might be more widely useful and trying to make them available to the open source community.
One such is 'metad' which you can find in my git repository at git://neil.brown.name/metad or http://neil.brown.name/git/?p=metad.
metad is a daemon for managing other daemons. It is a bit like inetd in that it starts programs and waits for them to complete. However it isn't just starting programs based on network activity - that is possible, but was a later addition.
The main purpose is to run all other little daemons one seems to need and to allow those daemons to be stopped and started remotely. It may not be very interesting on a single-user machine, but it is wonderful when administering a network
So, Christian: You think you would like to be able to "Speak in tongues"?
Let me suggest a good tongue to start with.
They say "Money speaks all languages" so if you speak with money, you can speak in all tongues.
I encourage you then to speak your worship of God with the language of Money. Give, as Christ has given so much to you.
Then your 'speaking in tongues' will truely be a blessing to many (including yourself) and will be glofirfying to God.
Ever since I moved this blog and the nearby git repos to my home network I have had weird intermittent network problems. I worked just enough for me to convince myself that it seemed to be working, but not enough for people to have convenient access from outside.
After fiddle with cables a bit with no real success I did some more systematic testing and discovered that the wired ports on my Netcomm wireless/ADSL modem were just not doing the right thing.
So I decided it was time for an upgrade. Not only would it then work immediately, but I could have VOIP integrated into the same box (instead of separate) and be ready for ADSL2 - if that ever gets to the 'lucky country' (well... a few exchanges have it, but not many).
A few hundred dollars for an NB9W and a couple of hours later it all works again nicely. The VOIP QoS applied to all my traffic without esoteric routing being required, and my webside gives a consistent 20KB/sec to the world. Now I just have to tidy up the wires before someone trips over...
I've been preaching a very occasional series at church based on 1 Samuel, and I'm coming to the end. Not the end of the book, but the end of the life of Samuel, and I feel it is a good time to take a break from that book. It's been fun but I think it is time to move on.
Anyway, the final sermon will start from I Samuel 16:1-13 where Samuel anoints David to be the next King of Israel, and God tell him (Samuel)
"Do not consider his appearance or his height, for I have rejected him. The LORD does not look at the things man looks at. Man looks at the outward appearance, but the LORD looks at the heart"
The question I want to answer is "When He looked at David's heart, what did the LORD see?".
I have just released mdadm 2.5. It is available from kernel.org and freshmeat knows about it.
It had originally expected this to be a fairly small update of assorted bug fixes. But when it came to putting it together, there turned out to be quite a lot of enhancements.
One - the major one - is the auto-assembly that I mentioned in an earlier past. Others were due to the fact that the maintainer of the Debian package took decided at the same time that it was time to sort through bug reports and forward some to me. Still others were just normal stuff on the linux-raid list.
All it all there is a reasonable amount of stuff in there. Hopefully it will get some testing, and even better: will get some feed back. The only way to make it the best is for people to tell me what is wrong with it.
Thanks to a slightly off-topic discussion on linux-kernel@vger.kernel.org, I recently discovered MozEx: http://mozex.mozdev.org/.
This is a very cool extension to firefox and friends.
In particular, I can tell it to use my favourite editor (emacs in my case) to edit the content of a text-area.
That means that instead of having to use the text editor that is built in to firefox (which is fairly lame) to edit my blog entries, I can use emacs, and get all it's nice features like flyspell etc.
I haven't tried it extensively yet, and have only just hacked emacsclient to open files in new frames (as my emacs is usually in a different workspace when I am using firefox) but I am using it for this blog entry, and it seems to work just fine.
Probably the most wanted feature of mdadm is auto-assembly. People want it to just do-the-right-thing. They want to simply be able to assemble all of their arrays without having to worry about creating and maintaining config files or anything like that.
I've always been against blind auto-assembly as it can (and occasionally has) cause problems when the wrong thing gets assembled.
However it is possible to find a middle ground, that isn't completely blind, but that requires minimal configuration effort. I've finally figured out how I want to implement that and scheduled the time to do it, and so it should appear in mdadm-2.5.
The core idea is to report the host name of each raid array. mdadm can then assemble every array that it can find, providing it is for 'this' host.