From owner-freebsd-questions@FreeBSD.ORG Tue Sep 11 17:59:00 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8FE3106566B for ; Tue, 11 Sep 2012 17:59:00 +0000 (UTC) (envelope-from isoa@kapsi.fi) Received: from mail.kapsi.fi (mx1.kapsi.fi [IPv6:2001:1bc8:1004::1:25]) by mx1.freebsd.org (Postfix) with ESMTP id 4C81A8FC08 for ; Tue, 11 Sep 2012 17:59:00 +0000 (UTC) Received: from 91-157-164-122.elisa-laajakaista.fi ([91.157.164.122] helo=[192.168.255.133]) by mail.kapsi.fi with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TBUji-00052l-L3 for freebsd-questions@freebsd.org; Tue, 11 Sep 2012 20:58:58 +0300 Message-ID: <504F7BDE.9090106@kapsi.fi> Date: Tue, 11 Sep 2012 20:58:54 +0300 From: Arto Pekkanen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 91.157.164.122 X-SA-Exim-Mail-From: isoa@kapsi.fi X-SA-Exim-Scanned: No (on mail.kapsi.fi); SAEximRunCond expanded to false Subject: GELI provider and trim (BIO_DELETE) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 17:59:00 -0000 I have an SSD driver, rather new, and "camcontrol identify" reports it supports data set management (TRIM). I set up the disk so, that there is one slice. On this slice I put two BSD labes a and b with geli providers. On these geli providers I did newfs -t to enable trim. Does the trim BIO_DELETE commands fall thru to the SSD, if the filesystem decides a sector inside the geli provider is free to be reused? In short: does UFS -t and thus BIO_DELETE work with geli as expected? I have checked dmesg but did not catch any errors, so I have no way of knowing. -- Arto Pekkanen, säätäjä ksym@IRCnet