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.