Optimizing Linux Use On a USB Flash Drive?

Buckbeak writes "I like to carry my Linux systems around with me, on USB flash drives. Typically, SanDisk Cruzers or Kingston HyperX. I encrypt the root partition and boot off the USB stick. Sometimes, the performance leaves something to be desired. I want to be able to do an 'apt-get upgrade' or 'yum update' while surfing but the experience is sometimes painful. What can I do to maximize the performance of Linux while running off of a slow medium? I've turned on 'noatime' in the mount options and I don't use a swap partition. Is there any way to minimize drive I/O or batch it up more? Is there any easy way to run in memory and write everything out when I shut down? I've tried both EXT2 and EXT3 and it doesn't seem to make much difference. Any other suggestions?"

Comments

Hrm.

[Creepy Crawler]

Well, the sucky thing about USB is it requires an inordinate amount of CPU. Normally this isnt a worry, but if you're using a encrypted loopback.. well ouch.

One thing you could instead use is the SD card slot and a USB loader. If you choose a 8GB class 6 SD card, you could have plenty of room for whatever, and 6MB/s minimum speed. You're still going to take the CPU hit for encryption, but that is your choice. The big thing is to stay off the USB.

Lightweight software && ssh -x

[Paradigm_Complex]

One thing I've found really, really helps is to use smaller programs et al. While the difference in how long it takes to start up gnome-terminal vs rxvt or nautilus vs pcmanfm is minimal on a normal/modern desktop or laptop, the difference is substantial on a cheap USB flash drive. There's plenty of lists for lightweight applications, window managers etc for linux around online. In fact, I'll often just stick with terminal applications (moc, for instance).

Another option, if you're booting on a box which has a good internet connection, is to ssh -X things over a network. Not only does this save a large amount of space, but I've found it's often faster to have a program like Firefox start on my snazzy box at home and ssh -X over than waiting for it to load off of my crappy usb drive.

USB1 vs USB2

[Mendy]

It might be that the poor performance occurs when you're on a computer that only has USB1 support. On Dells this was added later than you might expect.

You might find you got better performance if you were to use a CD to hold most of the static software and the USB for just your home directory.

optimizing Linux on USB: multiple angles of attack

[liraz]

I know a little bit about this because I am one of the developers for TurnKey Linux, a new opensource project which builds small installable live CDs (we're up to 9) optimized for various mostly server-related tasks. I've been investigating supporting live USB mode.

Your generic run-of-the-mill USB drive has about fourth-half the read/write performance of your hard drive nowadays (10-15MB/s). Since there are no moving parts (spinning platters), usually the seek times are very good.

There are several things you can do to optimize the performance of an operating system running live from a USB drive:

1) buy a faster USB drive: a good USB drive (e.g., Lexar JumpDrive) can have 2-3 times the performance of a generic.

2) Use a Linux distribution with a smaller footprint such as DSL (50MB) or Puppy Linux (standard edition is 68MB): the smaller the footprint, the less your drive has to read, the faster your system will load.

3) Try loading the operating system system into a ramdisk: many live USB distributions have the ability to load themselves into RAM. With some you have to add a cheatcode in the bootloader. Others do it by default if there is enough memory (usually not a problem with small distributions and modern computers).

4) Try turning on readahead: many distributions which are designed to run from a live CD or live USB have a feature that reads ahead various files important to the boot sequence sequentially. Whether or not this helps depends on the characteristics of the storage medium you are using, but you should investigate it.

Did you read the faq?

[agristin]

make sure you are on USB 2.0- interface can kill you.

Also did you check the faq-

No seriously:

http://www.linux-usb.org/FAQ.html#i5

especially the section on:

Q: What is max_sectors and how should I use it?

A:For USB Mass Storage devices (that is, devices which use the usb-storage driver) max_sectors controls the maximum amount of data that will be transferred to or from the device in a single command. As the name implies this transfer length is measured in sectors, where a sector is 512 bytes (that's a logical sector size, not necessarily the same as the size of a physical sector on the device). Thus for example, max_sectors = 240 means that a single command will not transfer more than 120 KB of data.

Try out different filesystems

[mbyte]

Try out different filesystems, NILFS seems to be optimized for FLASH usage.

Brtfs could also be worth a try.

use the "noop" IO/Scheduler with nilfs:
echo noop > /sys/block/sdX/queue/scheduler

Postmark benchs on an usb-stick (shameless copied from here:
ext3 (mount -o noatime,noadirtime, normale Partition, scheduler cfq): 49 Transactions/s
nilfs2 (Partition aligned 128k, scheduler noop, protection_period 10s): 588 Transactions/s

what I do

[ILuvRamen]

I have an old 10GB laptop drive inside of a very low profile USB enclosure and it runs like 35x faster than my USB drive or something absurd like that. It's a little more sensitive to bumps but it's not exactly expensive for 10GB drives. You can get a 6 pack of used one on ebay for about $3-7 each. Best of all, in a good enclosure, it still fits in your pocket.

busybox

[nategoose]

You might want to try replacing many programs as you can with busybox. It's versions of utilities are less complete than the standard gnu utilities, but they are all rolled into one binary, so most likely most of that binary will get cached in ram pretty early and stay there.
Also, for any packages you build you should try to use the -Os option for gcc, and perhaps even strip the binaries to remove unused symbols and debug info.
Building the system as though this was an embedded system with a small disk should be a win in most cases since fewer things have to go over the wire to load a file and more of the binaries can fit into cache.

Dave Jones suggestions for the eee900 might help

[Mr Z]

Dave Jones recently posted elsewhere his notes for improving things on the eee900. Several of the steps focus on getting proper performance out of the flash, and so would also apply to booting from a USB thumb drive or other flash media. Here's what he had to say:

Making the eee 900 series suck less.

Recently I've read about or spoken with a few people using Fedora on eeepc's who have been making some fairly big blunders without realising it. I've played with a few of these now, in their various incarnations.

The current one I've been carrying around is the 900 model with a whopping 20GB of flash. It's quite deceptive, because there are actually two SSDs in there (one 4GB, and one 16GB)

These ssds are also pretty damn awful performance-wise compared to the newer generation of SSDs, but short of opening it up and retrofitting something, there's not much that can be done. The tips below should at least make it more bearable.

• First off, don't use the default partitioning scheme.

  By default, anaconda will choose to use lvm, and make a contiguous volume out of the two SSDs. This idea is fail, because the two disks aren't the same, and run at different speeds.

  # hdparm -t /dev/sda

  /dev/sda:
  Timing buffered disk reads: 108 MB in 3.04 seconds = 35.57 MB/sec

  # hdparm -t /dev/sdb

  /dev/sdb:
  Timing buffered disk reads: 86 MB in 3.05 seconds = 28.20 MB/sec

  So, don't do that. Just create regular partitions, and make sure you put / on the faster of the two disks (the 4GB one), and leave the 16GB one for /home

• Next, the default filesystem will be ext3. You really don't want this.

  Given the journal is in a fixed location on disk, scribbling to it every time a file gets written is a great way to wear out the flash. Go with ext2. (Given that you've only got a few GB of flash anyway, a fsck doesn't take that long should you need to). Additionally, not having to write to the journal means that you're doing less IO, which is obviously a win when it's on such slow media.

• This should go without saying - no swap.

  Not only for the flash wear problem in the previous bullet, but also, because it's slow as all hell. If you find you run out of ram and get stuff oom-killed in this setup, well, you probably need to add more ram, or consider a real laptop.

• After installing, change the fstab so that everything gets mounted with noatime.

  Writes to the disk are just painful, so minimising them is the path to success here. It's doubtful that you'll be running anything on an eee that would actually care about atimes anyway.

With these points taken into consideration, the eee isn't a half-bad machine. I still wouldn't want to be building kernels and such on it, but it's perfectly usable for email and such whilst travelling.

Re:Get a swap partition

[Mr Z]

Method doesn't work when improperly implemented. News at 11.

My point is that this seems to be more prevalent than people realize.

You're basically saying that wear-leveling is no panacea, because not all devices have a good wear-leveling algorithm. Wouldn't the solution, then, to be to demand devices which have a good algorithm, and to reward manufacturers who solve this problem with dollars and word of mouth?

The problem with short product lifecycles is that you might not realize you bought a turd until after it eats your data, and there's no time for word-of-mouth to spread. And with so many no-name USB sticks out there, how can you really tell which ones are the turds and which ones aren't? There really isn't a good feedback mechanism here. You have some hope paying high dollar for a name brand, but I wouldn't put too much stock in it.

Also, there are conflicting product goals: Dynamic wear leveling, as described in the PDF I linked above, gives faster write performance. Static wear leveling gives longer silicon lifetime. Which algorithm will generate better word of mouth? It's not clear, although I suspect faster write performance will generate better word-of-mouth while the product is still on store shelves.

Of course, the sad part is, the devices would probably be simpler, and cheaper to manufacture, if they didn't pretend to be block devices. Only problem is, then OSes (probably filesystems) would have to implement wear-leveling on their own, and Linux is the only one I know of which currently does that.

You would have to expose a number of low-level details, such as erase block size and other aspects of physical organization to the OS. And, you'd have to teach many OSes about how to talk to you, such as "block erase takes 5ms; device is unresponsive during erasure". Until there's a standardized way of doing this across platforms, faking yourself as a block device is an easy way to get broad compatibility with anything that understands the USB storage device (or SD card, or whatever format you're working with) profile.

Still, it would be nice if we could fix that problem in software, rather than letting manufacturers get it wrong.

You can still implement software wear leveling over the abstracted interface. Unless the device actively tries to work against you, it should help.