On Wed, Aug 27, 2014 at 4:12 PM, Matt matt.mailinglists@gmail.com wrote:

...

...

I noticed that the Supermicro X9SCL has a USB type-a port right on the motherboard.

http://www.supermicro.com/products/motherboard/Xeon/C202_C204/X9SCL.cfm

Has anyone used a port like this to boot the core OS and used the physical drives for OpenVZ and KVM containers? I figure a 64GB thumb drive would work. Anyone done this or will a USB thumb drive not stand up too the load? Seems much easier then using a SATA SSD drive but I imagine you still have to find a more durable USB drive.

works great with VMware ESXI, or FreeNAS... neither of those treats the boot device as a read/write file system. FreeNAS does have one master configuration file it updates when you make configuration changes, but no operational data is written to it.

Hmm, my CentOS install is still do some log file writing. Most of the traffic is on /vz though. Wander how much a USB thumb drive can take?

Some manufacturers may release MTBF specs ... as with anything, not all do. And whether or not we can trust those specs is another thing.

Know of any better ones?

Even if you chose the "best" and possibly "most expensive" flash drive, I'd still tune the setup for flash memory. Back up what's on flash (probably just /etc and wherever else you modify) either regularly or whenever you change it. Not too hard, right? ;-)

You might take some info from Voyage Linux (intended for running on embedded boards using Compact Flash cards, ex: PC Engines ALIX, Soekris, etc). 1. file systems (on the flash device) are mounted read-only most of the time 2. tune file systems (on the flash) not to do a mandatory fsck every so many mounts 3. ...your job to research from here...

Remember that bash will want to log history to /home or /root depending on who you're logged in as. So a few writes there.

My suggestions: No swap on the USB flash. Put /var on your conventional storage (and not on the USB flash). So that would encompass /var/log and /var/spool for example. /tmp also takes occasional writes, so you might use tmpfs (RAM) or toss that on your conventional drives.

Ideas: Create your hardware or software array. Lay LVM over top the array. Allocate some space to /var and some amount to /vz. (Though I'd imagine you could use LVs as backing with OpenVZ just as some of us do with KVM.)

If you intend on using XFS for /vz, I'd say be conservative and leave free extents in the LVM VolumeGroup (at least until you get things as you want them). That way you can add space to /var in an emergency. You can't shrink XFS file systems, but you can shrink with ext3 or ext4.