0

We have a rather large custom in-house application that we are considering moving the configuration files to an SSD drive. In the midst of these configure files we also write thousands of zero byte files to track logged on users and the timestamp of their last activity (by the file's name and timestamp). There are probably 50 zero byte files written/updated per second.

So my question is, how long would it take to kill an SSD drive writing this many zero byte files?

We would be using a Samsung Pro, which I believe has 8k NAND pages. I would also estimate about 1.5 million hits per day (50 hits/sec * 60 seconds * 60 minutes * 8+ hours = ~1.5M).

Given 8192 bytes per write * 1.5M writes per day = 12GB per day.

Providing no addition write amplification, I believe these Samsungs can take about 500,000GB of writing before they wear out.

500000 / 12 = 41666 days / 365 days per year = 114 years.

So I am estimating that the drive will last 114 years before wearing out. Does this sound like a reasonable calculation, or am I missing something very important in my math?

(I am aware that the application should not be writing zero byte files, but until that can be corrected to something more feasible, I have to work with what is there. Please consider this question as an academic question on wearing out an SSD with zero byte file writes instead of the flaws that might exist in an application.)

Brain2000
  • 298
  • 1
  • 3
  • 11
  • 1
    You can't fix the application? There are many ways to do this sort of thing, and zero byte files ranks among the worst. – Michael Hampton Aug 07 '14 at 22:32
  • Is this on server hardware? Will there be a RAID controller in the mix? What operating system/version/filesystem will you be using? – ewwhite Aug 07 '14 at 22:39
  • It depends on the filesystem used, but there could be writes in two different places. First, the directory is updated, and then the file space itself is allocated. – Tero Kilkanen Aug 07 '14 at 22:51
  • I believe your calculation leaves out a lot of overhead writes for inode updates as well..... – mdpc Aug 07 '14 at 22:52
  • @MichaelHampton Agreed, but this is a legacy application. What would you suggest? We have to maintain state in a high availability application for tens of thousands of users. Sure, we could add a database to hold state, but that's a lot of work for just doing something "properly". – Brain2000 Aug 07 '14 at 22:55
  • @mdpc I was considering 8k for the inode update. Is there more than that? – Brain2000 Aug 07 '14 at 22:56
  • @ewwhite This will hosted on an SSD directly attached on a Windows server, so most likely NTFS will be the file system. – Brain2000 Aug 07 '14 at 22:59
  • 1
    I'd ponder changing the application to possibly using ONE file or a simple MySQL database. – mdpc Aug 07 '14 at 22:59
  • @mdpc That would be ideal, and the code for checking and updating the timestamp is contained in one centralized function, so that would be possible. Though, I'm still considering the SSD option until I would have time to add and test the code for that. – Brain2000 Aug 07 '14 at 23:01
  • Ideally this should all remain in memory and never touch a disk. Why is it being written out to begin with? – Michael Hampton Aug 08 '14 at 00:09
  • @MichaelHampton It's a very highly available application with clustered servers to take over should one fail, so we never use RAM to store state information. The other option would be to use a database. Again, that involves code changes that I'll have to get through red tape. In the meantime, I'm just looking to see if my math calculations above are correct. – Brain2000 Aug 08 '14 at 14:56

1 Answers1

1

My recommendation here is to use an endurance-optimized SSD, a highly-overprovisioned SSD (e.g. 40%), an under-provisioned SSD (via firmware), and industrial SSD or a device with no wearout potential (e.g. DRAM-based SSD).

Don't use consumer SSDs for this. At least not without some form of RAID...

ewwhite
  • 197,159
  • 92
  • 443
  • 809
  • The Samsung Pro is MLC, a bit better than consumer grade TLC, but not as tough as the enterprise SLC. Of course there would be a mirror... which would then replicate to a second server through DFSR housing on another mirrored pair. – Brain2000 Aug 08 '14 at 14:53