On 16 apr 2010, at 17.05, Bob Friesenhahn wrote: > 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.
This is exactly how they work, at least most of them. If they should erase and reprogram each flash block (say, 128 KB blocks times the parallelism of the drive) for each 512 B block written, they would wear out in no time and performance would be horrible. Eventually they have to gc because they are out of erased blocks, and then they have to copy the data in used to new places. In that process, it of course helps if some of the data is tagged as not needed anymore, it can then compact the data much more efficiently and it doesn't have to copy around a lot of data that won't be used. I't should also help saving copy/erase cycles in the drive, since the data it moves is much more likely to actually be in use and probably won't be overwritten as fast as a non-used block, it will in effect pack data actually in use into flash blocks. If the disk is nearly full, TRIM likely doesn't make much difference. I'd guess TRIM should be very useful on a slog device. > It is much more efficient (from a housekeeping perspective) if filesystem > sectors map directly to SSD pages, but we are not there yet. I agree with Eric that it could very well be better to let the device virtualize the thing and have control and knowledge of all the hardware specific implementation details. Flash chips, controllers, bus drivers and configurations don't all come equal. > 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. That would sure be interesting! /ragge > > 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 _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
