[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

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>