| 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 2.0.0.21 (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? -Eric |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: what is the status of XFS ?, Felix Blyakher |
|---|---|
| Next by Date: | Re: [PATCH] xfs: add more checks to superblock validation, Felix Blyakher |
| Previous by Thread: | Re: XFS support for TRIM / blkdev_issue_discard?, Dave Chinner |
| Next by Thread: | Re: XFS support for TRIM / blkdev_issue_discard?, Peter Niemayer |
| Indexes: | [Date] [Thread] [Top] [All Lists] |