Optimization for USB based FreeBSD installations

[ronaldlees]

I've gotten rid of most of my hard drives. I run FreeBSD, and other operating systems only from my thumb drives. I guess this forum is more about asking questions, rather than giving out unsolicited information. Yet - I think other USB'ers may find this little configuration detail to be useful.

I usually run the Chromium browser on the thumbdrive based systems. When I first started using Chromium on a stick, I found I could not view YouTube movies. After some fuss, I eventually discovered that the latency of the USB stick was the problem. I found that the only way I could view movies on the stick was by creating a memory-based-disk backing for the .cache directory that Chromium uses to hold buffered video.

md      /usr/home/joe/.config   mfs     rw,-s100M,nosuid,noatime        0      0
md      /usr/home/joe/.cache    mfs     rw,-s300M,nosuid,noatime        0      0

The downside of the memory-based-disk is that .config gets reset every time I restart the machine. I guess that could be an advantage if I wanted every browser startup to use the default settings, but I made a little script that copies the configuration I want from .savedconfig/* to .config/* when I launch the browser. Additionally, I have a script to set non-root permissions on all of the configuration and cache files, etc.

One thing I'll say about running on sticks, is that every three or four months I "semi-brick" them (turn them into read-only devices containing data of questionable integrity) or "brick" them (make them inaccessible). I think it usually happens when data is being written and there is a power interruption. I've seen utilities that claim to be able reset the stick's original state (firmware reset), but have never trusted the source sites where I found them :\

I do have a question, come to think of it... The use of a home directory for an fstab mount seems awkward. What would be a better approach?

 

[ronaldlees]

I guess I could symlink it to /tmp or something, since /tmp is already a memory-based-disk on my thumbdrive. I just have to increase the size to a half Gig gigabyte or so...

 

[kisscool-fr]

If I remember well, you can specify to Chromium a different directory for its cache, so why not create a memory based disk only for Chromium's cache and point Chromium to that directory?

 

[ronaldlees]

@kisscool-fr: Thanks! I think I remember reading such a thing. Chromium has so many switches that it boggles the mind. Many have names similar to others, which is frustrating in terms of knowing which to use. The cache-dir option could be the way to go, since I'm the only one who uses this stick, so putting it all in /tmp should be OK.

 

[trh411]

Thanks! Yes, I think I remember reading such a thing. Chromium has so many switches that it boggles the mind. Many have names similar to others, which is frustrating in terms of knowing which to use. That specified dir approach seems like the way to go, since I'm the only one who uses this stick, and putting it all in /tmp should be OK.

Now I have to find that switch...

Maybe --disk-cache-dir is what you're looking for? For reference see: List of Chromium Command Line Switches.

 

[SirDice]

I guess I could symlink it to /tmp or something, since /tmp is already a memory-based-disk on my thumbdrive. Just have to increase the size to a half Gig or so...

I'd use tmpfs(5) for /tmp, it can adjust its size dynamically.

 

[ronaldlees]

I guess I could symlink it to /tmp or something, since /tmp is already a memory-based-disk on my thumbdrive. Just have to increase the size to a half Gig or so...

I'd use tmpfs(5) for /tmp, it can adjust its size dynamically.

tmpfs: that sounds like the best bet yet. I originally had set the fixed-memory-disk size to 50M 50 MB - and subsequently it ran out of space, causing a system panic, and bricking one of my USB drives. Bumping the size up to 300M 300 MB seemed to take care of things, and I watched hours of movies with no hitches. The tmpfs could save a little memory on my machines. Thanks @SirDice!

I suppose that even a fairly large fixed-memory-based disk could fall short of demand, so using tmpfs potentially could save me from having to deal with any more bricked USB thumbdrives! I'll give it a try.

 

[ronaldlees]

Thanks! Yes, I think I remember reading such a thing. Chromium has so many switches that it boggles the mind. Many have names similar to others, which is frustrating in terms of knowing which to use. That specified dir approach seems like the way to go, since I'm the only one who uses this stick, and putting it all in /tmp should be OK.

Maybe --disk-cache-dir is what you're looking for? For reference see: List of Chromium Command Line Switches.

Thanks for the Peter Beverloo link. Have you ever seen such an options list like that one?!

 

[Beastie]

memory-based-disk backing for the .cache directory that Chromium uses to hold buffered video.

The downside of the memory-based-disk is that .config gets reset every time I restart the machine. I guess that could be an advantage, but I made a little script that copies the configuration I want from .savedconfig/* to .config/* when I launch the browser.

Even though I'm not using a USB-based system, I've been doing this for many years. Most of my partitions are read-only. Only /var and /home are mounted read-write. /tmp is memory-based (tmpfs(5)) and all cache directories (not just for browsers) are symlinked to /tmp.
For browsers, the entire profile directory is regenerated on every run:

• create a directory hierarchy in /tmp that mirrors the targets of symlinked directories.
• extract configuration from a compressed archive to the above hierarchy
• launch application

 

[ronaldlees]

I've changed my setup to use a tmpfs mount, and so far it's doing OK with the video feeds. I noticed that the default tmpfs mount configuration uses a cap equal to half the memory.

One thing I try to remember when using the USB thumb-drives for regular computing - and that is to NEVER store anything important on them. A panic - for any reason - could put my data at risk. There's some level of risk associated with running sticks, but I like the flexibility of having my system with me all the time, and using it wherever I want, on whatever I want. Plus, the security (physically in my pocket) is nice.

I can't believe I've used FreeBSD so many years, and never made use of tmpfs before. :\

Another thing I need to do is use the Chromium --disk-cache-size option to make sure the cache will fit inside my tmpfs! Apparently, according to a bug related post I read somewhere (I don't know if this has been fixed or not)) - it'll grow forever otherwise!

Hopefully, the --disk-cache-size option also controls the video buffer cache. Anyone know for sure?

Beastie: I wish I wasn't too lazy to do it your way!!

 

[Beastie]

I noticed that the default tmpfs mount configuration uses a cap equal to half the memory.

I'm pretty sure it doesn't cap it by default, and uses all the available virtual memory (i.e. all free physical memory and swap space).

I wish I wasn't too lazy to do it your way!!

It's mostly just a bunch of scripts tailored to each application.

 

[ronaldlees]

I don't know how popular it might be for people to install "daily use" operating systems on USB thumb-drives, and then carry them (securely) in their pants pockets. These days, it seems the prudent thing to do. So, I'll add another tidbit related to the way I set the things up.

I like to keep an archive of pre-configured-live OS images on a USB thumb-drive that is separate from my daily operations "live/web enabled" thumb-drive, such that I can use the " dd" utility to "ghost" a nice clean image onto the latter - whenever I feel I've been someplace low on my list of "safe" places to go (i.e., when I've been potentially compromised). I see the prudence in this idea of, every so often, "laundering the drives"

I have an archive of a half dozen or so of my favorite operating system images on this dedicated OS image thumb-drive.

Everyone knows that using dd to ghost a thumb-drive is a very time consuming operation. So, I construct the "prebuilt" archive images so they are as tiny as possible, while still having the minimal set of apps (web browser, etc) installed, by using the file-system size option with newfs. I usually have one big partition, and I like that. After using dd to copy the much reduced image to the USB thumb-drive, I use the gpart and growfs utility to grow it back out to the full capacity of the disk. This reduces the time it takes for dd to copy the image, by two or three times:

gpart resize -i 1 [u]my slice[/u]
growfs /dev/[u]my partition[/u]

Of course, different commands and syntax apply on non-FreeBSD systems.

Because the thumb-drives occasionally brick themselves, due to the way the NAND flash controllers do not show much resilience during and after power crashes, I keep a third thumb drive, onto which I store any important information that has accumulated on the live disk. I consider anything I leave on the live drive to be expendable. Does anybody else do this kind of thing?