xfs
[Top] [All Lists]

Re: XFS support for TRIM / blkdev_issue_discard?

To: Peter Niemayer <niemayer@xxxxxx>
Subject: Re: XFS support for TRIM / blkdev_issue_discard?
From: "Martin K. Petersen" <martin.petersen@xxxxxxxxxx>
Date: Mon, 20 Apr 2009 15:11:19 -0400
Cc: Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <49ECC2CA.20108@xxxxxx> (Peter Niemayer's message of "Mon, 20 Apr 2009 20:45:30 +0200")
Organization: Oracle
References: <20090331053013.7642414167108@xxxxxxxxxxxxxxxxxxxxxxx> <49E4A131.5040309@xxxxxx> <BB5058FD-E69F-4254-9548-82CD634C7FD6@xxxxxxx> <20090419081927.GE16929@xxxxxxxxxxxxxxxx> <49EB487C.1020205@xxxxxxxxxxx> <49ECC2CA.20108@xxxxxx>
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)
>>>>> "Peter" == Peter Niemayer <niemayer@xxxxxx> writes:

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

This was never an issue with SSDs.  The requirement comes from
thin-provisioned SCSI disk arrays that would like us to do unmaps
(trims) in units of their internal block size.

There was a huge pushback from the industry about this.  This is clearly
something the array firmware should have to keep track of and not the
operating system.  As a result the unmap granularity size proposal was
pulled and for a while it looked like everything was going to be fine.

Unfortunately yet another array vendor recently discovered that thin
provisioning is hard and sent out a request to have the granularity
brain damage reinstated in the latest protocol draft.

I'm just hoping that all the vendors who came around on the issue will
stay that way...

-- 
Martin K. Petersen      Oracle Linux Engineering

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