stupidfs

Once I've finished the NAT module for Cisco's Skinny protocol I'd like to write a "filesystem". My researchers often use raw partitions for saving data -- they transfer a few big datasets and transfer speed wins over the convenience of a general-purpose filesystem. The huge number of virtual partitions allowed by LVM has been a win.

However, filesystems are convenient: Naming, times, access control. What is needed is a filesystem no more complex than dd. Too stupid for general use: bad things happen as the filesystem fragments into holes from file deletion. Interesting for high-performance data transfer and for measuring the overhead of a filesystem compared to dd (which I've read may be as high as 30%, but we will actually be able to know, rather than to suspect).

The Web and Benford's Law

Benford's Law (Frank Benford, 1939) says that numbers starting with small numerals are more likely to be encountered in nature than numbers starting with larger numerals. Dr Karl has a good summary.

Although I can't be bothered to run the few thousand samples through Google, it looks like Benford's Law holds for web content. Note the distribution at (9) to (11):

hits(1) = 9,470,000,000), hits(2) = 3,110,000,000, hits(3) = 2,760,000,000, hits(4) = 2,430,000,000, hits(5) = 2,350,000,000, hits(6) = 2,050,000,000, hits(7) = 1,940,000,000, hits(8) = 1,880,000,000, hits(9) = 1,760,000,000, hits(10) = 2,560,000,000, hits(11) = 1,920,000,000.

Configuring Pine for SMTP Submission and IMAPS

The open standard for corporate e-mail is to send authenticated mail on the SMTP submission port and to store folders using IMAP over SSL. One of the nice things about using a standard protocol is that you can use a range of e-mail clients, even on the same machine.

Sometimes it is useful to use the ancient Pine mail client. I find it particularly useful if I need to retrieve an e-mail when connected to a router console.

Configure ~/.pinerc to be:

user-domain=example.com
smtp-server=submission.srv.example.com:587/tls/novalidate-cert/user=gdt
inbox-path={imaps.srv.example.com/ssl/novalidate-cert}INBOX
default-fcc={imaps.srv.example.com/ssl/novalidate-cert}Sent
postponed-folder={imaps.srv.example.com/ssl/novalidate-cert}Drafts
folder-collections="Example" {imaps.srv.example.com/ssl/novalidate-cert}[]
rsh-open-timeout=0
ssh-open-timeout=0

linux.conf.au 2008 Sysadmin miniconf

I am please to inform you that we have accepted your talk below for the linux.conf.au 2008 Sysadmin Miniconf.

Response to call for papers for linux.conf.au 2008 sysadmin miniconf

Topic

Tuning hosts for network performance.

Description

The bottleneck for network performance used to be transmission capacity. Huge amounts of capacity can now be had for moderate cost. The bottleneck has now moved to the host connected to the network and to the network protocols and their tuning.

This presentation gives Linux system administrators information to identify practices which lead to poor network performance. Common fault scenarios and the tools used to investigate those scenarios are explored.

The pros and cons of using Linux as a network middlebox are examined and a checklist of good practices for middleboxes are given.

Specific practices include: bandwidth-delay product and TCP buffer tuning; Linux buffer autotuning; congestion, link loss and TCP performance; common causes of link losses; choice of TCP algorithm, performance and fairness; applications design. Tools include: what do ping and traceroute actually measure; using iperf and ttcp, using Web100 kernel patches.

Middlebox issues include: participating in the control plane; anti-DoS measures; allowing fault diagnosis; queuing; minimising jitter; fairness; concurrent flow effects.