On 2012-10-02, John R Pierce pierce@hogranch.com wrote:
a server makes very little use of its system disks after its booted, everything it needs ends up in cache pretty quickly. and you typically don't reboot a server very often. why waste SSD for that?
I think the impetus (which I wasn't totally on top of) was to maximize the number of drive bays in the controller node. So the bays are 2.5" instead of 3.5", and finding 2.5" ''enterprise'' SATA drives is fairly nontrivial from what I can tell. I don't actually need 8 2.5" drive bays, so that was an oversight on my part.
After reading the SSD/RAID docs that John Doe posted, I am a little concerned, but I think my plan will be to use these disks as I originally planned, and if they fail too quickly, find some 2.5" magnetic drives and RAID1 them instead. I may also end up putting /tmp, /var, and swap on the disk array instead of on the SSD array, and treat the SSD array as just the write-seldom parts of the OS (e.g., /boot, /usr, /usr/local). If I do that I should be able to alleviate any issues with excessive writing of the SSDs.
I am not sure what drives I have, but I have seen claims of "enterprise" SSDs which are designed to be up 24/7 and be able to tolerate more writes before fatiguing. Has anyone had experience with these drives?
re: alignment, use the whole disks, without partitioning. then there's no alignment issues. use a raid block size of like 32k. if you need multiple file systems, put the whole mess into a single LVM vg, and create your logical volumes in lvm.
So, something like mkfs.xfs will be able to determine the proper stride and stripe settings from whatever the 3ware controller presents? (The controller of course uses whole disks, not partitions.) From reading other sites and lists I had the (perhaps mistaken) impression that this was a delicate operation, and not getting it exactly correct would cause performance issues, possibly set fire to the entire data center, and even cause the next big bang.
--keith