Tag-Archive for » linux «

Sunday, August 04th, 2013 | Author:

I had a power outage affect my server’s large md RAID array. Rather than let the server as a whole be down while waiting for it to complete an fsck, I had it boot without the large array so I could run the fsck manually.

However, when running it manually I realised I had no way of knowing how far it was and how long it would take to complete. This is especially problematic with such a large array. With a little searching  I found the tip of adding the -C parameter when calling fsck. I couldn’t find this in the documentation however: fsck –help showed no such option.

The option turns out to be ext4-specific, and thus shows a perfectly functional progress bar with a percentage indicator. To find the information, instead of “fsck –help” or “man fsck”, you have to input “fsck.ext4 –help” or “man fsck.ext4”. 🙂

Sunday, August 04th, 2013 | Author:


Much had changed since I last mentioned my personal server – it has grown by leaps and bounds (it now has a 7TB md RAID6) and it had recently been rebuilt with Ubuntu Server.

Arch was never a mistake. Arch Linux had already taught me so much about Linux (and will continue to do so on my other desktop). But Arch definitely requires more time and attention than I would like to spend on a server. Ideally I’d prefer to be able to forget about the server for a while until a reminder email says “um … there’s a couple updates you should look at, buddy.”

Space isn’t free – and neither is space

The opportunity to migrate to Ubuntu was the fact that I had run out of SATA ports, the ports required to connect hard drives to the rest of the computer – that 7TB RAID array uses a lot of ports! I had even given away my very old 200GB hard disk as it took up one of those ports. I also warned the recipient that the disk’s SMART monitoring indicated it was unreliable. As a temporary workaround to the lack of SATA ports, I had even migrated the server’s OS to a set of four USB sticks in an md RAID1. Crazy. I know. I wasn’t too happy about the speed. I decided to go out and buy a new reliable hard drive and a SATA expansion card to go with it.

The server’s primary Arch partition was using about 7GB of disk. A big chunk of that was a swap file, cached data and otherwise miscellaneous or unnecessary files. Overall the actual size of the OS, including the /home folder, was only about 2GB. This prompted me to look into a super-fast SSD drive, thinking perhaps a smaller one might not be so expensive. It turned out that the cheapest non-SSD drive I could find actually cost more than one of these relatively small SSDs. Yay for me. 🙂

Choice? Woah?!

In choosing the OS, I’d already decided it wouldn’t be Arch. Out of all the other popular distributions, I’m most familiar with Ubuntu and CentOS. Fedora was also a possibility – but I hadn’t seriously yet considered it for a server. Ubuntu won the round.

The next decision I had to make didn’t occur to me until Ubiquity (Ubuntu’s installation wizard) asked it of me: How to set up the partitions.

I was new to using SSDs in Linux – I’m well aware of the pitfalls of not using them correctly, mostly due to their risk of poor longevity if misused.

I didn’t want to use a dedicated swap partition. I plan on upgrading the server’s motherboard/CPU/memory not too far in the future. Based on that I decided I will put swap into a swap file on the existing md RAID. The swap won’t be particularly fast but its only purpose will be for that rare occasion when something’s gone wrong and the memory isn’t available.

This then left me to give the root path the full 60GB out of an Intel 330 SSD. I considered separating /home but it just seemed a little pointless, given how little was used in the past. I first set up the partition with LVM – something I’ve recently been doing whenever I set up a Linux box (really, there’s no excuse not to use LVM). When it got to the part where I would configure the filesystem, I clicked the drop-down and instinctively selected ext4. Then I noticed btrfs in the same list. Hang on!!

But a what?

Btrfs (“butter-eff-ess”, “better-eff-ess”, “bee-tree-eff-ess”, or whatever you fancy on the day) is a relatively new filesystem developed in order to bring Linux’ filesystem capabilities back on track with current filesystem tech. The existing King-of-the-Hill filesystem, “ext” (the current version called ext4) is pretty good – but it is limited, stuck in an old paradigm (think of a brand new F22 Raptor vs. an F4 Phantom with a half-jested attempt at an equivalency upgrade) and is unlikely to be able to compete for very long with newer Enterprise filesystems such as Oracle’s ZFS. Btrfs still has a long way to go and is still considered experimental (depending on who you ask and what features you need). Many consider it to be stable for basic use – but nobody is going to make any guarantees. And, of course, everyone is saying to make and test backups!


The most fundamental difference between ext and btrfs is that btrfs is a “CoW” or “Copy on Write” filesystem. This means that data is never actually deliberately overwritten by the filesystem’s internals. If you write a change to a file, btrfs will write your changes to a new location on physical media and will update the internal pointers to refer to the new location. Btrfs goes a step further in that those internal pointers (referred to as metadata) are also CoW. Older versions of ext would have simply overwritten the data. Ext4 would use a Journal to ensure that corruption won’t occur should the AC plug be yanked out at the most inopportune moment. The journal results in a similar number of steps required to update data. With an SSD, the underlying hardware operates a similar CoW process no matter what filesystem you’re using. This is because SSD drives cannot actually overwrite data – they have to copy the data (with your changes) to a new location and then erase the old block entirely. An optimisation in this area is that an SSD might not even erase the old block but rather simply make a note to erase the block at a later time when things aren’t so busy. The end result is that SSD drives fit very well with a CoW filesystem and don’t perform as well with non-CoW filesystems.

To make matters interesting, CoW in the filesystem easily goes hand in hand with a feature called deduplication. This allows two (or more) identical blocks of data to be stored using only a single copy, saving space. With CoW, if a deduplicated file is modified, the separate twin won’t be affected as the modified file’s data will have been written to a different physical block.

CoW in turn makes snapshotting relatively easy to implement. When a snapshot is made the system merely records the new snapshot as being a duplication of all data and metadata within the volume. With CoW, when changes are made, the snapshot’s data stays intact, and a consistent view of the filesystem’s status at the time the snapshot was made can be maintained.

A new friend

With the above in mind, especially as Ubuntu has made btrfs available as an install-time option, I figured it would be a good time to dive into btrfs and explore a little. 🙂

Part 2 coming soon …

Friday, September 11th, 2009 | Author:

Peace in the land of USB

Under a *nix operating system, having multiple partitions on a USB drive isn’t rocket science, it just works. In my case, my USB drive has two partitions because the first partition is a bootable Arch Linux installer.

I have Windows on a desktop at home – mostly for gaming – and many of my colleagues use it too. Since Windows doesn’t do very well with non-Windows partitions I figured I could create a FAT32 partition on the memory stick after the bootable Arch Linux partition. FAT32 is almost ubiquitous and is usable on every common desktop operating system in the world.


Unfortunately it doesn’t work straight off the bat. Apparently, Microsoft in their infinite wisdom decided that memory sticks are supposed to have one (and only one) partition. In reality Windows finds the first partition and then ignores any others that happen to be set up:

Please Format

Err, no, I do not want you to format my Arch Linux installation partition

The trick to getting it working is to fool Windows into thinking the device is not a regular USB memory stick but perhaps a solid-state hard disk which happens to be connected via USB. Yes I know, this is seriously stupid that Windows behaves this way. A solid-state hard disk is just a whopping big (and fast) memory stick after all!

I found a few sources on how to do this however I still had to figure out some things on my own. Specifically, the guides I found either skipped some steps or didn’t provide enough information on where to download the driver package.

This procedure involves manually changing hardware drivers and installing “non-signed” drivers “not intended for your hardware”. I know someone is going to break their system and blame me so I say now that I take no responsibility for any damage you may do to your Windows system as a result of this. Read that again. 😛


remove the highlighted text

click for larger version

Download and unzip the driver, originally created by Hitachi, here. Open the cfadisk.inf file in notepad (or your favourite plaintext editor), and find the section labeled [cfadisk_device]. Remove the section highlighted on the right:

Minimize (don’t close) the editor and go to your desktop icons – right-click on My Computer and select Properties. Select the hardware tab and then select [Device Manager]:

System Properties

Find the device under “Disk drives”, right-click your memory stick and select Properties:

Device Manager

Click the Details tab and in the dropdown box on that page, select “Hardware Ids”. Click the first line in the list of Hardware IDs and press Ctrl+C to copy the name:

USB Hardware Ids

Don’t close this dialog, go back to notepad (which was minimised) and paste the hardware ID into where the previous content was removed.

Changes pasted into notepad

Save the file in notepad and go back to the device’s property dialog window. Click the “Driver” tab and click the [Update Driver…] button. In the windows that pop up, select “No, not this time”; [Next] -> “Install from a list or a specific location (Advanced)”; [Next] -> “Don’t search. I will choose the driver to install.”; [Next] -> [Have Disk…].

Unsigned Drivers - Click Continue Anyway

Browse to the folder where you have saved the modified cfadisk.inf file. Click [OK]. You will find

there is a Hitachi Microdrive driver listed. Select this and click [Next]. When the warning

appears, click [Yes]. Another warning will pop up regarding a similar issue (these are the “unsigned” and “not intended for your hardware” warnings I mentioned earlier). Click [Continue Anyway]:

At this point I recommend closing all the dialog boxes related to the setup. Finally, remove and re-insert the memory stick into your USB port and you should find that the extra partitions on the stick are accessible. In the worst-case scenario, you might still need to partition the disk however the hard part is over. 🙂

Wednesday, April 22nd, 2009 | Author:

Arch Linux’s installation process is documented on the Arch wiki. I recommend that persons new to Arch try the excellent Beginner’s Guide instead of the Official Arch Linux Install Guide. Though both wiki entries cover similar ground, the Beginner’s Guide gives a lot more relevant information for those new to the system. The Beginner’s Guide is aimed at desktop installation and, as I’m installing a server, I won’t be going through the installation of the graphical environment at all. Assuming that you’re following my installation, assume that I’ve followed the Beginner’s Guide right up to and including the installation of sudo.  I installed the ssh daemon afterwards rather than during the initial setup however.

A few small recommendations and notes regarding installation:

  • If you can, consider using a USB memory stick for the installer and keep it handy for future installations.
  • I keep a copy of my local “repository” of installed applications on my installer memory stick. Once installation is finished I save a bit of download and update time by copying this to the new server’s /var/cache/pacman/pkg/ folder. The repository on my desktop is typically 1.7GB
  • For the rc.conf, South African-appropriate regional settings are:
  • I’ve set up the network very simply, according to the guide, and will be expanding on the network setup in a later post.
  • As it is for a server, my non-privileged user on the server is only part of 3 groups: wheel (for sudo), storage, and users. A desktop user will likely be in many more groups.

I prefer using an application called yaourt instead of Arch’s default package manager. Yaourt has the exact same usage syntax as pacman except that it supports a few extra options. It is actually a wrapper application in that it, in turn, uses pacman. Importantly, yaourt supports installation of applications from Arch’s AUR. The AUR is a repository of installation scripts built by Arch users for Arch users to easily install applications that are not officially supported by the main Arch repositories. Yaourt can download and install applications from AUR or the main repositories with the same command, treating the AUR as “just another repository”. Pacman unfortunately does not support this.

Again, the installation is covered in the wiki. I recommend the easy route mentioned in the wiki if you’re new at Arch. Its too much too soon to do it the hard way (also mentioned in the wiki entry).

When done, update your system by issuing the single command:

yaourt -Syu


pacman -Syu

and follow the given recommendations.

Saturday, March 28th, 2009 | Author:

Its amazing how much you can do by combining the small yet powerful commands Unix has available.

This little-used command, time, finally became useful today as a way to report the length of time that certain automated operations are running. In my example, I’m timing how long it takes to build the Linux kernel:

$ time rebuild-kernel26
==> Finished making: kernel26 x86_64 (Sat Mar 28 17:19:52 SAST 2009)
real    62m21.994s
user    43m31.846s
sys     6m1.096s

Yup, that took a little over an hour to build. The values are:

  • “real” the actual time elapsed while the command was running – 62 minutes
  • “user” the amount of userland time the command used – 43 minutes
  • “sys” the amount of system time the command used – 6 minutes

(I was busy doing other things while this was happening which is why it took 62 minutes for the desktop to do (43+6=) 49 minutes-worth of work)

If you’re using the GNU version (most likely), it also gives you the option of displaying the results in a custom fashion. Mostly, this command could be useful in scripts where you need to report how long a task took – or maybe? just a geeky way to time something random. 😛

Category: linux  | Tags: , , , , , , ,  | Leave a Comment