Support discarding of unused sectors: Difference between revisions
initial proposal |
Update status of the work, and add a link to FITRIM/discard, minor formatting, spell check |
||
| (3 intermediate revisions by one other user not shown) | |||
| Line 3: | Line 3: | ||
For magnetic disks, DRAM and many other physical media used as block devices, it does not matter for the device to know which sectors are actually unused by the filesystem and therefore contain irrelevant content. | For magnetic disks, DRAM and many other physical media used as block devices, it does not matter for the device to know which sectors are actually unused by the filesystem and therefore contain irrelevant content. | ||
This is quite different for Solid State Disks (SSDs) built from Flash Memory: To avoid performance degradation from the dynamic wear- | This is quite different for Solid State Disks (SSDs) built from Flash Memory: To avoid performance degradation from the dynamic wear-leveling algorithms, there has to be a clever management of "unused" blocks in the SSD controller. | ||
To let the SSD controller know which sectors contain irrelevant data, the ATA TRIM command has been standardized, and now the first SSDs are available that implement that command (e.g. the SSDs using the Indilinx Barefoot controller, from firmware revision 1370 onwards). | To let the SSD controller know which sectors contain irrelevant data, the ATA TRIM command has been standardized, and now the first SSDs are available that implement that command (e.g. the SSDs using the Indilinx Barefoot controller, from firmware revision 1370 onwards). | ||
| Line 9: | Line 9: | ||
== What needs to be done == | == What needs to be done == | ||
This work has been implemented in Linux since v2.6.38, Jan 18 2011. | |||
== Related Standards == | |||
* [http://www.t13.org/Documents/UploadedDocuments/docs2008/e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc Data Set Management Commands Proposal for ATA8-ACS2] | |||
* [http://www.t13.org/Documents/UploadedDocuments/docs2008/e08137r4-DRAT_-_Deterministic_Read_After_Trim.doc Deterministic TRIM Proposal for ATA8-ACS2] | |||
== Other Documents == | |||
[http://www. | * [[FITRIM/discard]] | ||
* An interesting [http://www.anandtech.com/printarticle.aspx?i=3531 Article at Anandtech] that (while being a little verbose and Windows-oriented) explains many aspects of SSD performance, including the prospective benefits of the ATA TRIM command (at page 10). | |||
* Patch [http://www.mail-archive.com/cluster-devel@redhat.com/msg03401.html adding the blkdev_issue_discard()] feature to GFS2 | |||
* [http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf Presentation] on a comparison between different filesystems performance on SSDs (including XFS) | |||
Latest revision as of 19:42, 11 October 2011
Rationale[edit | edit source]
For magnetic disks, DRAM and many other physical media used as block devices, it does not matter for the device to know which sectors are actually unused by the filesystem and therefore contain irrelevant content.
This is quite different for Solid State Disks (SSDs) built from Flash Memory: To avoid performance degradation from the dynamic wear-leveling algorithms, there has to be a clever management of "unused" blocks in the SSD controller.
To let the SSD controller know which sectors contain irrelevant data, the ATA TRIM command has been standardized, and now the first SSDs are available that implement that command (e.g. the SSDs using the Indilinx Barefoot controller, from firmware revision 1370 onwards).
What needs to be done[edit | edit source]
This work has been implemented in Linux since v2.6.38, Jan 18 2011.
Related Standards[edit | edit source]
Other Documents[edit | edit source]
- FITRIM/discard
- An interesting Article at Anandtech that (while being a little verbose and Windows-oriented) explains many aspects of SSD performance, including the prospective benefits of the ATA TRIM command (at page 10).
- Patch adding the blkdev_issue_discard() feature to GFS2
- Presentation on a comparison between different filesystems performance on SSDs (including XFS)