It is said that SSDs do not need to be defragmentised, that it even can be harmful to the durability of an SSD to do so. However, Noel Carboni'S severla comments here
https://www.askwoody.com/forums/topi...youre-getting/
kept me wondering whether that really is true. He insists that SSDs do fragmentise, but that it plays a less prominent role due to their much faster access time, however, people in the knowledge he claim to know who do it once per year.
Then there is the alterntive to use TRIM command instead.
Anyone in the knowledge about SSD and the need to fragmentise or not to do so?
Lets ignore the faster access time, everybody knows that. What about other factors to decide between SSD and HD? And if it is reliability before speed what you want, is an NAS-certified HD like WD's Red Pro series the option of choice?
Finally, how long is the durability of SSDs today, lets say very good ones like they say Samsung builds them? Are they to be replaced every two years? Do they last shorter, muchz longer today? Noel Carboni says he uses some for over five years now - without a single dropout so far.
Also, consider this:
https://www.hanselman.com/blog/TheRe...ntYourSSD.aspx
Quote:
Actually Scott and Vadim are both wrong. Storage Optimizer will defrag an SSD once a month if volume snapshots are enabled. This is by design and necessary due to slow volsnap copy on write performance on fragmented SSD volumes. It’s also somewhat of a misconception that fragmentation is not a problem on SSDs. If an SSD gets too fragmented you can hit maximum file fragmentation (when the metadata can’t represent any more file fragments) which will result in errors when you try to write/extend a file. Furthermore, more file fragments means more metadata to process while reading/writing a file, which can lead to slower performance.
As far as Retrim is concerned, this command should run on the schedule specified in the dfrgui UI. Retrim is necessary because of the way TRIM is processed in the file systems. Due to the varying performance of hardware responding to TRIM, TRIM is processed asynchronously by the file system. When a file is deleted or space is otherwise freed, the file system queues the trim request to be processed. To limit the peek resource usage this queue may only grow to a maximum number of trim requests. If the queue is of max size, incoming TRIM requests may be dropped. This is okay because we will periodically come through and do a Retrim with Storage Optimizer. The Retrim is done at a granularity that should avoid hitting the maximum TRIM request queue size where TRIMs are dropped.
|