On Wed, Aug 27, 2014 at 4:12 PM, Matt <matt.mailinglists@xxxxxxxxx> 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 //
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
