SSD life vs file size

[chenw]

Hey all,

Just a question, does a SSD deteriorate faster, slower or the same when writing many many smaller files over a few large files?

Example, if I were comparing say writing 1million 1KB files to writing 1000 1MB files to 1 1GB file.

 

[Liger88]

No, it's all the same to the SSD. The controller deals with writes in a very very complicated manner, but it does so much better than before. It'll spread the files evenly across the cells to make the drive wear at the same rate throughout all NAND cells.

 

[gerph]

Hey all,

Just a question, does a SSD deteriorate faster, slower or the same when writing many many smaller files over a few large files?

Example, if I were comparing say writing 1million 1KB files to writing 1000 1MB files to 1 1GB file.

I wouldn't like to comment categorically on whether it will deteriorate faster, because that will depend on the specifics of the device, filesystem usage and caching used by your system. But I'd say that the number of blocks written will be higher for a million 1K files compared to 1000 1MB files, compared to 1 1GB file. The content may be the same but the metadata will not.

Consider a single 1GB file to begin with.
You have a directory entry this contains the details for this file - it's name, size, owner, attributes, and some way of finding the file on the device. Usually the way of finding the file on the device is a reference to a map entry or block list. If it's a map entry then this will itself contain a block list for the blocks that are actually used for the data. Depending on the filesystem this may be an actual list of every single block on the device, or a list of extents (eg 'from block 12345 to block 76543').
However it's done, this data is (most likely) in different places. So updating the file is at least an update to the directory entry, possibly a map, and most likely a block list (or however it's stored - there are many filesystem types, based on many different models). Let's assume just assume a single layer of indirection and say that we update the directory entry for the file and a block list. Let's also assume the use of extents to locate the content, rather than explicit block lists. Let's not assume that the extends list is shared with the directory entry, just for simplicity - it's possible with some systems, but for the following cases will be unlikely to be true.

Let's not assume a journalling filesystem which writes data in different places. Let's not assume that you're using a filesystem that keeps a history of every operation so that you can wind it back. These two assumptions make the number of writes much smaller, so the answer will be much more conservative than real life, but still in the same ratios.

I'm also making the assumption that the file comes into life fully formed - that is you don't write 1MB, then another 1MB, and so on - which might require many many updates to the directory entry to update the size field (and possibly the location blocks as well).

Best case, then is that we update <content> + <directory> + <location> blocks.

Now consider 1000 1MB files. The same is true, but we have more directory updates, and more location blocks. We might say that all these files are updated really quickly so the entries are all cached in memory before being written out, resulting in a very small number of writes. But lets not assume that because its rare to create all your files at once.

So now we have to update <content> + 1000 <directory> + 1000 <location> blocks.

Finally, consider 1,000,000 1KB files. The content size is again the same, but the meta data is far larger:

We have to update <content> + 1000000 <directory> + 1000000 <location> blocks.

So the number of writes in the case of larger numbers of files is larger. File systems are much more complex than this rudimentary calculation, and operating system (and file system) caching also comes into play here. But the basic principle is that the more write operations you perform, the more your SSD is affected, and the number of operations that are required by your cases is greater for smaller numbers of files.

The size of the metadata, compared to the data itself might be considerably smaller, but it is there.

So if you equate basic write operations to causing a deterioration of the SSD, then yes you will find that it deteriorates faster with the smaller files.

Repeating my caveat: Filesystems differ in behaviour, may write more or fewer blocks for each operations, may cache some operations and merge them together, may use journals which increase the number of writes when data or metadata is updated, may provide checksum blocks, may use historical records which cause more writes, and may, basically work competely differently to the simplistic approach I've described above. In short, don't rely on my word, but also don't assume that writing data to the disc only involves operations on that data...

 

[westrock2000]

I wouldn't worry about it AT ALL.

I have something like 5TB or writes on my Intel 160GB and it still shows about 95% health.