On Fri, 16 Apr 2010, Kyle McDonald wrote:
But doesn't the TRIM command help here. If as the OS goes along it makes sectors as unused, then the SSD will have a lighter wight lift to only need to read for example 1 out of 8 (assuming sectors of 512 bytes, and 4K FLASH Pages) before writing a new page with that 1 sector and 7 new ones. Additionally in the background I would think it would be able to find a Page with 3 inuse sectors and another with 5 for example, write all 8 to a new page, remap those sectors to the new location, and then pre-erase the 2 pages just freed up.
While I am not a SSD designer, I agree with you that a smart SSD designer would include a dereferencing table which maps sectors to pages so that FLASH pages can be completely filled, even if the stored sectors are not contiguous. It would allow sectors to be migrated to different pages in the background in order to support wear leveling and compaction. This is obviously challenging to do if FLASH is used to store this dereferencing table and the device does not at least include a super-capacitor which assures that the table will be fully written on power fail. If the table is corrupted, then the device is bricked.
It is much more efficient (from a housekeeping perspective) if filesystem sectors map directly to SSD pages, but we are not there yet.
As a devil's advocate, I am still waiting for someone to post a URL to a serious study which proves the long-term performance advantages of TRIM.
Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
