From owner-freebsd-current@FreeBSD.ORG Tue Apr 29 08:27:13 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 0D12437B401 for ; Tue, 29 Apr 2003 08:27:13 -0700 (PDT) Received: from sauron.fto.de (p15106025.pureserver.info [217.160.140.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FC1B43F85 for ; Tue, 29 Apr 2003 08:27:12 -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 A65A325C0F9; Tue, 29 Apr 2003 17:27:11 +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 02445-09; Tue, 29 Apr 2003 17:27:10 +0200 (CEST) Received: from giskard.foundation.hs (p509197A0.dip.t-dialin.net [80.145.151.160]) by sauron.fto.de (Postfix) with ESMTP id 5149B25C0C2; Tue, 29 Apr 2003 17:27:10 +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 RAA66117; Tue, 29 Apr 2003 17:27:04 +0200 (CEST) (envelope-from hschaefer@fto.de) Date: Tue, 29 Apr 2003 17:27:03 +0200 (CEST) From: Heiko Schaefer X-X-Sender: heiko@daneel.foundation.hs To: Poul-Henning Kamp In-Reply-To: <51195.1051628837@critter.freebsd.dk> Message-ID: <20030429171204.W20908@daneel.foundation.hs> References: <51195.1051628837@critter.freebsd.dk> 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 15:27:13 -0000 Hi Poul, > >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. > > Yes, I fumbled a commit and slipped in some debugging code in 1.12. judging by your commit message, at first i thought that 'debugging' implied only some lack in performance - or too much verbosity. > I've had 1.13 running my toture-test here for 38 hours now with no > trouble. i'll stress-test it some more after i get to reboot that machine physically this evening. mounting the filesystems that used to make some sense with 1.12 after upgrading to 1.13 apparently hanged the machine after some short time. my hope is to eventually have an nfs server (200gb data is waiting to live on it) that can saturize 100mbit - and is also reliable :) how much (incompatible) change in the format of the gbde data do you expect ? can i hope for something stable in 5.1, for example ?! > >> PS: i also have some performance issues with gbde, about which i'll whine > >> some other time :) it seems to me that the transactions on the disc (the > >> way i use gbde at least) are too small to reach the theoretical speed of > >> the harddrive. > > Much worse than that: They get cut into smaller I/O requests and the > cpu has to chew on them a lot. While GBDE is not directly slow, it > will never be as fast as an unencrypted partitition. hm... cpu seems to be not the limiting factor at all - that machine has an athlon 1800+ and is idle >>50% most of the time. without understanding the technical details, it seems to me that working on bigger chunks of the disc at a time would result in much more throughput. in general, as long as the cpu is not maxed out, shouldn't only latency - but not throughput - be impacted by using gbde? in absolute terms: getting approximately 1,5MB/s for writing access on a relatively modern harddisk seems quite low to me. does the data get scattered on the physical disc, or what could cause this ? read access is less tragic - approx 10MB/s (compared to slightly over 20MB/s on the same drive with a non-gbde mount) - but i also don't quite understand what leads to that. regards, thanks for the quick reply, Heiko