SSD Defrag Optimize

[Cerb]

In an ideal world, they shouldn't have to be re-written at all. SSD's don't care about the physical location of the data like HDD's do. The flash translation layer presents the flash cells as a spinning disk to the host, but it's just a table of pointers, not an actual spinning disk.
The translation layer could simply "lie" to the host during a defrag - A request to move data from location B to location A comes in - instead of erasing the data, rewriting it somewhere else on the flash cells and updating the translation table, it could simply say "OK, I moved that data from B to A for you" and just update the translation table to reflect this without rewriting the data.

And, there's no reason some given SSD couldn't do that. Sandforce SSDs might well do that, already. The SSD would have to know about the data being read and written, for that to work, or look all written data up against a dedup table. Most SSD makes probably don't want to add that kind of complexity, or risk poor performance over time, from doing so, given that write cycle life is not normally a problem.

Ultimately, it would be nice for OSes to have bare flash FSes, and bare flash interface options. But, today, that seems to be something reserved for specialized companies, and very large tech-dependent companies (FI, Google, and Facebook).

 

[destrekor]

In an ideal world, they shouldn't have to be re-written at all. SSD's don't care about the physical location of the data like HDD's do. The flash translation layer presents the flash cells as a spinning disk to the host, but it's just a table of pointers, not an actual spinning disk.
The translation layer could simply "lie" to the host during a defrag - A request to move data from location B to location A comes in - instead of erasing the data, rewriting it somewhere else on the flash cells and updating the translation table, it could simply say "OK, I moved that data from B to A for you" and just update the translation table to reflect this without rewriting the data.

And, there's no reason some given SSD couldn't do that. Sandforce SSDs might well do that, already. The SSD would have to know about the data being read and written, for that to work, or look all written data up against a dedup table. Most SSD makes probably don't want to add that kind of complexity, or risk poor performance over time, from doing so, given that write cycle life is not normally a problem.

Ultimately, it would be nice for OSes to have bare flash FSes, and bare flash interface options. But, today, that seems to be something reserved for specialized companies, and very large tech-dependent companies (FI, Google, and Facebook).

Isn't NVMe a path to let flash shed the HDD baggage? Perhaps it's incomplete as far as a total HDD>Flash transition, but it sure seems to be on the right track if it isn't already addressing your concerns.

 

[TheELF]

3dxpoint is coming anyways...

 

[destrekor]

3dxpoint is coming anyways...

So far the design focus has been on incorporating that onto DIMMs in order to marry RAM with storage for different applications. Which through that method you get a vastly different approach to storage, but I don't think that method is intended for regular storage uses; rather, I think that's more intended for database and other datacenter use cases.

I'm curious if they can keep all of the aspects of the technology, and incorporate it into add-on components meant for dedicated storage through NVMe.

 

[TheELF]

It will come out as ssd first and then as a ram/dimm version.
You won't have to read anything from disk anymore since your disk will be your memory,or at least part of it,like a ramdisk, since high end users(gamers) will still want their higher speed ram.

 

[destrekor]

It will come out as ssd first and then as a ram/dimm version.
You won't have to read anything from disk anymore since your disk will be your memory,or at least part of it,like a ramdisk, since high end users(gamers) will still want their higher speed ram.

So an SSD version of the 3D XPoint memory will be addressed by the system as RAM, but otherwise be a logical storage volume? I'm assuming there must be something done at the controller level, and something at the OS level too, because how will an SSD version, using NVMe, be addressed by the OS as actual RAM? Something like that must have to happen because otherwise, any means of expansion outside of the DIMM slots can no longer be treated by the system as RAM, at least, that's not something of which I'm aware is possible.

Or will be the benefit be that, when used as a true storage volume, the performance is so fast that shuttling data in and out of system memory is no longer a performance penalty? As a ramdisk that makes sense, but that's assuming it's a logical volume carved out of the RAM itself, whatever it's memory type. But if it's using any other kind of system bus, be it SATA, SAS, or NVMe over PCIe, an OS won't treat it like RAM (though it could be treated as cache). Right?