Slashdot Mirror
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?"
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.
"A witty saying proves nothing." - Voltaire
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.
Well, laptop mode's an obvious. However, I would not enable swap at all, or at least put it on the FS somewhere. If you do that, you wont be able to hibernate properly. Nor will hibernation work properly if you encrypt swap (partition).
You're looking at standby or poweroff events due to encrypted partitions and systems. That's the pain you pay for. There is another way... TCPA, and IBM has writen the requisite linux tools to utilize it properly. Just everybody's too scared to use it properly.
Most USB flash drives are very slow, and rely on heavy cacheing to make them usable. That doesn't help when you need to write large amounts of data (ie. in an apt-get update/install).
Some flash drives that advertise themselves as 10-15MiB/sec write capable peak out at only 1 or 2, and even less with small-block random I/O (since the erase-write cycle operates on relatively large blocks).
Several vendors make specialized flash drives that are somewhat more expensive (ie. 20-50% over average), but perform much better.
One is here: OCZ Turbo USB 2.0
A government is a body of people notably ungoverned - AC
Or on a mostly-Windows machine, you can always use a local-drive-based swapfile (there's likely no swap partition). Mount NTFS drive, create a "myswapfile" somewhere innocuous, mount it as a loopback swap partition (-o loop). Delete it on unmount (as part of your shutdown process) -- if you're truly paranoid you can even take the time to scrub the sectors your swap was using.
Don't swap to the flashdrive -- you'll just hog USB bandwidth that you need for reading & writing real files off your root partition.
Wow - it seems like you're the only person that has actually posted the correct information. ext is the wrong filesystem to use on flash & noop is a much better scheduler for flash.
Do you have any numbers on just noop vs cfq when the same file system is used on a USB stick?
Do you really need to encrypt everything? Why don't you create a separate partition for your /home (and /var /etc and /tmp if you really want to); encrypt that/those but not the rest. I can't see why there'd be anything confidential about what's in all other directories, especially since almost all the rest is probably open source anyway.
Method doesn't work when improperly implemented. News at 11.
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?
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.
Still, it would be nice if we could fix that problem in software, rather than letting manufacturers get it wrong.
Don't thank God, thank a doctor!