From owner-freebsd-geom@FreeBSD.ORG Sun Jan 14 00:31:11 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4CCCA16A417 for ; Sun, 14 Jan 2007 00:31:11 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id D461013C45B for ; Sun, 14 Jan 2007 00:31:10 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1H5tH5-0007YY-Gy for freebsd-geom@freebsd.org; Sun, 14 Jan 2007 01:31:03 +0100 Received: from p3ee2281c.dip0.t-ipconnect.de ([62.226.40.28]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Jan 2007 01:31:03 +0100 Received: from christian.baer by p3ee2281c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 14 Jan 2007 01:31:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Christian Baer Date: Sun, 14 Jan 2007 01:26:02 +0100 (CET) Organization: Convenimus Projekt Lines: 43 Message-ID: References: <20070113202018.GK90718@garage.freebsd.pl> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: p3ee2281c.dip0.t-ipconnect.de User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: What does geli attach -a do? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2007 00:31:11 -0000 On Sat, 13 Jan 2007 21:20:18 +0100 Pawel Jakub Dawidek wrote: > It'll tell you exact offset and size where corrupted data were detected. > It won't help you bring you data back, it's a security feature, not a > reliability feature, but can be used also to detect silent data > corruptions. Does that mean, it could probably tell me what file was affected >> Does it make sense to use this in combination with a mirror? > If you're afraid of silent data corruptions, then yes. When one half of > the mirror will be corrupted and geli will detect it, gmirror will read > the data from the other half. I'm not more afraid of those than of any other sort of breakdowns. :-) These are computers. They work but they also fail from time to time. I've lost quite a few HDs during the years that I've been working with computers now. Not all of the HDs went on friendly terms. :-) Basicly, the information is quite important but subject to constant changes. That is why I want to mirror the data, so I can have a pretty good chance of getting the changes back that were made between to backups. The question if this made sense in combination with a mirror went in another direction: Can gmirror detect which drive is holding the "right" data and retrieve it should a drive die? > Unfortunately authentication-only mode is not supported in geli at the > moment, so you have encryption/decription overhead. > If you don't care about this overhead, and don't care about security, > this is how you can create such configuration: Well, actually, I do care for security. Geli is already set up on the mirrors. I'm a little worried that this feature will however run the crap out of the CPUs. :-) This is a Sun U60 we are talking about. Not really what you'd call a CPU-monster. Copying a big file over the network onto an encrypted partition runs at about 5-6MB/s and uses 80-90% of both CPUs. There aren't many reserves to go around while doing that. Regards Chris