On Wed, Aug 27, 2014 at 4:12 PM, Matt <matt.mailinglists at 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. -- ---~~.~~--- Mike // SilverTip257 //