Jim, more notes on optimizing a usb stick once it's been set up:<br><br>Some Optimizations for Linux Running on a 4G Flash Memory<br><br>(Summary of flash setup for 128k erase blocks: partition info is 4 heads, 16<br>sectors/track, start at sector 8192, to end, no swap, ext2 filesystem (4k<br>
blocks 32k groups (which are the defaults I think), install to the flash,<br>rejecting offers to repartition or format.)<br><br>Linux installations on flash cards or USB thumbdrives raise the issue of<br>longevity, since after some number of writes to a flash block, it wears out.<br>
Miminize these writes to flash by using ramdisks. Laptops these days<br>frequently have 2G-4G of memory, more than enough for typical useage. Using<br>a part of this ram for ramdisks mounted at locations of high write activity<br>
is a reasonable way to extend the life of the flash media.<br><br>With 2G of ram on my laptop, I create my (4G) thumbdrives without swap, with<br>no adverse consequences, but this is just a matter of not wasting space --<br>
my normal processing load does not use swap anyway. Two obvious locations<br>with high write activity are /tmp and /var/log. Putting the /var/log on a<br>ramdisk means that system logs would be dumped at each shutdown, so remember<br>
to save any logs needed for problem investigation. Since both of these<br>locations are used early in the boot sequence, getting them mounted as soon<br>as possible makes sense. Two lines in /etc/fstab will be all that is needed:<br>
<br>tmpfs /tmp tmpfs size=256M,mode=1777 0 0<br>ramfs /var/log ramfs mode=755 0 0<br><br>update-manager cannot see any space in /tmp with the ramfs filesystem -- a<br>problem (bug 495131) caused by the underlying os.statvfs function. Use<br>
tmpfs, even if there is no swap. I think the default size of the /var/log<br>ramdisk is 32M or 64M, which is more than sufficient for me, but df -a<br>reports 0 size, so it too seems to have a problem with ramfs. These are the<br>
only two programs I run regularly in which I have noticed any problems --<br>the system runs normally otherwise. Some applications (e.g. Postgresql ) may<br>have problems if their logs are in a non-existent directory. These problems<br>
may be addressed on a case by case basis, adding the appropriate directory<br>creations and ownerships to the /etc/rc.local startup file.<br><br>The directory that update-manager uses for downloaded packages may be moved<br>
to a ramdisk. With 256M in /tmp, just create a link from the<br>/var/cache/apt/archives directory to /tmp/debs. The existing archives<br>directory may be renamed or removed.<br><br> sudo mv /var/cache/apt/archives /var/cache/apt/archives-orig<br>
sudo ln -s /tmp/debs /var/cache/apt/archives<br><br>Finally, create the link target by add the below mkdir line to the end of<br>/etc/rc.local, just before the "exit 0" (since the /tmp ramdisk starts empty<br>
at boot).<br><br> mkdir -p /tmp/debs/partial<br><br>The /var/log ramdisk is remade from scratch at every boot. No problems were<br>noticed until trying to update/run postgresql-8.4, which needed a postgresql<br>directory which was not made on the fly. This fix consists of adding the<br>
directory creation to the rc.local file. Instead, I just removed Postgresql,<br>which is just used for a few demos.<br><br> mkdir -m775 /var/log/postgresql<br> chgrp postgres /var/log/postgresql<br><br>Another directory with lots of writes is my browser cache directory. A link<br>
from this cache directory to /tmp/Cache-username removes those writes from<br>flash, and speeds up browser performance too.<br><br> rm ${HOME}/.mozilla/firefox/xxxxx.default/Cache<br> ln -s ${HOME}/.mozilla/firefox/xxxxx.default/Cache /tmp/Cache-username<br>
<br>Create the link target target in /etc/rc.local:<br> mkdir /tmp/Cache-username<br><br>Gnome and various applications create/modify lots of files, so a more<br>radical step would be to move an entire user home directory to /tmp. Create<br>
a new user, e.g. guest, and login to the new account.<br><br> adduser guest <br> ...<br><br>Tailor the things you care about like the desktop, bookmarks, mail, ...<br>Assuming the guest user does not have sudo capability, logout, and log back<br>
in as your normal user, who does have sudo capability. Tar up the guest home<br>directory:<br><br> cd /home<br> sudo tar -czf /usr/local/guest.tgz guest<br> sudo chown guest:guest /usr/local/guest.tgz<br><br>Edit /etc/rc.local, to unpack the guest.tgz file into /tmp:<br>
sudo vi /etc/rc.local<br> # create the guest home directory in /tmp<br> cd /tmp<br> tar -xpzf /usr/local/guest.tgz<br><br><br>Finally, edit the /etc/passwd file and change the guest home directory<br>to be in /tmp:<br>
sudo vi /etc/passwd<br> ...<br> guest:x:1001:1001:Guest,,,:/tmp/guest:/bin/bash<br><br>Now reboot and try to login as guest. A pwd command at a terminal should<br>give you /tmp/guest. Browser performance should be good, but remember, no<br>
further changes to bookmarks, etc. will be permanent. Permanent changes may<br>be made by re-taring the /tmp/guest directory and replacing the<br>/usr/local/guest.tgz file. Of course, a file may still be copied to<br>/home/guest/... to permanently save it. If you do want to change the guest<br>
home directory, make changes immediately after logging in, to keep unwanted<br>temporary files out of the tarball. After running as guest for awhile, you<br>can see what files get created with a find command:<br><br> find . -newer ./.cache/notify-osd.log -ls<br>
<br>My typical browser/email usage for less than an hour resulted in 270<br>file creations/modifications, of which 180 were browser cache files.<br><br>links to permanent directories back in /home/guest may be added and the<br>
/tmp/home re-tarred to provide locations with persistance. Another approach<br>would be to login as guest, run xhost to allow some otheruser with $HOME on<br>flash to use the display, then su to this otheruser. This approach keeps a<br>
lot of the Gnome/app temporary files in memory instead of being written onto<br>flash.<br><br>As guest, use xhost to add username (or just open up the display to<br>everyone with xhost + ):<br><br> xhost +SI:localuser:otheruser<br>
su otheruser<br><br>Now run firefox from a command line, (ignore the error popup) and see<br>otheruser's bookmarks. Firefox is easy, but other X programs<br>(e.g. evolution) which rely heavily on Gnome's environment/sockets<br>
will need more work to run this way. The benefits are obvious --<br>the flash-access LED blinks far less often.<br><br>Duplicating one of these sticks is quick and easy with the dd program.<br>A stick to stick copy is possible, but I make a copy on a hard disk<br>
to allow faster copies on multiple sticks. Use the 128k erase block<br>size to write (read) to the sticks, and the number of writes should<br>match the partition information on the stick (1/4 the number of 32k <br>cylinders).<br>
<br> dd if=/dev/sdx of=file ibs=128k<br><br>Switch sticks.<br><br> dd if=file of=/dev/sdx obs=128k<br><br>I have been very satisified running my daily operations off a 4G stick for<br>the last few months. I still have some concern about how long the flash will<br>
last with this normal workload, but even so, I run update-manager ever few<br>days, so updates represent the heaviest write load on the stick.<br><br>Since hardware is expected to fail at some point, backup is not optional.<br>
Spinning metal platters are fragile too, a friend lost a Terabyte of his<br>data when he tipped over the external disk enclosure. My laptop has<br>developed a (motherboard?) problem seeing its internal (Windows) disk, and<br>
fails to boot with it present. Solution: remove the disk (which is good and<br>still accessible via a USB enclosure) and continue to use the laptop by<br>booting off Linux USB devices (it runs cooler now ;) ).<br><br>Ken Shaffer<br>
<br>