From owner-freebsd-current@FreeBSD.ORG Tue Apr 29 14:05:36 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 111F837B401 for ; Tue, 29 Apr 2003 14:05:36 -0700 (PDT) Received: from sauron.fto.de (p15106025.pureserver.info [217.160.140.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E98043FA3 for ; Tue, 29 Apr 2003 14:05:35 -0700 (PDT) (envelope-from hschaefer@fto.de) Received: from localhost (localhost.fto.de [127.0.0.1]) by sauron.fto.de (Postfix) with ESMTP id 08ECD25C100; Tue, 29 Apr 2003 23:05:35 +0200 (CEST) Received: from sauron.fto.de ([127.0.0.1]) by localhost (sauron [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16578-06; Tue, 29 Apr 2003 23:05:34 +0200 (CEST) Received: from giskard.foundation.hs (p509197A0.dip.t-dialin.net [80.145.151.160]) by sauron.fto.de (Postfix) with ESMTP id AFDD125C0C2; Tue, 29 Apr 2003 23:05:33 +0200 (CEST) Received: from daneel.foundation.hs (daneel.foundation.hs [192.168.20.2]) by giskard.foundation.hs (8.9.3/8.9.3) with ESMTP id XAA67862; Tue, 29 Apr 2003 23:05:31 +0200 (CEST) (envelope-from hschaefer@fto.de) Date: Tue, 29 Apr 2003 23:05:30 +0200 (CEST) From: Heiko Schaefer X-X-Sender: heiko@daneel.foundation.hs To: Terry Lambert In-Reply-To: <3EAECC0A.388DDCFC@mindspring.com> Message-ID: <20030429225636.C23260@daneel.foundation.hs> References: <20030429155751.K20908@daneel.foundation.hs> <3EAECC0A.388DDCFC@mindspring.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at fto.de cc: freebsd-current@freebsd.org Subject: Re: gbde data corruption? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2003 21:05:36 -0000 Hi Terry, > > > > apparently updating g_bde_crypt.c from rev 1.12 to 1.13 has effects on the > > format of data or the layout of the encrypted filesystem. the stuff that > > was on that mount with the old kernel is gone now. > > > > i'll refill the volume and report any issues that still remain. > > While you are at it, consider "man tunefs", and read about the > "-m" option to see why "-m 0" is a terrible thing to do; in > particular, read the first and last paragraphs. i believe i'm aware of the issues with "tunefs -m 0". i only use it as a temporary means of cramming data onto disks. with 60GB drives it sometimes comes in handy to temporarily use those 8% (4.6GB in that case). of course i leave minfree at 8% on filesystems to which i write regularly. my comments on speed were unrelated to tunefs-related slowness, but i suppose it is reasonable to expect a "tunefs -m 0"'d filesystem to be reliable, albeit slow. that was what concerned me. but as it turned out, i just used a broken version of the gbde code. initial fiddling points that poul's hint of using "-i" when gdbe initing and setting the sector_size improves speed greatly for me. anyway, thanks for pointing it out - there are certainly enough other obvious things that i'm not aware of :) cheers, Heiko