Why would you want to do this? Well, say for example you have a MythTV Frontend PC. For the most part, most Frontends are dedicated PC’s connected to a TV or projector that are not used for any other purpose, so technically there is really no need to have a hard-drive inside one as nothing new will ever be stored (all the media is streamed from the Backend server). There’s also the added bonus of less noise by not having a hard-drive installed.

Another good example of using a Diskless boot environment is for performing offline virus scans of Windows based PC’s in a safe environment that is not Windows, using tools like ClamAV. In a corporate environment, having a “normal” installation makes it easier to setup default settings that normally don’t suit booting up from an Ubuntu Live CD, such as corporate Proxy settings. Making a Diskless Boot setup is far easier than creating a customised Live CD in this instance.

So how exactly do you create a diskless booting PC?

Pre-requisites:

• First up, you need a working PXE server. If you haven’t built one yet, you can refer to my previous tutorial on how to build one.
• Sufficient space to store a typical Ubuntu Desktop install. I would recommend having at least 10GB free to allow space for both the OS and any additional apps you might install.
• A PC that you will using as your diskless machine that has the ability to boot from PXE.
• A temporary hard-drive for your diskless machine that we will be using to do our initial build on.
• A fast network. Diskless booting is only useful if your network can transfer data quickly. I would recommend that you use a gigabit network.
• It is recommended to have at least 2GB RAM on your diskless PC, primarily because we will not be running a swap file or swap partition (swapping over a network connection is just silly).
• Ubuntu 10.04.2 LTS was used for this tutorial, but you should be able to use just about any release of Ubuntu. Note: The version of Ubuntu on your PXE server and the version of Ubuntu you are turning into diskless boot does not have to be the same version, but I would recommend using 10.04.2 LTS or later.

What to do:

1. First up, install the temporary hard-disk into your PC that is going to become diskless. You can attach it in the traditional way or connect it via USB.
   .
2. Perform a normal installation of Ubuntu Desktop Edition onto the hard-drive of your PC.
   .
3. Once installed, update the system with any outstanding system updates.
   .
4. Install any additional apps you wish to utilise on this machine, such as MythTV.
   .
5. Once you are satisfied that your installation is setup the way you want it, we need to prepare the installation to be able to boot via PXE. Start by opening up a terminal and type in the following commands:

   $ cd ~
   $ sudo nano /etc/initramfs-tools/initramfs.conf

6. You will now be looking at a text configuration file in the Nano text editor. This is the configuration file that controls how the boot-time RAM disk image is created. We need to modify it so that we can create a PXE-ready version of the RAM disk image instead of the usual type. Scroll down until you find the configuration line that looks like:

   MODULES=most

   …and modify it so that is now looks like:

   MODULES=netboot

7. Scroll down a little further until you see the line:

   BOOT=local

   …and change it to read:

   BOOT=nfs

8. Press CTRL+X, then “Y” and then “Enter” to save your changes. You will be returned to the Terminal prompt.
   .
9. Now let’s create our custom RAM Disk image using the following command:

   $ sudo mkinitramfs -o ./initrd.img

10. Once that has finished, we also need an unmodified copy of the current kernel you are running:

    $ cp /boot/vmlinuz-`uname -r` ./vmlinuz

11. Now we need to prep the server. First up, we need to setup a way to transfer our temporary hard-disk contents to the PXE server, and we also need to ready how the PXE server will serve the data to the diskless workstation when booting. We will be using the Network FileSystem or NFS for short. On your Ubuntu PXE Server, open a terminal and type in the following:

    $ sudo apt-get install nfs-kernel-server

12. Once the NFS server is installed, we need to setup the directory that will store and serve the Diskless system’s files. Assuming you have all your PXE related data under /srv/tftp, let’s create the following for our Diskless station data:

    $ sudo mkdir -p /srv/nfs/disklessboot

13. Now let’s tell the NFS server about this new directory:

    $ sudo nano /etc/exports

14. In the text file that appears in the Nano text editor, scroll to the bottom of the file and add the following line:

    /srv/nfs/disklessboot          *(rw,no_root_squash,async)

    The above will allow read/write access to the path /srv/nfs/disklessboot on your PXE server from any incoming IP address.

15. Save your changes by pressing CTRL+X, then “Y” and then “Enter”.
    .
16. Now activate the new NFS share by using the following command:

    $ sudo exportfs -a

17. We’re nearly there! Now we just need to transfer the contents of our temporary workstation hard-drive to the new NFS share. On your soon-to-be-diskless PC (not the server), and assuming that your PXE server’s IP address is 192.168.0.10, type the following in a Terminal:

    $ mkdir /dev/shm/nfs
    $ sudo mount -t nfs -onolock 192.168.0.10:/srv/nfs/disklessboot /dev/shm/nfs

    The above will create a directory in your RAM disk to mount the PXE server’s NFS share on and the second command will mount the NFS share /srv/nfs/disklessboot in the directory you just created in your RAM disk locally, thus allowing you to now read and write data to that NFS share by using /dev/shm/nfs locally.

18. Now let’s copy the OS files from the temporary hard-disk to the PXE server’s NFS share:

    $ sudo cp -avx /. /dev/shm/nfs/.
    $ sudo cp -avx /dev/. /dev/shm/nfs/dev/.

    The above commands will take a minute or two to finish and will show you a giant list of files being copied.

19. We are now done with the soon-to-be-diskless PC, so shut it down and remove your temporary hard-drive.
    .
20. Go back to your server and type in the following at the Terminal prompt:

    $ sudo mkdir -p /srv/tftp/disklessboot
    $ sudo cp /srv/nfs/disklessboot/home/USERNAME/vmlinuz /srv/tftp/disklessboot/
    $ sudo cp /srv/nfs/disklessboot/home/USERNAME/initrd.img /srv/tftp/disklessboot/

    Note: Replace USERNAME above with whatever your username was on the temporary hard-disk setup, eg: “/home/jbloggs/”)

21. We now need to change the network setup of the diskless boot install so that it doesn’t try to configure itself with a new IP address on boot (since it’ll already have one when you do the initial PXE boot):

    $ sudo nano /srv/nfs/disklessboot/etc/network/interfaces

22. Look for a reference to “eth0″ which is your first ethernet adapter. It will generally be the last line in the file and may look like:

    auto eth0

    …or:

    iface eth0 inet dhcp

23. Once you locate it, comment out that line by putting a hash symbol at the front like so:

    #auto eth0

    …or:

    #iface eth0 inet dhcp

24. Now add a new line with the following:

    iface eth0 inet manual

25. Save your changes with CTRL+X, then “Y” and then “Enter”.
    .
26. Now we need to ensure that the devices mounted by your diskless booting PC do not try to mount physical disk devices for things like /home and the root filesystem. Type in the following command:

    $ sudo nano /srv/nfs/disklessboot/etc/fstab

27. Once in the text editor, DELETE EVERYTHING and replace it all with the following:

    proc            /proc           proc    defaults        0       0
    /dev/nfs        /               nfs     defaults        1       1
    none            /tmp            tmpfs   defaults        0       0
    none            /var/run        tmpfs   defaults        0       0
    none            /var/lock       tmpfs   defaults        0       0
    none            /var/tmp        tmpfs   defaults        0       0

28. Save your changes with CTRL+X, then “Y” and then “Enter”.
    .
29. That’s the Diskless setup ready to go. All that we now need to do is configure the PXE boot menu to give you an option to boot Diskless. To do this, edit your PXE boot menu configuration file. Assuming you called it /srv/tftp/mybootmenu.cfg, type in the following:

    $ sudo nano /srv/tftp/mybootmenu.cfg

30. In the text editor, scroll down to the bottom of your configuration file and add the following lines:

    label My Diskless Boot PC
       kernel disklessboot/vmlinuz
       append initrd=disklessboot/initrd.img root=/dev/nfs nfsroot=192.168.0.10:/srv/nfs/disklessboot ip=dhcp rw

    The above menu configuration will tell PXE to load the kernel and custom RAM disk image from the TFTP directory and then transfer control of the boot process to the OS files located in /srv/nfs/disklessboot which will be mounted on the diskless system at /dev/nfs as the root filesystem.

31. Save your changes by pressing CTRL+X, then “Y” and then “Enter”.
    .
32. Finally, make sure that the TFTP daemon can read the new files you added to it with the following command:

    $ sudo chmod 777 -R /srv/tftp

33. That’s it! You are now ready to boot! Turn on your now-diskless PC and tell it to boot from PXE. When the PXE boot menu appears, choose “My Diskless Boot PC” and watch in wonder and amazement as Ubuntu boots up without a hard-disk as if by magic!

NOTE: Whilst the Diskless PC will boot and operate much like any ordinary PC and in fact you can indeed perform future system updates this way, be aware that the kernel itself will NOT get automatically updated. Newer kernels will get installed to the NFS mount as you would expect, however the kernel actually boots from your TFTP directory, not the NFS share, so if you do update the kernel in future, you must create a new RAM disk image manually as per step 9 and copy both it and the new kernel file into your TFTP’s directory (in this case /srv/tftp/disklessboot/) otherwise your updated system will not boot anymore. Alternatively, simply allow all updates to be performed except for kernel updates.

Finally, hardware drivers: If you install the NVidia proprietary drivers for your Diskless Boot system, ensure that you don’t try to boot other systems that do not contain NVidia graphics hardware otherwise X will break. The reason for this is that the NVidia driver installation makes a number of changes to system-level libraries to work, effectively binding that system to NVidia graphics-based systems only. If you intend to use your Diskless setup on multiple hardware platforms, such as NVidia, Intel and ATi, do not install the proprietary NVidia (or ATi) driver.

Enjoy!

But we’re not looking at the virtues of dd here. We’re looking at its annoyances and dd has one particularly glaring annoyance – a lack of display of progress. You could tell dd to start imaging your multi-terabyte hard-drive and not have any indication of how far it has gone – you just have to wait until it finishes. The dd command only outputs some information right at the very end of its job, which could well be several hours later. The only indicator that you have that something is happening is your hard-drive light madly flashing away.

Luckily while dd doesn’t show progress during its tasks, it can be prodded externally to give up information about itself as it runs, and we can achieve that by using the kill command without actually killing the dd command’s execution.

Now the kill command doesn’t just terminate tasks. It can also send other standard POSIX signals to applications. Many applications are written to acknowledge certain signals and perform an action on receiving them. In the case of dd, there is one signal that will make it output its summary information to the console as though it had finished, but rather than terminate, it keeps on going. The signal in question is USR1.

Here’s how to make use of it:

1. First we need a dd process running. Let’s say we are imaging our first fixed hard-drive /dev/sda to an image file called MyHDDBackup.img using the following command:

   $ sudo dd if=/dev/sda of=/home/jbloggs/MyHDDBackup.img

2. Now while that is running, open up a second terminal and type in the following followed by Enter:

   $ sudo kill -USR1 `pgrep ^dd`
   

   Breakdown of the above command:
   

   • sudo runs this command as root. In this case since we’re using dd as root, we also need to run the kill command as root or we won’t be able to send anything to dd.
   • kill is the command we are using to send dd a signal with.
   • -USR1 is the signal we are sending to dd.
   • pgrep is a program that will show you the process ID of a given application, in this case we use the argument “^dd” to say “locate any program that starts with the text ‘dd’ only” otherwise we would get other processes that containg the letters “dd” together in their name if we left out the chevron character. Note that the pgrep command is enclosed in “`” quotes so that it is executed and returns just a process ID number to the kill command.

3. Now have a look at the terminal that dd is running in. It has suddenly output some data about itself, specifically, how much of the task had been completed, but dd is still running! This is great – but how can we regularly have dd tell us where it’s up to without having to manually enter the above command each time? Simple, by combining it with the watch command:

   $ watch 'sudo kill -USR1 `pgrep ^dd`'
   

   The watch command will will re-execute the kill command once every two seconds, giving you near-realtime status to what dd is doing. If you want to change how often the watch command polls for, you can change it with the -n parameter, for example to change the polling to every 5 seconds, you would use:

   $ watch -n5 'sudo kill -USR1 `pgrep ^dd`'

While not providing any means of showing you how long it will take for dd to ultimately finish, you can now make use of the transfer speed shown along with the data processed thus far and calculate a rough idea of when dd will complete its task now.

Pat yourself on the back. You can now rest easy knowing that you can find out at anytime where dd is up to.

Since the idea of opening my PC on a regular basis to connect a drive is a bit of a turn off, I used to use an external USB drive enclosure. This works fine, but it’s a bit slow (well, at least until USB 3.0 makes its debut). The eSATA standard allows you to connect external drives at full SATA speed, but it’s not cost-effective to buy an enclosure for every external drive you have.

Enter the Docking Bay. This is a simple weighed base that allows you to connect a hard-drive in a similar way to how you used to plug in game cartridges into a classic game console like the Atari 2600. You can then eject the hard-drive and plug another one in, all without restarting the PC.

This is a review of one such Docking Bay and how it works with Ubuntu, including the wonders of hot-swapping.

I came across this generic eSATA Docking Bay whilst browsing my local PC store. eSATA Docking Bays have been around for awhile now, but I never got around to getting one so I figured I may as well try this one and see how it went under Ubuntu.

With a HDD inserted into the dock.

Without the HDD inserted into the dock.

There is unit was branded “A-Power” but I’ve seen several of these drives with various brand names on it, so this one is as generic as they come, but it comes in one of three variants:

1. eSATA and USB Docking Bay
2. eSATA and USB Docking Bay with in-built USB card-reader
3. USB-only Docking Bay with in-built USB card-reader

In my case, I got the first variant as I already have a separate card-reader.

Hooking Up

The Docking Bay is very easy to hook up. The package comes with the following components:

• The Docking Bay unit
• Power Supply
• eSATA cable
• USB cable

After connecting power, the Docking Bay is connected to the PC by the eSATA cable to a spare eSATA port on the back of your PC. You then insert the hard-drive into the slot on the top of the unit – it caters for both 3.5″ desktop hard-drives and 2.5″ notebook hard-drives. Once inserted, power on the drive using the power button at the back of the unit. The power light on the top of the Docking Bay will light up and you can now switch on your PC.

Configuration

eSATA Docking Bays don’t actually need any configuration as such. If you wish to make use of SATA’s ability to hot-swap, you will need to enable the Advanced Configuration Host Interface (AHCI) in your PC’s BIOS. Not every motherboard has AHCI, but if your machine is a recent machine, you should have AHCI capabilities. If you do not enable AHCI, you can still use your Docking Bay, however you will not be able to hot-swap a new drive without shutting down your PC first.

Using the Docking Bay

Drives inserted into the Docking bay appear like any ordinary permanently installed hard-drive inside your PC. You can format them, partition them, read and write data to them and see their SMART status like any other drive.

Doing an unscientific benchmarks using the dd app with a 7200rpm Seagate 1TB HDD, I was able to write straight zeros to the drive at a rate of about 116MB/s and read at about 120MB/s.

Real-world file copying transferred data at about 86MB/s which is consistent with normal single-drive copy speeds.

Doing a fresh installation of Ubuntu Karmic 9.10 on the hard-drive and booting my system from the docking bay and then repeating the boot test with the drive attached directly to the internal SATA connection as normal, Ubuntu booted in precisely the same amount of time, as one would expect. I was also able to dual-boot Ubuntu with Windows 7 without any issue.

Hot-swapping works well also. While Ubuntu is running, I insert my hard-drive into the dock, power on the drive and wait a few seconds. The drive appears in the Places menu, you choose it, enter your sudo password to mount the drive, and the drive appears on your desktop. When you are done with the drive, you simply do a right-mouse-click on the drive’s icon, choose “Unmount” and wait for any data to be written to the drive. Once the drive icon disappears off the desktop, you can then power off the drive in the docking bay, then press the eject button to remove the drive.

Dealing with differently sized drives, I tried a half-height Seagate 500GB I have (see photos). The spring-loaded flap on the top of the drive was able to hold the drive in place without a problem. Trying with a 2.5″ notebook HDD, the docking bay provides a cut-out section that allows you to insert the 2.5″ HDD but the flap does not press directly against the drive.

Conclusion

The convenience of a hard-drive docking station cannot be understated. This unit provides a simple, effective interface. For AUD$25 it’s cheap and in the last couple of months I’ve been using this unit, it has proven to be very reliable.

While this unit is not exactly the most elegant-looking of devices, it does the job and does it well.

Review score: 9 out of 10

Like most people, I use an external hard-drive to backup data to, or to shift things around if I’m low on space on my PC’s internal drive. Well, today that external drive reported that it was full. Damn.

So I fire up Ubuntu’s Disk Usage Analyser, aka Boabab, to find out what’s consuming the most space. I use a 1TB external drive and it’s formatted total is about 916GB, which is about right, however Boabab reported that the total consumption of data on the drive only added up to about 860GB – wtf? Even Nautilus’s Volume Properties window was reporting that the drive still had 50GB-odd free, so why is the system telling me it’s full?

I use Ext3 on my drives and, being a journalled filesystem, some space on the drive is reserved to record these journals among other functions which is expected, but 50GB worth? I did some research and found out that the Ext3 filesystem reserves 5% of disk space by default for itself! In this day and age of large drives, that’s a huge chunk of lost space!!

Thankfully there is a way to tell Linux not to reserve so much space. Read on…

1. First up, unmount your drive. You can do that by either right-clicking on the drive icon on the desktop and choosing “Unmount volume” or by clicking on the Eject icon next to it in the Places pane of any Nautilus window.
   .
2. Next, open up a terminal and type the following:

   $ sudo fdisk -l
   

   This will list all your available drives. Identify which one is your external drive and take note of the device name, eg: in my case my external drive appears as /dev/sdb with one partition on it, sdb1.
   .

3. Now type in the following:

   $ sudo tune2fs -m 1 /dev/sdb1
   

   This will modify the filesystem on that drive, on that one partition, to only reserve 1% instead of the default 5%.
   .

4. Now re-mount your drive by clicking on its name in the Places pane in a Naultilus window.
   .
5. The Nautilus Device Properties window will still show the same free space as before, because it reports the true total free space, but any Nautilus File Manager window only reports usable free space, which in the case of my external drive had now freed up a very sizable 37GB!
   .
6. Lather, rinse, repeat on any other non-system drive partitions on the same or different drive you want to reclaim space back for.

You learn something new everyday.

Title aside, this is one of yet another series of pre-packaged drive & enclosure solutions being bandied about the market today. These solutions are gaining interest with a lot of consumers because they generally manage to undercut the combined cost of buying the same hard-drive and enclosure separately, so much in fact that many users who only need the drive, buy the solution package, rip out the drive and discard the case because in some cases (pun not intended), it can be cheaper this way.

Cost aside, what if you simply need to have a cost-effective external portable backup solution with minimal hassles? That immediately calls for a notebook hard-drive that can be powered by the USB data cable.

A quick trip down to the weekly gatherings of some of my favourite vendors saw me come across Fujitsu’s answer to the masses – the intriguingly named Dynadisq III unit, available in several sizes. I am using the 320GB model for this review.

For AUD$130 you get:

• A single 320GB SATA 2.5″ notebook-sized hard-drive.
• Smart-looking matte silver enclosure with mini-USB, 5v external power and a small “Backup” button with some moderate styling and the Fujitsu logo embossed on top (the hard-drive is already pre-installed in the enclosure). The top side also features two LED’s – one green one for power and a red one for the obligatory activity notification. No blue LED’s in sight.
• A nice fake-leather pouch with a pocket and elastic strap to hold the drive, and several side pockets for cards and, er… stuff.
• A USB to mini-USB data lead.
• A USB to 5v-power lead.
• One-page “getting started” instructions (for Windows users only despite saying the unit will work on a “range of different computer operating systems”).
• A 50MB backup application installation CD-ROM (again, for Windows only).

The components come all packaged in a neatly presented and protected cardboard package.

The drive and case itself is lightweight and generally attractive to look at, with the fake leather pouch putting a bit of sophistication into the package, but then again, who buys an external hard-drive to be sophisticated?

Unfortunately, while the idea seems nice, the pouch just ain’t big enough to hold both the drive and cables together.

Plugging it in

Upon plugging it in to my Ubuntu Intrepid desktop, dmesg reported the following:

Nov  9 14:59:49 lamaar kernel: [ 1018.916011] usb 8-6: new high speed USB device using ehci_hcd and address 4
Nov  9 14:59:50 lamaar kernel: [ 1019.055454] usb 8-6: configuration #1 chosen from 1 choice
Nov  9 14:59:50 lamaar kernel: [ 1019.056230] scsi9 : SCSI emulation for USB Mass Storage devices
Nov  9 14:59:55 lamaar kernel: [ 1024.060657] scsi 9:0:0:0: Direct-Access     FUJITSU  DYNADISQ III     1.95 PQ: 0 ANSI: 2
Nov  9 14:59:55 lamaar kernel: [ 1024.062645] sd 9:0:0:0: [sdf] 625142445 512-byte hardware sectors (320073 MB)
Nov  9 14:59:55 lamaar kernel: [ 1024.063018] sd 9:0:0:0: [sdf] Write Protect is off
Nov  9 14:59:55 lamaar kernel: [ 1024.063640] sd 9:0:0:0: [sdf] 625142445 512-byte hardware sectors (320073 MB)
Nov  9 14:59:55 lamaar kernel: [ 1024.064017] sd 9:0:0:0: [sdf] Write Protect is off
Nov  9 14:59:55 lamaar kernel: [ 1024.064023]  sdf: sdf1
Nov  9 14:59:55 lamaar kernel: [ 1024.084377] sd 9:0:0:0: [sdf] Attached SCSI disk
Nov  9 14:59:55 lamaar kernel: [ 1024.084467] sd 9:0:0:0: Attached scsi generic sg6 type 0

So far so good, but not less than a few seconds later when GNOME tried to present the drive, the following dialog reared its ugly head:

Well, that confirms that it’s formatted for Windows out-of-the-box. Shame on Fujitsu for not properly unmounting the drive during factory testing! And what an exciting volume name they gave it too. Rather than shamelessly promote themselves, Fujitsu simply left it as the Windows-standard “New Volume”. Yay.

I was curious to find out if there was any included software on the drive itself. Maybe If I was lucky there would be random photos of factory workers testing the drives? Maybe I could find secret launch codes for Ballistic Nerf Missiles in the Southern Atlantic? Who knows what I could find?

I quickly fired up Virtualbox, setup the Fujitsu drive as a USB device for my Windows XP Virtual Machine and fired up. Upon checking the content of the drive, I was presented with… nothing. Nada. Zip. Zilch. Totally empty. What a disappointment.

I did a proper disconnect on the drive and shut Windows down. I then fired up GParted to repartition the drive for Ext3.

GParted reports the drive as only containing 302GB of physical storage space, which follows the whole 1,000MB versus 1,024MB in a GB debate that always surrounds drive sizes.

Repartitioning the drive into a single giant 320GB partition took just over 3 minutes to complete.

Turtle or Hare?

So let’s try some real-world file read/write tests.

I decided to go with the following basic tests involving the copying of data:

1. Copy from my desktop hard-drive to RAM
2. Copy from my desktop hard-drive to my aging Samsung 160GB IDE external USB notebook HDD
3. Copy from my desktop hard-drive to the Fujitsu Dynadisq III 320GB SATA external USB notebook HDD

Timing was done by hand with a stop watch from the triggering of the copy action to the closing of the file transfer progress window.

First up, let’s copy a single 2.2GB DV video file.

Figure 1: Time to copy a single large file

According to GNOME’s Nautilus, RAM was pulling a transfer rate of 85.4MB/s, the Samsung drive was pulling 30.2MB/s and our review Fujitsu was pulling 40.5MB/s – a notable difference over the Samsung.

Next up, we copy 7,762 small files all between 10K and 25K each (total 146.9MB) comprised of various image thumbnails:

Figure 2: Time to copy a series of small files

Nautilus didn’t have much time to evaluate the speed. RAM took less than a second to complete the copy, my Samsung drive took 3.65 seconds, and the Fujitsu took a paltry 2.98 seconds.

Finally, we go and copy 2,987 medium-sized files comprised of digital photos in various subfolders all between 250K and 1.5MB in size (2 megapixels max resolution).

Figure 3: Time to copy a series of medium files

Nautilus reported RAM pulling a transfer speed of 71MB/s, my Samsung drive did 32MB/s and the Fujitsu triumphed over the Samsung with 39MB/s.

So the Fujitsu shows an average 21% performance benefit over my little Samsung IDE unit. Not bad.

The Backup Button

Earlier I pointed out that there was a “Backup” button on the back of the drive labelled simply “Backup”. The intended use is to perform a one-touch backup of all your important data onto the external unit. Sounds great, except that it doesn’t work. Well, at least under Ubuntu it doesn’t work. The system does not recognise any press of the button – not even as a keyboard multimedia button.

The supplied CD-ROM contains the driver and backup application for use with the Backup Button, but unfortunately, it’s Windows only.

This is hardly a concern, though. You can easily throw an icon on your desktop to execute a script to backup all your important data and Linux in general has unparalleled methods for regularly backing up large volumes of data with ease, such as rsync.

Aesthetics

So what more can be said about this drive? Well, it’s quiet – barely a chirp from it. It also gets a little warm, but not overly hot when doing large file copies. No biggies.

It certainly looks like a nice unit – clean design, not trying to overtly stand out. The power and activity LED’s are non-intrusive as well unlike the bright blue LED’s you find on some units.

Probably the only real downer I can say about it is the juice consumption, but this is probably unavoidable, really. The main reason I still like my little 160GB IDE unit is that it is one of the last capacities to not really require additional power. Whilst conducting my tests on the Fujitsu, I did encounter moments where the drive was reporting back to the system hard-errors and at one point simply unmounted itself. Disconnecting and reconnecting it fixed these issues and a quick run of fsck showed that there were not any actual errors on the drive. Once I had hooked up the second USB power lead, the problems never manifested themselves again.

Conclusion

One of the main reasons people use notebook USB drives for portable storage is for their convenience. Not only for their size, but for the fact that you can do data and power over one lead. This one requires two for any major file operations, and while that may be an inconvenience for some, it’s still a helluva lot better than having to hook up a power brick to run a 3.5″ desktop drive.

SSD’s (and to a lesser extent, USB flash drives) are still a long way off from completely replacing hard drives, and at this stage are far more expensive GB for GB, so until then, this little drive suffices nicely. It’s small, tidy, fairly quick, had a good pouch which will offer some knock protection, and while not as small as a USB flash drive, it easily fits into most pockets.

All up, this is a drive worthy of notice.

Review score: 8 out of 10

Many thanks to fellow Ubuntu compatriot Blinky who supplied the unit for review.