[Top] [All Lists]

Re: XFS support for TRIM / blkdev_issue_discard?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS support for TRIM / blkdev_issue_discard?
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sun, 19 Apr 2009 10:51:24 -0500
Cc: Felix Blyakher <felixb@xxxxxxx>, Peter Niemayer <niemayer@xxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20090419081927.GE16929@xxxxxxxxxxxxxxxx>
References: <20090331053013.7642414167108@xxxxxxxxxxxxxxxxxxxxxxx> <49E4A131.5040309@xxxxxx> <BB5058FD-E69F-4254-9548-82CD634C7FD6@xxxxxxx> <20090419081927.GE16929@xxxxxxxxxxxxxxxx>
User-agent: Thunderbird (Macintosh/20090302)
Dave Chinner wrote:
> On Tue, Apr 14, 2009 at 01:32:35PM -0500, Felix Blyakher wrote:
>> On Apr 14, 2009, at 9:44 AM, Peter Niemayer wrote:
>>> Dear Felix Blyakher,
>> Hi Peter,
>>> do you know whether there are plans to support the ATA TRIM command /
>>> blkdev_issue_discard() call in XFS for Linux anytime soon?
>> This topic was indeed brought up in xfs discussions.
>> Though, we don't have any definite plans on supporting it yet.
> 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?  For think provisioning it might be
different.  I  think (?) the simply block-by-block free is still
relevant, no?


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