Categories
General Technical

Speaking of speed…

I really don’t like waiting, especially when I can avoid it. Therefore, when I got tired of waiting for my computer recently I did something about it.

On SSH and passwords

The average ssh logon time consumes what feels like 3-4 seconds on my 2007-era machines. The delay has worsened since Ubuntu 0910, which now retrieves system information on logon (in its default form, nearly useless to me). I really like the idea of seeing useful info at logon time, but bottlenecking logon – the most common act that happens – for multiple seconds is unacceptable. If you’re like me, just use your own script instead of landscape:

apt-get remove landscape-common

I banged out some bash that runs nearly instantaneously and shows only what I actually care about, and it only took some lines in .profile. simple version:

echo 'df -h' >> ~/.profile
PATH=$HOME/bin/

Finally for a really good one that totally pays for itself: think about how many times you type in a password. The net time saved by not having to spend a few seconds typing in your password each time is huge.

echo "PubkeyAuthentication yes" >> /etc/ssh/sshd_config

It’s called public key authentication in SSH, and it’s one of the best kept SSH secrets.

Categories
Technical

Decent speed boost

Just finished optimizing the page load time by recompressing several large JPGs that used to be part of every page that had a sidebar (i.e. most pages on this site).

Load times are down to an average of about .983 sec from about 1.8 sec before. Hooray for more speed.

Categories
Technical

Note on building your own RAID5

RAID5, generally speaking, is a bad idea. Unless you have some very specific needs, RAID5 increases complexity, is more prone to hardware failure and administration errors, and does not automatically back itself up. If two RAID5 member drives fail at the same time, *all* your data is SOL. Individual drives, such as a bunch of externals, are probably a better choice for most people. And if two individual drives fail, you can still get data from the rest of them.

But people are nevertheless drawn to RAID5’s speed and size; it’s a great way to effectively have a freaking gigantic drive. It’s set and forget, easy to expand in the future (with some filesystems), and for reads is substantially faster than one drive. If one RAID5 drive fails, it’s an easy fix via drop-in replacement.

Some advice: when building a RAID array, use drives from different sources. Going different brands is probably a good idea, but caveat emptor: Company A’s 1TB drive will most likely not be the same ultimate size Company B’s. The available space will quite probably be skewed by a few KB or MB.

It should go without saying, but build your array only when you have all drives in hand. To more easily allow future expansion of your RAID, when it comes partition time shave a meg or so off your smallest drive. And when you decide to expand your array, buy a drive that’s the exact same model as one already in there. It will probably be cheaper than the newest model anyway.

Categories
Design Meta Technical Web Design

Favicon update

To keep your bookmarks and RSS feed favicons looking shiny, I changed the onpaws.com favicon again. I was getting tired of the crusty current one which I made on a whim one day:

Passable at 64×64, but it always looked crummy at the more commonly seen 16×16:

After becoming intimately reacquainted with the various ways to disable Photoshop’s on by default selections and fill anti aliasing, I started with a 16×16 canvas this time, using the pencil tool and as per usual keeping the background transparent. This was a candidate:

But I’m happy with this new one for now- it retains the motif of circle + ‘p’ descender from onpaws -> op.

What do you think?

Categories
Technical

Recovering a deleted MBR partition table (ext2/ext3)

This post is originally from April 2007 and never got published. Here’s hoping I’ll never have to use it again. ~paws

Take a deep breath and relax. This is not bad luck. This is God’s retribution for your failure to back up your data. You are a bad person and you deserve this. Fortunately, there is a way for you to spite the will of God and recover your data anyway. Unfortunately, acts of contempt in this class usually require nerves of steel, and this stunt is no exception. Here is what you do:
Make a partition that is at least as big as your first partition was. You can make it larger than the original partition by any amount. If you underestimate, there will be much wailing and gnashing of teeth.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-23361, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-22800, default 22800): 13032

Command (m for help): w

Run dumpe2fs on the first partition and grep out the block count
Example:

% dumpe2fs /dev/sda1 | grep “Block count:”
Block count: 41270953

If you are uncertain about this value, repeat Step 1 with a bigger partition size. If the block count changes, then you underestimated the size of the original partition when you made your first guess. Repeat Step 1 until you get a stable block count.

Remove the partition you just created
Command (m for help): d
Partition number (1-4): 1

Make a new partition with the exact size you got from the block count. Since you cannot enter block size in fdisk, you need to figure out how many cylinders to request. Here is the formula:

(number of needed cylinders) = (number of blocks) / (block size)

(block size) = (unit size) / 1024

(unit size) = (number of heads) * (number of sectors/cylinder) * (number of bytes/sector)

Consider the following example, where a hard drive has been partitioned into four primary partitions of 1, 2, 4, and 8 cylinders.
disk /dev/sda: 16 heads, 63 sectors, 23361 cylinders
Units = cylinders of 1008 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 2 976+ 83 Linux
/dev/sda2 3 5 1512 83 Linux
/dev/sda3 6 10 2520 83 Linux
/dev/sda4 11 19 4536 83 Linux
fdisk provides the configuration information I need in the head of the output.

The unit size is 516096 ( 16 heads * 63 sectors/cyl * 512 bytes/sector ).

The block size is 504 ( 516096 / 1024 ).

The number of needed cylinders for the second partition is therefore 3 ( 1512 blocks / 504 ).

The partition table shows that this is indeed the case: the first cylinder is 3, the second 4, and the last is 5, for a total of three cylinders.

The number of needed cylinders for the third partition is calculated similarly: 2520 blocks / 504 = 5, which corresponds to 10 – 6 (plus one, since we are counting the 6th through the 10th cylinders inclusively).

Notice that this calculation does not work for the first partition because the block count is wrong ( 976 instead of 1008 ). The plus sign indicates that not all the blocks are included in the fdisk value. When you try the calculation ( 976 / 504 ) you get 1.937. Knowing that the number of cylinders must be an integer, you can simply round up.

Run e2fsck on it to verify that you can read the new partition.

Repeat Steps 1-5 on remaining partitions.

Remount your partitions. Amazingly, all of your data will be there.

Credit for thinking of this strategy goes to Mike Vevea, jedi sys admin and MGH’s finest.