RE: 3.10LTS ok for production?

["Paul B. Henson" <henson-HInyCGIudOg@public.gmane.org>]

> From: Matthew Patton [mailto:pattonme-/E1597aS9LQAvxtiuMwx3w@public.gmane.org]
> Sent: Friday, November 08, 2013 9:29 PM
>
> The following is opinion, MY opinion.

Noted; thanks for taking the time to share it :).

> I think that's hard to say. The .10 code wasn't re-worked like the .11
> branch and it may well have fewer issues than the .11 series.

There was a re-factoring between .10 and .11? I hadn't noticed that.
 
> Storage is the LAST place to cut corners. Unless of course your data isn't
> important, can be thrown away, or recreated without a lot of time and
> sweat.

Well, technically, this particular deployment is for my house ;), and while
I wouldn't really agree with any of those statements for my data, this hobby
box has already become ridiculously expensive, and I'd like to make the best
of the pieces I already have.
 
> Personally I think it needs another 3 months to bake, even in the 3.11.6
> guise.

Hmm, won't 3.11 be EOL before then? So presumably the result of that bake
time would be in 3.12.

> As to your specific example, are WRITE IOPs of critical importance? If
> not, just use WRITE-THRU and have the SSDs be a READ cache for hot data.
>
> There is no or almost zero risk to your data in that configuration.

Well, I don't know if I'd agree with that; bugs in bcache could result in
corrupted data being returned from reads or ending up on the backing devices
right even in write through, definitely less risk I would think then write
back, but none?

> Despite all the hand-waving by sysadmins, READ cache is far more useful as
> a practical matter than WRITE. If you have a heavy WRITE load, then there
> is no good solution that doesn't cost money.

Theoretically, caching the writes through the SSD should decrease latency
and turn random IO into a sequential stream for the backing device,
resulting in increased performance. Ideally, I'd like to avail of that :). 

> the alternative software solutions both of which are free: IOEnhance from
> STEC

It looks like they was some activity back in February about getting that
into the staging driver section of the kernel, but I don't see it there, and
I don't see any further activity, so not sure what happened there. I'd
prefer to use functionality in the standard kernel, as opposed to compiling
in outside stuff.

> the in-kernel MD-hotspot

Do you have a reference for that? I can't seem to find anything via Google.

> Failing that, shell out the money for a ZFS-friendly setup and abstract
> the storage away from your virtual machines. Indeed that's a much better
> design anyway.

I actually have a storage server sitting right next to the virtualization
server running illumos/zfs, with roughly 21TB of storage, which is going to
provide bulk storage, but I plan to have the vm operating system files and
smaller data on the virtualization server itself.

> Lastly maybe forget KVM/Xen and get VMware ESXi as your hypervisor.

We use ESXi at my day job, it's got a pretty good feature set, but I'm
trying to stick with open source for my home deployments...

Thanks for your thoughts.