Say you wanted to create a RAID1 device but didn't have all your devices ready. Here is how you could create a degraded RAID1 array and then add the second device at a later time. For these examples /dev/sda1 is the first device which will become our RAID and /dev/sdb1 will be added later.

First step is easy, create the RAID array. Our array will be /dev/md0. The "-n 1" option tells it that just a single device will be used and "-f" is required to use such a non-standard option.

$ mdadm --create /dev/md0 -l raid1 -f -n 1 /dev/sda1

Looks like World IPv6 Day was a good success. I saw a lot of traffic on NANOG announcing various issues people had seen, and many people declaring success. My own little fiefdom experienced relatively few problems. My Linux laptop had no issues with Google, Facebook and the other sites I could find. I reset my traffic counters this morning so I could watch it:

Despite what some simple Googling might imply, it's entirely possible to use a /32 as a netmask for an IP address on Linux. The important detail is that it can't be the primary IP address. That primary can be an RFC1918 address (i.e. nonrouteable on the Internet) but your default gateway needs to be able to route to you via something other than the /32.

Here's the setup. Assume a Cisco router on 192.0.2.1/24 and a Linux server on 192.0.2.2/24. The /32 we'll use is 192.0.3.1/32.

On the server:

ip addr add dev eth0 192.0.2.2/24
ip addr add dev eth0 192.0.3.1/32

On the router:

interface FastEthernet0/1
ip address 192.0.2.1 255.255.255.0
ip route 192.0.3.1 255.255.255.255 192.0.2.2

At this point, you should be able to ping both 192.0.2.2 and 192.0.3.1 from the router.

The other step you may need to take is to add some routing on the Linux server to source from the 192.0.3.1 address. Normally traffic that is received on that IP will reply with that IP, so that's fine, but for new traffic if you want the source to be the /32, you'll need a special route:

ip route add 10.0.0.0/8 via 192.0.2.1 src 192.0.3.1

See, I told you it was easy.

There's a great food blog that I read. I used to read it with much more zeal than now, and that's the subject of my story. See a few ago I noticed a recipe for what amounted to a casserole made from a can. Had I drifted back in time to the 1950s? No, upon further review this was a post sponsored by "Campbell's Kitchen". I was shocked and yes even a little offended.

The problem wasn't so much the fact that they were accepting advertising from Campbell's, rather that now I didn't know which stories are advertising. For example, in this review of store-bought gravies (something I would not ever buy anyway, but I'm into taste tests of all sorts), Campbell's gravy got an honorable mention. Is that because it was actually tasty or because Campbell's slipped a little cash their way. There's really no way to know. Worst of all, nothing the author might say could prove otherwise because how do we know he's not being paid off to deny it. It's a horrible spiral of assumed deceit.

Beyond just a silly food blog, this is basically the same problem facing Congress. When a congressman takes campaign money from a person or company, and then later passes legislation that benefits that entity, how can we ever believe that the money didn't affect their decision? And even if the representative is being honest and trying their best, does the money subconsciously alter their behavior?

We here at zmonkey.org are proud to bring you ad-free content. You can be certain that nobody paid anything for this, no matter how hard we might have tried.

The last day of the conference started with a fabulous presentation by Joshua Drake from Command Prompt. From my former days as a Postgres admin, I recall he was quite the presence on the Postgres mailing list so I was quite excited. He went from bottom to top (could have been top to bottom; hard to tell) on how to make Postgres fast. Among the key concepts were that RAID5 is always to be avoided (use RAID10), put your transaction log on a separate spindle (RAID1 please), and take time to learn EXPLAIN ANALYZE. The details take much longer to learn but if I ever get the chance to run a Postgres database again, these will come in very handy.

Miscellaneous Notes:

• hard drives are the slowest
• raid1 great for pg_xlog
• split transaction log
• raid10 for data, separate raid1 for transaction log
• transcation log on ext2 because it *is* a journal
• don't use raid5
• always always always use a battery backup unit (bbu)
• many controllers will disable cache if no bbu
• max out ram. 98% of data sets fit in 4GB of ram.
• sata is great. get a bbu and get twice as many spindles.
• pg is process-based. more cores, better performance.
• autovacuum is not optional. do it.
• default autovacuum works 99% of the time
• shared_buffers - pre-allocated working cache of tuples
• rule of thumb is 20% of available ram
• check kernel.shmmax
• work_mem - amount a sort, etc can use before it spills to disk
• set work_mem to a larger value if you know a query needs it
• explain analyze shows the sort method and the amount of mem
• maintenance_work_mem - maintenance tasks - analyze, vacuum, create index, reindex
• set maint as high as possible. ceiling, not allocation.
• effective_cache_size - very misunderstood. hint.
• % of cached + shared_buffers = effective_cache_size
• generally 40% to 70%
• log_checkpoints - off by default. correlate between checkpoints and spikes in %IOWait from sar
• checkpoint_timeout - force timeout. 15-20 minutes. default 5.
• checkpoint_completion_target - do not change this
• checkpoint_segments - default 3. set to 10. how many transactions logs before a checkpoint is forced.
• use checkpoint_warning to see if you need more
• each segment is 16MB
• recovery means going through each segment
• wal_sync_method - leave default
• synchronous_commit - wait for wal to be written before client completes
• turn off for faster commits. generally turn off.
• default_statistics_target - arbitrary value to determine stats collected by vacuum
• analyze will take longer, but plan is better
• can be set per-column
• know to increase it with explain analyze. if plan == actual, good.
• sqlite - great unless you need concurrent writes
• seq_page_cost - related to rand_page_cost. cost of fetching from disk. with raid10 set the same.
• cpu_operator_cost - default is 0.0025. 0.5 is better
• cpu_tuple_cost
• connection pooling - use pgbouncer
• skype uses postgresql
• plproxy
• prepared queries hang onto plan for the life of the connection. pooled connections can be problems.
• functions are great for ORM
• execution_cost - higher means function costs more
• no function hints to the planner
• 9 has replication. not ready for production data yet.
• londiste - some kind of skype-made replication
• drbd