Install entire FreeBSD 8.1 filesystem on Flash?

Greetings all,

inspired by several contributors (phoenix, vermaden), running part of the OS from flash, I decided to attempt the same in my upcoming update from 7.1 to 8.1. My initial idea was to use two mirrored 4GB CF USB drives - 512MB for / and 3.5GB for /usr. Visit to my local Fry's revealed a sale on 8GB Patriot CF USB, making them cheaper than any of the 4GB versions sold.

I am now wondering, if it would be advisable to install additional file-system/var, /tmp, swap on the CF. My concern stems from the fact that unlike the / and /usr, which are fairly static, the remaining file-systems are dynamic. Consequently, I am worried about:

1. the speed of the USB interface compared to the SATA interface;
2. the potential errors due to repeated read-write to the CF, which, as I understand will eventually occur.

I would appreciate any comments from anyone familiar with these issues.

Kindest regards,

M
 
If possible, you want to limit the number of writes to flash media. MLC-based flash (most USB sticks, CompactFlash, consumer SSDs) is good for around 10,000 writes per cell; SLC-based flash (enterprise SSDs) is good for around 100,000 writes per cell. On larger (32 GB +) flash media, this isn't too worrying, as you can write a continuous stream to the disk for about 3 years without wearing it out. For smaller media (1-16 GB), this can be worrying, as you can wear it out in under a year.

Thus, for an 8 GB flash media, you should try to avoid /tmp, /var, and /home, if possible. /tmp and /var can be made memory filesystems (see tmpmfs and varmfsp in /etc/defaults/rc.conf), although it would be better to have /var be a real filesystem, otherwise you'll lose /var/db/pkg on every boot.
 
I'm working on a similar configuration for a machine that has onboard flash on the motherboard. I'm going to use NanoBSD for my project without the "nano" part. It will basically be a full OS install, but using the configuration of Nanobsd to keep the main OS read-only and make small ram disks for runtime. Might not work for your needs, but take a look at it!
 
I have DragonFlyBSD on my netbook (eeepc/HAMMER fs) with ssd (4+16GB) - earlier I had FreeBSD (with UFS).
Speed&performance is OK. No problem while compiling apps from pkgsrc or ports

Since ssdrives are cheap then no need to worry about its usage (remember to backup your data!).
 
klanger said:
Since ssdrives are cheap then no need to worry about its usage (remember to backup your data!).
I'd still recommend putting at least /tmp and /var/tmp (symlink to /tmp) on a ram disk. No need to hold on to clutter and ram is even cheaper ;)
 
Dear phoenix, SirDice

thank you for the reply. If I understand correctly, propose to install just the / and /usr on the CF. Use tmpfs for /tmp and install /var on a hard-drive. Sorry for failing to mention it in the original post, but the /home and all the other data were always intended to be on the hard-drive. My motivation was to place all OS related files on the CF thus separate the OS from the /home and other data for easier re-installation/upgrade. You have not commented on swap, but since swap also writes to the CF, it should, by following your logic, be on a hard-drive, correct?

Dear Sylgeist,

thank you for the reply, it is an interesting concept. But, my motivation was to utilize the entire CF.

Dear klanger,

thank you for the comment regarding the speed.

Kindest regards,

M
 
mefizto said:
My motivation was to place all OS related files on the CF thus separate the OS from the /home and other data for easier re-installation/upgrade.

You can do that if you really want to. Just be sure to enable tmpmfs in rc.conf so that /tmp is a RAM disk. And you may want to go through /etc/syslog.conf to turn down the amount of logging that happens to /var/log. Or, if you really don't need that info saved, create an mfs (RAM disk) for /var/log.

You have not commented on swap, but since swap also writes to the CF, it should, by following your logic, be on a hard-drive, correct?

Swap really shouldn't be on flash. If you use swap a lot, it will wear out the flash. However, if you rarely end up using swap, you can put it on the flash as a just-in-case.
 
You may not use swap at all, if you have a lot (1GB or more) of RAM, but it is not recommended.
All my BSD setups (FreeBSD & now DragonFlyBSD have no swap, and only while cleaning up HAMMER system uses all of its RAM but still fells very responsive).

I had Freebsd even on 4 GB SD card (slow) & PC-BSD/DesktopBSD on very slow 8GB usb-stick.
Once your system is booted and few apps loaded it runs with normal speed (don't know why). But when it is on netbooks integral ssd it is a rocket (have in mind that I'm talking about very low power/budget netbook - eeepc 900 MHz.
 
Dear phoenix,

thank you for the qualification. I think that I will not complicate things and just install / and /usr on the CF, and the rest on the hard-drive.

Dear klanger,

I am very confused about the need for swap. Some articles agree with your suggestion of not using swap, other recommend swap at least the size of RAM, regardless of the amount of RAM. I am planning on 4-6GB RAM.

Kindest regards,

M
 
If you want to be able to dump the contents of RAM when the kernel panics, in order to help debug the crash, then you need swap slightly larger than RAM.

If you want to be able to keep the system running when a process goes out of control, using up memory, then having swap helps (increases the amount of virtual memory a process can use before crashing the system).

If you want a little bit of wiggle room (load more apps than you have physical RAM for), then you want swap.

IOW, you generally want at least 1-2 GB of swap space available, just in case. :) In a perfect world, you would never need to use that swap space, but it's always nice to have it. Kind of like seat belts. :)
 
Dear phoenix,

this is the first explanation that - for simpletons like me - makes sense.

Thank you,

M
 
klanger said:
You don't need swap at all, if you have a lot (1GB or more) of RAM.
Even with enough ram turning off swap completely is detrimental for performance. Modern OSs need at least some swap. It's even mentioned in tuning(7).

It is not recommended that you configure any less than 256M of swap on a system and you should keep in mind future memory expansion when sizing the swap partition. The kernel's VM paging algorithms are tuned to perform best when there is at least 2x swap versus main memory. Configuring too little swap can lead to inefficiencies in the VM page scanning code as well as create issues later on if you add more memory to your machine.
 
You may not use swap at all, if you have a lot (1GB or more) of RAM, but it is not recommended.

OK, I've changed my previous post.

I have a netbook with ssd - swap is also not recommended on ssd, so I don't use it since I don't have an option (hd drive just for swap) :D
 
Dear SirDice,

thank you for the reference to tuning(7). Referring to the text:

Finally, on larger systems with multiple
SCSI disks (or multiple IDE disks operating on different controllers), we
strongly recommend that you configure swap on each drive. The swap par-
titions on the drives should be approximately the same size. The kernel
can handle arbitrary sizes but internal data structures scale to 4 times
the largest swap partition. Keeping the swap partitions near the same
size will allow the kernel to optimally stripe swap space across the N
disks.

do I read it correctly that if I want 4GB swap, and I have two disks in mirror, I need 2 GB swap on each disk?

Thank you,

M
 
SirDice said:
I'd still recommend putting at least /tmp and /var/tmp (symlink to /tmp) on a ram disk. No need to hold on to clutter and ram is even cheaper ;)

It's my understanding that /tmp is for truly temporary files that don't need to survive a reboot and can reside on a volatile filesystem, while /var/tmp is for temporary files that should be kept through reboots. /var/tmp isn't symlinked to /tmp by default.
 
True, but you still can do it because you don't absolutely need those files in var's tmp directory.
But you could as well keep them both on the flash, especially for a desktop-oriented live system. On my desktops, both directories contain empty directories, and a few lock files, sockets and fifos. I doubt these will kill the flash cells.
 
hmmm this is an interesting post for me.

I'm making plans to create a picture frame out of old laptops using minimal install of FreeBSD.

The setup, if built, would run the following:

ssh (for remote access to the picture folder)
pf
x11/xorg
graphics/feh - the one doing all the heavy lifting of displaying pictures for, well, the picture frame :D
deskutils/remind - maybe some sort of alarm
multimedia/mplayer - play some audio files.
and any other ports that are necessary to make the above possible.

It may also run some scripts (deskutils/conky or echoing to transparent x11/rxvt-unicode) fetching and displaying messages (maybe some particularly formatted email messages or other simple text files or maybe the weather). Any unnecessary functions or hardware would be removed; all I would want would be the internal board and the LCD screen but wouldn't want the keyboard or even the casing in favor of a picture frame. I also would customize the kernel to make it smaller.

I COULD use the old hdd that comes with it, but opted instead to do away with moving parts to decrease noise and heat and either use a usb memory stick or other form of memory storage device. With such specific set up, would I need to have swap or worry about /var and /var/tmp being lost on reboot? The laptop, at best, would hold couple hundred megabytes of ram, maybe not even a hundred in some case.
 
For that use, you may be able to do without x11. You do not need a window manager, and there are a number of ports that can display images and video direct to the display from the console.

Yes, use flash for the permanent storage, and follow the instructions for a read-only root. You do not need to preserve /var and /tmp.
 
Looks like it.
I'd consider swapping on flash to be a no-no. Give it enough memory so it does not need to. Mind you, flash drives' write performance and longevity are much better these days.

Making the system drives read only makes the thing more of an appliance.

Here's a silly idea i just had: Get it running as you like, hibernate, and keep the hibernate image read-only. Could make for near-instant turn-on. Don't have a clue how to achieve that, though.
 
so to be clear:
no entry of swap in fstab whatsoever
and put /var and /tmp on a tmpfs
and put / read-only or not depending on use

I am trying to make the system into a picture frame with perhaps additional function of playing music or movie clips or fetching text strings to display them perhaps using sysutils/conky. For such use, I hoped read-only / with read-write /usr might do the job, sort of like setting up a jail with read only root.

about hibernate, well, you lost me on "hibernate" haha I never hibernated my computer and wasn't even aware the FreeBSD could do that haha. Can anyone give me pointers on hibernation, and, well, us on how to make that into an image if such is possible? I'm going to guess that it's probably not but, well, if possible, who wouldn't want to use insta-boot regardless of the setup :D
 
jem said:
It's my understanding that /tmp is for truly temporary files that don't need to survive a reboot and can reside on a volatile filesystem, while /var/tmp is for temporary files that should be kept through reboots. /var/tmp isn't symlinked to /tmp by default.
Could I get someone else's opinion on this? I'm trying to decide whether to snapshot /tmp and /var/tmp for purposes of backing up. Do either of those need to be backed up?
 
At least /tmp has always been for temporary files that do not need to survive a reboot. The other one /var/tmp is more fuzzy because there's no good standard of what it's supposed to be used for. On some systems /var/tmp is just a symlink to /tmp.
 
carlton_draught said:
I'm trying to decide whether to snapshot /tmp and /var/tmp for purposes of backing up. Do either of those need to be backed up?
/var/tmp has the vi.recover directory which stores vi(1) recovery files (see the man page) and needs to exist with specific permission and ownership settings.
Other than that, both /tmp and /var/tmp are filled with application-created directories, sockets, fifos and lock files that can be liberally discarded.

/tmp can indeed be mounted on a memory disk media. I personally don't because I store "semi-temporary" data that I don't want in my home directory.

So do what you want with /tmp. As for /var/tmp, why not simply back it up as part of /var?
 
Thanks guys. I think what is necessary is to have some sort of separate "scratch pad" area of filesystem that if it gets snapshotted, is only done via FIFO, for example, not grandfather-father-son. Maybe not even snapshotted. In that way, /tmp and /var/tmp will remain small and can be backed up/snapshotted with the rest of the root mirror.
 
Back
Top