TRIM support for UFS?

[Pawel Jakub Dawidek]

On Thu, Dec 09, 2010 at 04:37:48PM -0800, Bakul Shah wrote:
> On Thu, 09 Dec 2010 10:13:39 PST Kirk McKusick <mckusick at mckusick.com>  wrote:
> > Other than the nit pointed out by Pawel, the diffs look good to me.
> > You should consider adding the -t option to newfs so that the TRIM
> > option can be specified at the time the filesystem is created (as
> > a general rule, anything you can do with tunefs should also be
> > possible with newfs).
> > 
> > I agree with your decision to let administrators opt-out of doing
> > TRIM. If experience shows it to be generally useful to have it on,
> > we can change the default to enabled later. If we do change the
> > default to enabled, then we will want to delete the warning about TRIM
> > not being supported by the underlying disk that you added at mount
> > time as we would start getting a lot of them for all the non-SSD disks.
> 
> Would be nice if something like ftrim(fd, offset, size) or
> trim(path, offsetm size) or TRIM file ioctl is added, to free
> up blocks undelying a given range in a file.  ftruncate can
> delete blocks at the end but there is no facility to lose
> blocks in the middle.  Mainly handy for virtual disks and
> databases (and would work nicely with SEEK_DATA, SEEK_HOLE).

libgeom(3) provides:

	int g_delete(int fd, off_t offset, off_t length);

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20101210/025ad233/attachment.pgp