On Sat, Apr 11, 2015 at 2:03 PM, Brandon Vincent
<[log in to unmask]> wrote:
> On Sat, Apr 11, 2015 at 4:18 AM, Vladimir Mosgalin
> <[log in to unmask]> wrote:
>> Otherwise you're going to live with eventual performance degradation,
>> because hardware controllers (at least LSI and Adaptec) do not support
>> TRIM for drives in RAID.
>
> This is not correct. LSI SAS2008 I/O controllers do support TRIM with
> drives that support both deterministic trim (DRAT) and deterministic
> read zero after trim (DZAT).

Just a heads up, one I try to insert early in conversations about
RAID. RAID is not backup. If you're relying on RAID1 or RAID10 to
provide fallback, or failover capacity, I'll urge you to think first
about genuine backup. This is because it's far, far, far more common
to fatfinger a command and accidentally delete files you care about
than it is to have a reasonable quality drive of any sort fail.

If you're actually dealing with multiple drives that you need to treat
as as a shared space for a single application, yeah, that can be
needed. But for *most* of us, it can be much easier and safer to
simply use the drives, as is, create file systems on them, and symlink
components of those filesystems together. Rather than making my /
partition oversized on a large RAID array, for example, a bit of
thought can often segregate out bulky contant, such as databases or
rsync mirrors, to another drive. And if you're dealing with something
that needs, say, 2 TB of space, it can be critical to segregate that
from the rest of your operating system. Saying "Oh, I only need 10 Gig
for my OS, there's plenty of space on that 2 TB array for my OS" leads
to accidents where whatever generated that 2 TB makes 8one* mistake
and blows away that margin.

I've had that argument repeatedly: "We have 2 TB of space, and 20 gig
left, and we only produce 1 Meg per day: we have 60 years left" was
actually presented to me as a reason to tune the monitoring to ignore
the problem. And, of course, it blew up and took out "/" and critical
databases with it when a broken component started spewing error logs,
filled the disk, and corrupted a critical database.