42

We're quite interested in exploring the possibility of using SSD drives in a server environment. However, one thing that we need to establish is expected drive longevity. According to this article manufacturer's are reporting drive endurance in terms of 'total bytes written' (TBW). E.g. from that article a Crucial C400 SSD is rated at 72TB TBW. Do any scripts/tools exist under the Linux ecosystem to help us measure TBW? (and then make a more educated decision on the feasibility of using SSD drives)

badnews
  • 565
  • 1
  • 6
  • 6
  • Take a look at https://serverfault.com/q/995084/34560, I am trying to figure out the same thing. – Gaia Dec 10 '19 at 19:20

5 Answers5

35

Another possibility is to look at /proc/diskstats. It's not persistent across reboots, but it has data for every block device. Probably most interesting to you is field 10, which contains the total number of sectors written. On a system with scsi disks with a sector size of 512 bytes, you could run

awk '/sd/ {print $3"\t"$10 / 2 / 1024}' /proc/diskstats

to see how many megabytes were written to each device. The output will look like

sda 728.759
sda1 79.0908
sda2 649.668

sciurus
  • 12,493
  • 2
  • 30
  • 49
  • 4
    Sector size could be found by running command #cat /sys/block/sda/queue/hw_sector_size – Antonio Jul 03 '12 at 15:19
  • @Antonio thanks! I'm not sure when that was added. It looks like it is in 3.2 but not 2.6.18. – sciurus Jul 03 '12 at 19:04
  • @sciurus could you explain the math behind your calculations please ? You're talking about the size of the sector = 512 but your calculations are dividing the read value with 2/1024 – milosgajdos Jan 14 '13 at 18:07
  • @gyre Field 10 contains the number of 0.5 kilobyte sectors written. I divide that by 2 to get the number of kilobytes written. I then divide that by 1024 to convert to megabytes. – sciurus Jan 15 '13 at 18:19
  • @antonio That *does* show the sector size being used with the underlying hardware, but afaict from the kernel source, iostat source, and empirical tests, the "sectors" number in /proc/diskstats *always* refers to 512 bytes, even when `hw_sector_size` is different (at least since the 2.4 series). See `block/cfq-iosched.c`, particularly `cfqg_stats_update_dispatch()`. – the paul Feb 07 '14 at 20:36
26

I was struggling with the same problem on my notebook, but as I reboot it pretty much on a daily basis, the accepted answer wasn't helpful. I have a Samsung mSATA SSD, which happens to have the SMART attribute #241 Total_LBAs_Written. According to the official documentation,

To calculate the total size (in Bytes), multiply the raw value of this attribute by 512B.

So the following command gives me the total TB written on my SSD disk (sdb)

sudo smartctl -A /dev/sdb | awk '/^241/ { print "TBW: "($10 * 512) * 1.0e-12, "TB" } '

As it also works on my HDD, I assume that it should work on pretty much every modern hard disk.

Benoit Duffez
  • 143
  • 2
  • 11
Gabriel Miretti aka gmiretti
  • 371
  • 3
  • 4
  • 3
    No, this only exists on certain models of SSD drives. It is not universal. – Michael Hampton Feb 03 '14 at 03:50
  • 3
    I wanted to point out that your equation actually produces a number that is off it would be more accurate as: `sudo smartctl -A /dev/sda1 | awk '/^241/ { print "TBW: "($10 * 512) * 1.0e-12, "TB" }'`. – Jordon Bedwell May 02 '15 at 17:05
  • My Intel SSD has the same attribute but it's called `Host_Writes_32MiB`. Also there is Attribute 249 `NAND_Writes_1GiB`. So be aware that on each SSD this seems to be different (e.g. a mSATA Intel SSD of mine does not have those attributes) – reox Sep 30 '16 at 15:37
  • On my Intel SSD Pro 5400s (SATA) the `Total_LBAs_Written` is specified in GBs! Couldn't make any sense of the low `4714` smart was showing. But looking in the Intel SSD Toolbox in Windows showed it was in GB. – MrCalvin Jun 26 '19 at 06:34
23

You can see how much data has been written to an ext4 filesystem by looking in /sys/fs/ext4/$DEVICE/lifetime_write_kbytes.

sciurus
  • 12,493
  • 2
  • 30
  • 49
  • That's a cool feature I didn't know about! A shame most of our systems are running ext3 and also some raw LVM partitions for VMs :) – badnews Feb 21 '11 at 08:06
  • ext3 (and to a slightly lesser extent) ext4 are not designed for writing to flash. The failure will occur depending on the number of times a location is written - and with conventional filesystems, hotspots develop very rapidly. The figures cited by manufacturers are very misleading since they assume an even spread of writes. There are filesystems - such as JFFS2 - specifically designed to extend the life of your SSDs. – symcbean Feb 21 '11 at 12:47
  • 3
    @symcbean - with present-day flash devices, this is largely a non-issue. They all have wear-leveling routines built into their on board controllers. – EEAA Feb 21 '11 at 14:50
  • @ErikA - I assumed the same. The flash controller should perform wear-levelling which would make the "total bytes written" metric a useful guideline :) (or so I hope!) – badnews Feb 21 '11 at 22:32
  • 2
    @symcbean - There are two kinds of flash devices. Memory Technology Devices (or MTDs) present a direct interface to the flash memory. These are typically found in embedded devices and are what filesystem like JFFS2 are designed for. The other kind of flash device hides the flash memory behind a Flash Translation Later (FTL) so that it looks like a regular block device. This is how consumer technology like SSDs, usb sticks, and memory cards are implemented. Filesystems like JFFS2 aren't appropriate for these; instead, you have to use filesystems like ext4 that are designed for block devices. – sciurus Feb 23 '11 at 04:10
  • 1
    BEWARE: The ext4 lifetime_write_kbytes and session_write_kbytes are not representative of SSD memory cell writes. I've seen one system report 15TB for ext4 lifetime_write_kbytes, while the SSD itself reported only 1TB via SMART attribute 241. I suspect ext4 might be adding the entire size of the filesystem's free space to those statistics every time fstrim runs, even though the SSD controller obviously wouldn't repeatedly erase all those available blocks if they hadn't been touched since the last erase. tune2fs -l output appears to be similarly misleading. – ʇsәɹoɈ Apr 26 '17 at 01:19
  • Is there any equivalent of this for Btrfs? – TCB13 May 10 '22 at 10:47
2

You can try iostat. It gives you statistics related to IO and CPU usage. Have a look at the manual man iostat.

Khaled
  • 35,688
  • 8
  • 69
  • 98
  • I suppose that could work but I was hoping there was something higher-level available that could provide cumulative byte totals :) – badnews Feb 21 '11 at 08:05
2

For my KINGSTON SEDC400S37480G, under Ubuntu Server 14.04, I use the following script to monitor TBW. I run it from cron once every day. The script outputs to a log file.

You need calc for it to work. Install calc using:

apt-get install apcalc

Script content:

echo "*** $(date -R) ***" >> /scripts/tbw/log.txt
tbw=$(cat /sys/fs/ext4/sda1/lifetime_write_kbytes)
TB=1000000000
echo TB written to sda1: >> /scripts/tbw/log.txt | calc $tbw / $TB >> /scripts/tbw/log.txt

Will output:

*** Thu, 20 Jul 2017 03:02:51 +0300 ***
TB written to sda1:
    3.062138442
inteq
  • 21
  • 3