Date: Thu, 09 Dec 2010 16:57:18 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-fs@freebsd.org, pjd@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de> Subject: Re: TRIM support for UFS? Message-ID: <201012100057.oBA0vIgT065481@chez.mckusick.com> In-Reply-To: <20101210003749.3F7E15B92@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> To: Kirk McKusick <mckusick@mckusick.com> > cc: Kostik Belousov <kostikbel@gmail.com>, freebsd-fs@freebsd.org, > pjd@freebsd.org, Oliver Fromme <olli@lurza.secnetix.de> > Subject: Re: TRIM support for UFS? > Date: Thu, 09 Dec 2010 16:37:48 -0800 > From: Bakul Shah <bakul@bitblocks.com> > X-ASK-Info: Message Queued (2010/12/09 16:37:54) > X-ASK-Info: Confirmed by User (2010/12/09 16:39:17) > > 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). We have discussed adding such a system call over the years (actually we called it `release' rather than `trim'). If such a call ever does get added, any blocks that it actually manages to release will get passed through to BIO_DELETE by the changes that Kostik is soon to add to the system. Kirk McKusick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012100057.oBA0vIgT065481>