From owner-freebsd-fs@FreeBSD.ORG Fri Dec 10 01:35:15 2010 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B940B106564A for ; Fri, 10 Dec 2010 01:35:15 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 9E2F18FC14 for ; Fri, 10 Dec 2010 01:35:15 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 0C30C5B94; Thu, 9 Dec 2010 17:27:19 -0800 (PST) To: Kirk McKusick In-reply-to: Your message of "Thu, 09 Dec 2010 16:57:18 PST." <201012100057.oBA0vIgT065481@chez.mckusick.com> References: <201012100057.oBA0vIgT065481@chez.mckusick.com> Comments: In-reply-to Kirk McKusick message dated "Thu, 09 Dec 2010 16:57:18 -0800." Date: Thu, 09 Dec 2010 17:27:19 -0800 From: Bakul Shah Message-Id: <20101210012720.0C30C5B94@mail.bitblocks.com> Cc: freebsd-fs@freebsd.org, pjd@freebsd.org, Oliver Fromme Subject: Re: TRIM support for UFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Dec 2010 01:35:15 -0000 On Thu, 09 Dec 2010 16:57:18 PST Kirk McKusick wrote: > > To: Kirk McKusick > > cc: Kostik Belousov , freebsd-fs@freebsd.org, > > pjd@freebsd.org, Oliver Fromme > > Subject: Re: TRIM support for UFS? > > Date: Thu, 09 Dec 2010 16:37:48 -0800 > > From: Bakul Shah > > 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. That is why this seemed like a good time to mention this! Probably most of the logic for this can be borrowed from ftruncate().... Pawel mentions g_delete() but it seems a bit indirect.