From owner-freebsd-geom@FreeBSD.ORG Tue Feb 27 13:51:18 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 20C0C16A402 for ; Tue, 27 Feb 2007 13:51:18 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx2.netclusive.de (mx2.netclusive.de [89.110.132.132]) by mx1.freebsd.org (Postfix) with ESMTP id AB70D13C467 for ; Tue, 27 Feb 2007 13:51:17 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdca9.f.ppp-pool.de [195.4.220.169]) by mx2.netclusive.de (Postfix) with ESMTP id 2266E2600CC for ; Tue, 27 Feb 2007 14:22:01 +0100 (CET) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 3649215213; Tue, 27 Feb 2007 14:21:59 +0100 (CET) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Tue, 27 Feb 2007 14:21:59 +0100 (CET) Organization: Convenimus Projekt Lines: 114 Message-ID: NNTP-Posting-Host: garfield.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1172582519 74995 192.168.100.11 (27 Feb 2007 13:21:59 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Tue, 27 Feb 2007 13:21:59 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD) Subject: geli mirror with -a won't format 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: Tue, 27 Feb 2007 13:51:18 -0000 Hello there, peeps! I have been trying to create a filesystem for paranoid people like myself. :-) What I want to make is this: - mirror (two partitions with gmirror) - geli with -a on that I am not expecting anyone to manipulate my system. My data is far too unimportant (to other people) for that. But the file systems will contain stuff that is *very* important to me and I am hoping that -a will give me an early warning if the data becomes corrupt due to hardware failure. If I got the whole thing with -a wrong, then *my* problem is solved, as I won't be using -a. :-) But it could very well be an issue for other people. The commands I used are these (with the replies from the system): sunny# geli init -v -s 4096 -K - -a HMAC/SHA256 -e blowfish -l 448 -P /dev/mirror/home Metadata value stored on /dev/mirror/home. Done. sunny# geli attach -v -p -k - /dev/mirror/home Attched to /dev/mirror/home. Done. Note: The keyfile in both cases is created by a script and piped to geli. Now strangely, this looks ok so far. But it isn't. :-/ If I use the init without the -a I get this in /var/log/messages: kernel: GEOM_ELI: Device mirror/home.eli created. kernel: GEOM_ELI: Encryption: Blowfish-CBC 448 kernel: GEOM_ELI: Crypto: software I can do a newfs, mount the provider and work with it. That all stops when I activate authentication when initialising the provider (as shown in the comman above). /var/log/messages gets really messy then: kernel: GEOM_ELI: Device mirror/home.eli created. kernel: GEOM_ELI: Encryption: Blowfish-CBC 448 kernel: GEOM_ELI: Integrity: HMAC/SHA256 kernel: GEOM_ELI: Crypto: software kernel: GEOM_ELI: mirror/home.eli: kernel: 4096 bytes corrupte kernel: d at offset kernel: kernel: 11456892928 kernel: . kernel: GEOM_ELI: mirr kernel: or/home.eli kernel: : 4096 byte kernel: s corrupted kernel: at offset 0 kernel: . kernel: GEOM_ELI: mir kernel: r kernel: or/home.eli kernel: : 4096 byte kernel: s corrupted kernel: at offset 4 kernel: 096. kernel: GEOM_ELI: mirr kernel: or/home.eli kernel: : 4096 byte kernel: s corrupted kernel: at offset 0 kernel: . kernel: GEOM_ELI: mirr kernel: or/home.eli kernel: : 4096 byte kernel: s corrupted kernel: at offset 0 kernel: . kernel: GEOM_ELI: mi kernel: r kernel: ror/home.el kernel: i: 8192 byt kernel: es corrupte kernel: d kernel: at offset kernel: 0. I have tried changing the options for -a (md5 and sha1) and -e (AES only, 3DES is so damn slow that I didn't even *want* to try it) with the same result - basicly anyway. The output in /var/log/messages is a little different, showing the used algorithms but otherwise the same thing. As you can imagine, I can't even create a file system on that: sunny# newfs -U -O 2 /dev/mirror/home.eli /dev/mirror/home.eli: 10926.1MB (22376752 sectors) block size 16384, fragment size 4096 using 33 cylinder groups of 336.88MB, 21560 blks, 21568 inodes. with soft updates newfs: can't read old UFS1 superblock: read error from block device: Invalid argument I'm not sure if I messed up here or if the code might actually be broken. uname -a says this: FreeBSD sunny.rz1.convenimus.net 6.2-STABLE FreeBSD 6.2-STABLE #1: Tue Feb 27 11:08:32 CET 2007 root@sunny.rz1.convenimus.net: /usr/obj/usr/src/sys/SUNNY sparc64 As you can see, I am not running a standard Intel CPU, but a Sun U60 with 2 CPUs and 2GB of RAM.[1] The drives are two Seagate Cheetah SX173404LC with 73GB each. geli worked before on this system, but I didn't use -a back then. Can anyone help me? Regards Chris [1] Ok, you can't see all of that from the uname. :-)