TRIM support for UFS?

[Christoph Hellwig]

On Fri, Dec 10, 2010 at 02:26:42AM -0800, Julian Elischer wrote:
> private response.
> BTW as you seem to be a Linux person how did you end up here?
> (not a problem, just curious)

I might be mostly a Linux person, but I've also done various BSD based
customer projects.  I've been subscribed for various FreeBSD lists for
years to keep my knowledge in this area current.

> but do they support the option to be nodeterministic about it :-)

Well, it's not an option for the operating system to select.  It's
something the disk choses to advertise through the ATA IDENTIFY page.

> When you trim a block range you have to store that information somewhere.
> and that in turn  can cause a cascade of problems when you are trying to
> cope with unclean shutdown. (I work for fusionIO with Jens Axboe and
> Nick Piggins and my job includes writing code to do exactly that).
> it takes cpu and ram and doing so detracts from overall performance
> so if your drive has an option to make trims "non persistant" in the
> case of
> power failure you can use that fact to increase the performance in
> other ways.

Yes, it's simpler, but also not overly useful for many of use cases.
Take a look at ftp://ftp.t10.org/t10/document.08/08-347r1.pdf for a
slightly older writeup of the issues of indeterminate TRIM behaviour.

Depending on how your structure your underlying storage returning
determinate blocks is not a huge problem.  I've already written
two different implementation of TRIM/UNMAP building on top of the
XFS hole punching ioctl - the qemu one can be found on the qemu
mailinglist for anyone curious enough.  With the XFS hole punch
ioctl we only need to log changes to the extent btree and the inode
core, as well as zeroing out areas of a block that wasn't fully
discarded.  It boils down to relatively little sequential I/O into
the filesystem log, which can be on a separate device for arrays,
but you don't even have that problem with flash based devices.

> I'll leave it to Jens to work on the ioctls for linux, but we have the
> same driver for Windows, Linux, FreeBSD, OS-X, AIX, ESX, and Solaris
> with different adaptation layers so what we decide to export is
> pretty flexible.

The ioctls sit in the Linux block layer or filesystems - the low-level
driver just needs to understand the discard type bio - which is pretty
similar to the delete bio proposed in this thread.