Re: XFS support for TRIM / blkdev_issue_discard?

[Peter Niemayer <niemayer@isg.de>]

Eric Sandeen wrote:
> Dave Chinner wrote:
>> I did some initial work on tracking extents being freed, but then
>> the TRIM request morphed into a "tell the largest free space around
>> the area just freed" and that is much harder to do than simply to
>> issue a "we just freed this bit" command.
> 
> FWIW, ext[34] is still doing it block by block.  At least for SSDs, I
> think that's fine, isn't it? 

Well, theoretically, if there was a SSD that on one hand was sophisticated
enough to provide TRIM support, but would otherwise not use an intelligent
controller or cache memory and thus could pre-erase blocks only if the
TRIM was applied to a whole erase block at once, then even a SSD could
benefit from "telling the largest free space around the area just freed".

In practice, I don't think there will ever be a SSD like that on the market,
the primitive ones do not support TRIM, the sophisticated ones will
keep book of unused sectors internally and will notice when a whole erase-block
became empty and thus ready for proactive erasing.

And I did not find any requirement or hint to "tell the largest free space around
the area just freed" in
http://www.t13.org/Documents/UploadedDocuments/docs2008/e07154r6-Data_Set_Management_Proposal_for_ATA-ACS2.doc

Regards,

Peter Niemayer

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs