45

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)

Improve this question
1

5 Answers 5

Reset to default
36

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

Improve this answer
5
  • 4
    Sector size could be found by running command #cat /sys/block/sda/queue/hw_sector_size
    – Antonio
    Jul 3, 2012 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 3, 2012 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, 2013 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, 2013 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 7, 2014 at 20:36
27

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.

Improve this answer
4
  • 3
    No, this only exists on certain models of SSD drives. It is not universal.
    – Michael Hampton
    Feb 3, 2014 at 3: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 2, 2015 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, 2016 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, 2019 at 6:34
24

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

Improve this answer
7
  • 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, 2011 at 8: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, 2011 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, 2011 at 14:50
  • 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, 2011 at 4: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, 2017 at 1:19
3

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
Improve this answer
1
2

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

Improve this answer
1
  • I suppose that could work but I was hoping there was something higher-level available that could provide cumulative byte totals :)
    – badnews
    Feb 21, 2011 at 8:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .