xfs
[Top] [All Lists]

Re: XFS support for TRIM / blkdev_issue_discard?

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: XFS support for TRIM / blkdev_issue_discard?
From: Peter Niemayer <niemayer@xxxxxx>
Date: Mon, 20 Apr 2009 20:45:30 +0200
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Felix Blyakher <felixb@xxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <49EB487C.1020205@xxxxxxxxxxx>
References: <20090331053013.7642414167108@xxxxxxxxxxxxxxxxxxxxxxx> <49E4A131.5040309@xxxxxx> <BB5058FD-E69F-4254-9548-82CD634C7FD6@xxxxxxx> <20090419081927.GE16929@xxxxxxxxxxxxxxxx> <49EB487C.1020205@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.19) Gecko/20081204 SeaMonkey/1.1.14
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

<Prev in Thread] Current Thread [Next in Thread>