2

Brief question about partition layout. I use an SSD for /, /boot, /usr, & /home partitions. I'd like to move /var to a mechanical disk to minimize writes to the SSD. I'm mainly concerned about maximizing drive life rather than maximizing performance (although I obviously wouldn't want to cripple my server).

My mechanical disks consist of two drives sharing LVM, and a third used for nightly rsync backups. I also have a bunch of old 2.5in hard disks lying around.

My question is, should I simply create a new LVM volume '/var' on my primary data store, or would it be worth the increased energy consumption (in terms of maximizing the lifetime of the LVMed drives) to install a low volume 2.5in disk to use just for /var?

On a more general level my question is about the trade offs of placing OS mounts on the same physical volumes as my data. Thanks for any help!

  • 2
    What's your write-MB/day to /var? – Chopper3 Mar 14 '12 at 16:46
  • I'll have to check tomorrow, as I haven't been keeping track lately. Right now it totals at 1.3 GB. If possible I'd like to know all my options, since as I build more services onto the server I assume my mb/day will increase. – Tammer Ibrahim Mar 14 '12 at 16:54

2 Answers2

3

1.3GB/day isn't a lot of data. Intel rates the Intel 320 series of SSDs for 20GB/day of 4k random writes for 5 years (Intel 320 Spec). 4k random writes represents a worst-case scenario for flash write/erase cycles, and for standard workloads you're pretty unlikely to be hitting that consistently, so your actual lifetime will be somewhat better.

Other SSDs may differ here, but in general I wouldn't worry about that kind of write level assuming you're using a modern SSD.

You can also check your SSDs reported wear level, to get a better understanding of how long it will last. I posted here on how to check this with Intel SSDs. Other controllers will report different attributes, but all modern SSDs report the same data in one way or another.

Many modern SSDs controller chipsets also do compression, which will further increase your write longevity, assuming compressible data (most things in /var, such as logfiles, will compress reasonably well)

As an example, here is some of the output from smartctl run on Sandforce based OCZ Vertex 2:

  9 Power_On_Hours_and_Msec 0x0032   100   100   000    Old_age   Always       -        8298h+23m+00.940s
231 SSD_Life_Left           0x0013   087   087   010    Pre-fail  Always       -       0
233 SandForce_Internal      0x0000   000   000   000    Old_age   Offline      -       30272
234 SandForce_Internal      0x0032   000   000   000    Old_age   Always       -       124672
241 Lifetime_Writes_GiB     0x0032   000   000   000    Old_age   Always       -       124672
242 Lifetime_Reads_GiB      0x0032   000   000   000    Old_age   Always       -       3136

I put it into this machine just under a year ago, which correlates with the power on hours figure fine (345 days). This drive has done 124672GiB over 345 days, or around 361GiB/day. The SSD internal wear counters are at 87% - so after nearly one year of operation, it has worn down around 13%.

This is probably very compressible (RRD data, starting with empty datasets so a lot of highly compressible RRDs). My understanding is that attribute 233 is the volume of "actual" data written to the SSD, and 234 / 241 are the "uncompressed". This would mean it's actually done 30272 GiB of writes, which is around 87GiB/day.

(As an aside, both of these figures seem a bit high to me, but my OS-level monitoring reports a consistent 4.5MiB/sec write to these drives, which is pretty close to 360GB/day, so it adds up ok. Pretty unlikely for the linux kernel and the drive controller to both get it wrong in exactly the same way)

It'll depend a bit on your SSD and your specific workload, but I don't see any particular need to move /var off your SSD.

Daniel Lawson
  • 5,426
  • 21
  • 27
1

1.3gb/day will be ok for any ssd (maybe except some very, very old ones). Here is report from ssd life calculator: http://www.ssdready.com/measure/?value=1.3&msr=Gb&submit=Estimate%21

crea7or
  • 123
  • 4