LCA 2003
The fourth annual linux conference in Australia (third named linux.conf.au), held in Perth, Western Australia. I gave a paper about a new filesystem that I am building.
Neil @ Home
LCA 2002
The third annual linux conference in Australia, held in Brisbane this year. I gave a paper on Authentication infrastructore for Linux kNFSd
LCA 2001
The first linux.conf.au, a worthy successor to CALU-99, the Confernece of Australia Linux Users in late 1999. Linux.conf.au was held in Sydney at the University of New South Wales, where I work, so I had to go. I even gave a WorkInProgress on Linux Raid development.
Better FSID management
An NFS filehandle stores information to identify a filesystem (or directory in the filesystem that is the export point) and a file within that filesystem.
Identifying the file within the filesystem is now handled fairly well, but there are problems with identifying the filesystem.
Ideas for Aether
I've just installed aether-1.4 for this website and made a few enhancements that I might submit one day.
They include allowing a blog to select entries from another blog based on tags in the [entry] field. Thus my
Also a blog can show just a list of pages (or the summaries there-of), so my
Other changes I am contemplating include:
- Once a password has been typed in, the "Edit" and "New" links at the bottom of the page become simple links that contain the password. This way I only need to type the password once. There would need to be an easy way to forget the password of course
BULLET - Almost all my aether usage is using it as an error document, so the meaningless "me" doesn't appear. But when I edit a page it has to use a real URL, as you cannot post to an error document (I think). The "post" should pass in the preferred prefix so that when I come out of editing, I am back in the error-document space. (Does that make sense to anyone but me).
New "mdadm"
I have just released a new version of mdadm - 1.6.0.
Mdadm is my tool for managing Linux Software RAID arrays.
This release included initial support for a --grow mode that allows resizing on-line arrays. Naturally this requires kernel support to be able to work. The 2.6.7-rc2-mm1 Linux kernel has support for changing the active size of component devices and changing the number of drives in a RAID1.
I hope to add support for adding drives to a linear array soon, and adding drives to a RAID5 eventually.
I had hoped to get support for the new-style superblocks into this release, but it just didn't happen. Maybe next time.
vpatch design notes
In my Linux kernel development work, I often apply patches to files that have changed since the patch was created. Sometimes these patches fail to apply for trivial reasons.
About a year ago I wrote a program called
When I apply a patch that fails, I would like to be able to see exactly why it failed, and what wiggle would do to fix it. But to do that I currently have to grovel around in various files. I would be nice if this was more automatic.
What I am envisaging is a new patch application tool. Let's call it vpatch.
01170844
Beyond Pipes
Pipes are a great tool for connecting programs together. It is a real joy to be able to connected various Unix tools together in a pipeline. One of my favourite is
... | sort | uniq -c | sort -n
to get a frequency count of some collection of lines (often from logs).
It is worth noting that pipes are only one of the enabling technologies for this sort of thing. There are two others.
The first is the Bourne shell and derivative. The fact that the shell makes it easy to create pipelines is fundamental to their success.
The other is the common practice of having program receive and generate un-decorated line-oriented data. This 'common language' for passing data around is essential for pipelines to work. It is worth noting that while line-oriented is very standard, having fields in the lines is very ad-hoc. Many commands allow you to act of fields, but they all do so in different ways. If you compare sort, cut, uniq and others you will see a complete lack of uniformity. This something that a successor to pipes would need to address.
So a successor to pipes needs an IPC primitive (the pipe), and platform for building applications (the shell) and a standard data representation (line == record). It also needs a market - a reason for existence.
My own feeling of the market is for interactive tools. With pipe line, there is no opportunity for a conversation between elements of the pipeline. There is no way to have a "server" which will respond to requests, or a client that can give more information. So interactivity would be my choice of market place. Note that this doesn't mean interactive in a 'human-interacts-with-computer' sense, but in a 'client interacts with server' sense.
This is by no means a new market - there have been RPC (remote procedure call) systems for decades. There is even CORBA which is designed to make parts easily interchangeable. But somehow they don't seem to have the same degree of use as pipelines.
I also think that the IPC primitive is already available. I see two primitives as being usable. One is loadable modules, and the other is Unix domain sockets.
Loadable modules allow the server to run in the same address space as the client, which should provide high bandwidth and low latency. It does require the server to be single threaded and to only server one client at a time. For many applications this would be fine.
Unix domain sockets are an easy way to create a connection between two processes, much like a pipe. It is better than IP sockets as there is natural permission checking.
That just leaves a suitable data format, and a usable platform.
Data Format
I think it would be a mistake to try to define how fields fit into records, what separator to use, and how to label fields. It might be worth doing this if we were trying to make pipelines better, but we are going beyond that.
I see that appropriate abstraction being a namespace line a filesystem. Each server presents a namespace. Each name can be "opened" and the resulting channel can be subject to "read" and "write". Each client sees it's own namespace, so that different clients don't affect each other unless that is the purpose of the service.
Whitelisting email
I have been following SPF for a while and have been thinking through the whole junk-mail control issue.
I have come to the conclusion that the only viable long-term solution is agressive whitelisting.
I have been having thoughts about setting up a local service to support whitelisting.
Getting Organised
I often get the feeling that I am thrashing - lots of little things to do, plenty of interruptions, stuff gets done but it doesn't seem to get done as efficiently as it should. I spend to much time trying to decide what to do next.
So I recently (well, a few weeks ago now) realised that it was time for something to change.
Since then, I have been planning to do one thing each day. Sometime two if the second one was small, but normally one.
If I get an interruption that cannot be dealt with immediately, I schedule it in so that it has it's day, a few days hence.
This has been working REALLY WELL.
- Firstly, there is the feeling of being in control - I have a plan.
- Then there is the feeling of being productive. I can cross something off each day.
BULLET - It also means that I know what to do first thing - I have already allocated something to do, so I get stuck in and do it. BULLET - Sometimes things don't take the whole day, and I can do something that was scheduled for a later day and so get ahead of my plans. This doesn't happen often, but it feels good when it does. BULLET - It means that the less-urgent things still get attended to. Maybe not often, but at least sometimes. I have been using my work-at-home day to work on myfilesystem (which I really should create a page about). I haven't spent any time on that for nearly a year .
On the whole, I am very pleased.