From owner-freebsd-geom@FreeBSD.ORG Sun Sep 23 14:00:11 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D22E16A418 for ; Sun, 23 Sep 2007 14:00:11 +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 2EE8913C46E for ; Sun, 23 Sep 2007 14:00:11 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fddc5.f.ppp-pool.de [195.4.221.197]) (Authenticated sender: ncf1534p2) by mx2.netclusive.de (Postfix) with ESMTP id B587226021F for ; Sun, 23 Sep 2007 15:30:33 +0200 (CEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 808D715217; Sun, 23 Sep 2007 15:27:35 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Sun, 23 Sep 2007 15:27:35 +0200 (CEST) Organization: Convenimus Projekt Lines: 102 Message-ID: References: <200709222256.17692.yarodin@gmail.com> NNTP-Posting-Host: sunny.rz1.convenimus.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: nermal.rz1.convenimus.net 1190554055 83489 192.168.100.5 (23 Sep 2007 13:27:35 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 23 Sep 2007 13:27:35 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p7 (sparc64)) Subject: Re: Pipes password from kdialog to geli attach 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, 23 Sep 2007 14:00:11 -0000 On Sat, 22 Sep 2007 22:56:17 +0600 yarodin wrote: > init: > password=`kdialog --password "Enter the password"` > echo $password|sha256|geli init -s 4096 -P -K - /dev/ad0s1e Unless you are planning to create a lot of encrypted providers I don't really see a point in actually writing a script for this. The providers are usually initialized only once and then left like that for a really long time. You'd do just as well to do this directly from the console or in an Xterm. > atach: > password=`kdialog --password "Enter the password"` > echo $password|sha256|geli attach -p -k - /dev/ad0s1e Suggestion to add this: echo "Checking ..." fsck -fv -t ffs /dev/ad0s1e.eli if [ $? -eq 0 ]; then echo "Filesystem is ok, mounting it!" mount /dev/ad0s1e.eli [/usr/secure] if [ $? -eq 0 ]; then echo "Mount succeeded!" geli detach -l [/usr/secure] else echo "Mount failed, please check the filesystem manually!" fi else echo "fsck failed! Please check the filesystem manually!" fi Encrypted filesystems don't have dirty tags and there is no way to find out if the fs was unmounted cleanly or not. IMHO it's a good idea to run fsck over the fs before every mount. It takes a while longer but you are on the safe side. You can "spike" the command there a little to your liking using the -p, -F, -B, -n or -y flags. > Is it very unsecure? May be a better method exists? Yes and no. The script itself is fine. I don't see any security risks in the implementation. Make sure your shell doesn't keep any variables in the memory after finishing the script. However, I *do* see a risk in the possibly weak passphrase. Geli doesn't accept the Password piped to it, this only works with the keyfile (as you have written there). A keyfile should normally consist of random bits and because Geli assumes this, no salt is added. Unfortunately, remembering a sequenz of random bits or even characters isn't easy for a human and if this string is too short it is insecure by design and also compromises sha. Since you seem to be the system's administrator (root), you can work against this by issuing a strong passphrase. Create a keyfile with random characters (that can be input with the keyboard if need be) *and* think up a passphrase, preferably one containing characters (small and capitals), numbers, punctuation and symbols. Use known abreviations and ones you think up and even incorrect spelling if you like. The passphrase could bei something like this: "76% of the US of A's laW §s are old, outdated and completely useless(!); by design!" No, I don't want to start a political discussion and BTW: this is true for just about any country. :-) Note the capital 'W' in 'laW'. Doesn't look like much but will completely change the hash. This is a passphrase that will allmost certainly withstand a dictionary attack - although is doesn't even contain all the mentioned examples for illuding one, like strange spelling. Save the keyfile somewhere safe (in several places), including a USB-Stick. Then ask the user for both the passphrase and the keyfile and somehow interweave them. This follows the principle "something you have and something you know" as recommended by PHK. If You use a passphrase like the example I just made up, you should be pretty safe. If you have several providers you wish to attach, add a little something to each keyfile-passphrase-combo before piping it to the hash. Maybe something like this: echo "SeCuRE01${password}sEcUre01" | sha256 | geli attach -p -k - /dev/ad0s1e echo "SeCuRE02${password}sEcUre02" | sha256 | geli attach -p -k - /dev/ad1s1e This way you can attach all providers with one passphrase and still stay pretty secure. Remember, a weak passphrase *always* compromises security and even salt only mildly improves this. In this case you don't have any salt , so everything falls and stands with the good passphrase and how safe you keep your keyfile. If you are using a good passphrase, you might want to add "-l 256" to the init line, especially if the encrypted fs is pretty big. If you decide to use a weak passphrase or just a password, because you don't need that much security, don't add the -l option but instead "-e Blowfish". Blowfish is much faster than AES, especially with these short keylengths. It's not as secure as AES but still a lot harder to break open than a weak passphrase or password. I hope to have helped a little - without boring you too much. Regards Chris From owner-freebsd-geom@FreeBSD.ORG Sun Sep 23 15:26:46 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFDB16A417 for ; Sun, 23 Sep 2007 15:26:46 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id E905113C4B2 for ; Sun, 23 Sep 2007 15:26:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id BACC245EA7; Sun, 23 Sep 2007 17:26:44 +0200 (CEST) Received: from localhost (154.81.datacomsa.pl [195.34.81.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 69DDB45684; Sun, 23 Sep 2007 17:26:39 +0200 (CEST) Date: Sun, 23 Sep 2007 17:25:08 +0200 From: Pawel Jakub Dawidek To: yarodin Message-ID: <20070923152508.GB1123@garage.freebsd.pl> References: <200709222256.17692.yarodin@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <200709222256.17692.yarodin@gmail.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: Pipes password from kdialog to geli attach 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, 23 Sep 2007 15:26:46 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 22, 2007 at 10:56:17PM +0600, yarodin wrote: > init: > password=3D`kdialog --password "Enter the password"` > echo $password|sha256|geli init -s 4096 -P -K - /dev/ad0s1e >=20 > atach: > password=3D`kdialog --password "Enter the password"` > echo $password|sha256|geli attach -p -k - /dev/ad0s1e >=20 > Is it very unsecure? May be a better method exists? It depends. Most (if not all) shells have echo command built-in, so noone will see 'echo ' in ps(1) output, although, maybe simply do: kdialog --password "Enter the password" | geli attach -p -k - /dev/ad0s1e ? BTW. sha256 is not needed. Also, as it was mentioned, keyfiles are not preprocessed by PKCS#5v2, but this is a good example why it's worth adding such functionality. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG9oVUForvXbEpPzQRAjT9AKDFGypOVw+RAeqgJZHIFw5WLeA2xwCfTV5S 6RyFQIXwQ95uMDVB4GYmUdk= =48HN -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-geom@FreeBSD.ORG Sun Sep 23 18:06:45 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2521716A46C for ; Sun, 23 Sep 2007 18:06:45 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx3.netclusive.de (mx3.netclusive.de [89.110.132.133]) by mx1.freebsd.org (Postfix) with ESMTP id C62E413C50A for ; Sun, 23 Sep 2007 18:06:44 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fddc5.f.ppp-pool.de [195.4.221.197]) (Authenticated sender: ncf1534p2) by mx3.netclusive.de (Postfix) with ESMTP id B5E676049DC for ; Sun, 23 Sep 2007 20:06:43 +0200 (CEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 78C4D15217; Sun, 23 Sep 2007 20:03:42 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Sun, 23 Sep 2007 20:03:42 +0200 (CEST) Organization: Convenimus Projekt Lines: 28 Message-ID: References: <200709222256.17692.yarodin@gmail.com> <20070923152508.GB1123@garage.freebsd.pl> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1190570622 84770 192.168.100.5 (23 Sep 2007 18:03:42 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Sun, 23 Sep 2007 18:03:42 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p7 (sparc64)) Subject: Re: Pipes password from kdialog to geli attach 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, 23 Sep 2007 18:06:45 -0000 On Sun, 23 Sep 2007 17:25:08 +0200 Pawel Jakub Dawidek wrote: > BTW. sha256 is not needed. Could be a good idea though when mounting several providers with one keyfile/passphrase combination - if they are "salted". > Also, as it was mentioned, keyfiles are not preprocessed by PKCS#5v2, This however only provides additional protection when analising the disc and a part of the passphrase is known. A brute force attack against the passphrase will work just as well, no matter if it is salted or not. I know that *you* know that. :-) Just wanted to point it out again. > but this is a good example why it's worth adding such functionality. Good idea! I've been pondering the idea of writing a front-end for geli for some time but the fact of this missing feature stopped me because anyone using this frontend would lose functionality. If you make it possible to pass the passphrase on to geli from the command line or via a pipe or something, then I'll sit down and write the front-end for it. Provided, you don't expect me to do that in C. :-) Python would probably be my choice here. Regards, Chris From owner-freebsd-geom@FreeBSD.ORG Sun Sep 23 21:35:50 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7208C16A417 for ; Sun, 23 Sep 2007 21:35:50 +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 CE57113C45A for ; Sun, 23 Sep 2007 21:35:49 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZZ70-0001Ah-58 for freebsd-geom@freebsd.org; Sun, 23 Sep 2007 21:35:34 +0000 Received: from 89-172-44-225.adsl.net.t-com.hr ([89.172.44.225]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Sep 2007 21:35:34 +0000 Received: from ivoras by 89-172-44-225.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Sep 2007 21:35:34 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Sun, 23 Sep 2007 23:35:15 +0200 Lines: 38 Message-ID: References: <20070921143318.GC5690@garage.freebsd.pl> <20070921170506.GB9445@garage.freebsd.pl> <1310567292.20070921235802@gmail.com> <20070922011847.GH9445@garage.freebsd.pl> <1231480340.20070922112446@gmail.com> <20070922111958.GA1614@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigACE0CE5402A75E37DFC13772" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 89-172-44-225.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) In-Reply-To: <20070922111958.GA1614@garage.freebsd.pl> X-Enigmail-Version: 0.95.3 Sender: news Subject: Re: raidtest for zfs 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, 23 Sep 2007 21:35:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigACE0CE5402A75E37DFC13772 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pawel Jakub Dawidek wrote: > ZFS ZVOL doesn't present raw blocks to use, like graid3/graid5, so it's= > quite possible that because of how the data was written and how ZFS > prefetches the data it's faster than one disk. So does ZVOL actually offer "cooked" data to its users (caching, lazy allocation?), similar to what would happen if the entire ZVOL was one big file in a "normal" ZFS file system? Slightly off-topic: for most file systems, it used to be recommended that "lots of smallish files" be distributed in lots of directories in a radix-like fashion instead of keeping all files in one huge directory. Do you know if ZFS does something to help this situation, or are the old rules of thumb still applicable? --------------enigACE0CE5402A75E37DFC13772 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG9twTldnAQVacBcgRApujAKDR3sqoICUAm6M6ZMTlx+ZkgBOGewCfRa4c 8knVXM+Xs0al+LaMSXs7ty8= =CjT4 -----END PGP SIGNATURE----- --------------enigACE0CE5402A75E37DFC13772-- From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 00:10:03 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E6E016A417 for ; Mon, 24 Sep 2007 00:10:03 +0000 (UTC) (envelope-from fbsd06+OT=5f7b9a72@mlists.homeunix.com) Received: from turtle-out.mxes.net (turtle-out.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 3132B13C458 for ; Mon, 24 Sep 2007 00:10:03 +0000 (UTC) (envelope-from fbsd06+OT=5f7b9a72@mlists.homeunix.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by turtle-in.mxes.net (Postfix) with ESMTP id D701410546 for ; Sun, 23 Sep 2007 19:49:51 -0400 (EDT) Received: from gumby.homeunix.com. (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id DEF655190F for ; Sun, 23 Sep 2007 19:49:49 -0400 (EDT) Date: Mon, 24 Sep 2007 00:49:46 +0100 From: RW To: freebsd-geom@freebsd.org Message-ID: <20070924004946.0825d90b@gumby.homeunix.com.> In-Reply-To: References: <200709222256.17692.yarodin@gmail.com> X-Mailer: Claws Mail 3.0.0 (GTK+ 2.10.14; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Pipes password from kdialog to geli attach 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: Mon, 24 Sep 2007 00:10:03 -0000 On Sun, 23 Sep 2007 15:27:35 +0200 (CEST) Christian Baer wrote: > Blowfish". Blowfish is much faster than AES, especially with these > short keylengths. Is it? Blowfish is very fast when you use it to encrypt a whole file, but it deliberately has a high initialization cost to prevent its speed aiding a brute force attacks against beginning of the ciphertext. Presumably geli encrypts a sector at a time, so it's not obvious whether Blowfish is all that fast. Do you know of any Benchmarks for Blowfish verses AES? From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 09:10:26 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904B616A41B for ; Mon, 24 Sep 2007 09:10:26 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx3.netclusive.de (mx3.netclusive.de [89.110.132.133]) by mx1.freebsd.org (Postfix) with ESMTP id 1AEDB13C44B for ; Mon, 24 Sep 2007 09:10:26 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdcde.f.ppp-pool.de [195.4.220.222]) (Authenticated sender: ncf1534p2) by mx3.netclusive.de (Postfix) with ESMTP id B7BB3604BDE for ; Mon, 24 Sep 2007 11:10:24 +0200 (CEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id 84BDC15217; Mon, 24 Sep 2007 11:07:13 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Mon, 24 Sep 2007 11:07:13 +0200 (CEST) Organization: Convenimus Projekt Lines: 49 Message-ID: References: <200709222256.17692.yarodin@gmail.com> <15188.8009081178$1190592622@news.gmane.org> NNTP-Posting-Host: sunny.rz1.convenimus.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: nermal.rz1.convenimus.net 1190624833 88773 192.168.100.5 (24 Sep 2007 09:07:13 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Mon, 24 Sep 2007 09:07:13 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p7 (sparc64)) Subject: Re: Pipes password from kdialog to geli attach 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: Mon, 24 Sep 2007 09:10:26 -0000 On Mon, 24 Sep 2007 00:49:46 +0100 RW wrote: >> Blowfish". Blowfish is much faster than AES, especially with these >> short keylengths. > > Is it? Blowfish is very fast when you use it to encrypt a whole file, > but it deliberately has a high initialization cost to prevent its speed > aiding a brute force attacks against beginning of the ciphertext. I know the problem with the brute force attack - although IMHO you'd probably break it open more quickly if you attacked the passphrase. I gave this suggestion in direct combination with a weak passphrase or password, if only mild security was needed; like keeping love letters safe from your wife/girlfriend. :-) The weaknesses of Blowfish are well known, that is why the Bruce Schneier brought out a new Cypher (Twofish) together with John Kelsey, Doug Whiting, David Wagner, Chris Hall, and Niels Ferguson. > Presumably geli encrypts a sector at a time, so it's not obvious > whether Blowfish is all that fast. Do you know of any Benchmarks for > Blowfish verses AES? There are several out there but although they distinguisch AES128 and AES256, there is only one Blowfish and judging from the speed, I'd say they used a keylength of 448 bits. With such a long key, Blowfish is actually slower than AES - even if you encrypt a large file with it. You're right, geli does encrypt sector by sector. But first of all, the sectors aren't 512 bytes in size, but more like 4096 bytes and second, it doesn't use a new key for every sector. I'm afraid I have no benchmarks for you that will satisfy scientific standards. Older Versions of Truecrypt[1] supported Blowfish (it was removed a while back) and also had a benchmark where Blowfish was always on top - and 3DES always on the bottom. :-) I played around with geli a fair while back, trying AES and Blowfish. On that machine (AMD Tbred 2000) Blowfish was always a lot faster when the key was no longer than 256 bits. I tried that extensively by moving files around (from a non-encrypted provider to an encrypted one). Please don't ask me about the numbers, as I was really only playing around. The installation of a crypto-cárd was always planned and these little buggers are optimized for AES. I'm not even sure if they do anything else. Regards, Chris [1] http://www.truecrypt.org From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 09:20:39 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2850916A419 for ; Mon, 24 Sep 2007 09:20:39 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 6A15913C467 for ; Mon, 24 Sep 2007 09:20:38 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 5865B45E8F; Mon, 24 Sep 2007 11:20:36 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 15CA745E90; Mon, 24 Sep 2007 11:20:31 +0200 (CEST) Date: Mon, 24 Sep 2007 11:19:02 +0200 From: Pawel Jakub Dawidek To: Christian Baer Message-ID: <20070924091902.GB3320@garage.freebsd.pl> References: <200709222256.17692.yarodin@gmail.com> <20070923152508.GB1123@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8GpibOaaTibBMecb" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: Pipes password from kdialog to geli attach 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: Mon, 24 Sep 2007 09:20:39 -0000 --8GpibOaaTibBMecb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 23, 2007 at 08:03:42PM +0200, Christian Baer wrote: > On Sun, 23 Sep 2007 17:25:08 +0200 Pawel Jakub Dawidek wrote: >=20 > > BTW. sha256 is not needed. >=20 > Could be a good idea though when mounting several providers with one > keyfile/passphrase combination - if they are "salted". GELI already provides additional salt and pass passphrase/keyfiles through HMAC function. > > Also, as it was mentioned, keyfiles are not preprocessed by PKCS#5v2, >=20 > This however only provides additional protection when analising the disc > and a part of the passphrase is known. A brute force attack against the > passphrase will work just as well, no matter if it is salted or not. It's not about salt. The idea is to call HMAC some number of times on the passphrase and use the result. I use 131072 iterations with my passphrase, this means that to brute-force my passphrase an attacker needs 2^17 more steps to do for each password he wants to try. It takes about 2 seconds to calculate the key out of my passphrase because of those 2^17 steps. He can of course brute-force the result, but it's more or less totally random and for HMAC/SHA256 he has 2^256 steps to do. > > but this is a good example why it's worth adding such functionality. >=20 > Good idea! I've been pondering the idea of writing a front-end for geli > for some time but the fact of this missing feature stopped me because > anyone using this frontend would lose functionality. >=20 > If you make it possible to pass the passphrase on to geli from the command > line or via a pipe or something, then I'll sit down and write the > front-end for it. Provided, you don't expect me to do that in C. :-) > Python would probably be my choice here. We are planning to create graphic front-end to the GEOM in my company in python, but feel free to do a geli front-end as well:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --8GpibOaaTibBMecb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG94EGForvXbEpPzQRAgfSAJwL5v0j5yyptDnUCy3Ttok4UgdOHwCg7nBB qIdla0wchhpllrP8/yZ4uek= =l/Wx -----END PGP SIGNATURE----- --8GpibOaaTibBMecb-- From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 11:08:21 2007 Return-Path: Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88F8516A417 for ; Mon, 24 Sep 2007 11:08:21 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 484EF13C467 for ; Mon, 24 Sep 2007 11:08:21 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l8OB8LvR064160 for ; Mon, 24 Sep 2007 11:08:21 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l8OB8KFc064156 for freebsd-geom@FreeBSD.org; Mon, 24 Sep 2007 11:08:20 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Sep 2007 11:08:20 GMT Message-Id: <200709241108.l8OB8KFc064156@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 24 Sep 2007 11:08:21 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/89102 geom [geom_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o misc/113543 geom [geom] [patch] geom(8) utilities don't work inside the o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/115572 geom [gbde] gbde partitions fail at 28bit/48bit LBA address 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for f kern/105390 geom [geli] filesystem on a md backed by sparse file with s o kern/107707 geom [geom] [patch] add new class geom_xbox360 to slice up p bin/110705 geom gmirror control utility does not exit with correct exi o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [geom] [patch] improved gmirror balance algorithm o kern/114532 geom GEOM_MIRROR shows up in kldstat even if compiled in th o kern/115547 geom [geom] [patch] for GEOM Eli to get password from stdin 10 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 11:43:32 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3404E16A418 for ; Mon, 24 Sep 2007 11:43:32 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from mx3.netclusive.de (mx3.netclusive.de [89.110.132.133]) by mx1.freebsd.org (Postfix) with ESMTP id B4CF913C447 for ; Mon, 24 Sep 2007 11:43:31 +0000 (UTC) (envelope-from news@nermal.rz1.convenimus.net) Received: from nermal.rz1.convenimus.net (Fdcde.f.ppp-pool.de [195.4.220.222]) (Authenticated sender: ncf1534p2) by mx3.netclusive.de (Postfix) with ESMTP id 855FA604BB0 for ; Mon, 24 Sep 2007 13:43:30 +0200 (CEST) Received: by nermal.rz1.convenimus.net (Postfix, from userid 8) id EBE801521D; Mon, 24 Sep 2007 13:40:17 +0200 (CEST) To: freebsd-geom@freebsd.org Path: not-for-mail From: Christian Baer Newsgroups: gmane.os.freebsd.devel.geom Date: Mon, 24 Sep 2007 13:40:17 +0200 (CEST) Organization: Convenimus Projekt Lines: 65 Message-ID: References: <200709222256.17692.yarodin@gmail.com> <20070923152508.GB1123@garage.freebsd.pl> <20070924091902.GB3320@garage.freebsd.pl> NNTP-Posting-Host: sunny.rz1.convenimus.net X-Trace: nermal.rz1.convenimus.net 1190634017 88773 192.168.100.5 (24 Sep 2007 11:40:17 GMT) X-Complaints-To: abuse@convenimus.net NNTP-Posting-Date: Mon, 24 Sep 2007 11:40:17 +0000 (UTC) User-Agent: slrn/0.9.8.1 (FreeBSD/6.2-RELEASE-p7 (sparc64)) Subject: Re: Pipes password from kdialog to geli attach 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: Mon, 24 Sep 2007 11:43:32 -0000 On Mon, 24 Sep 2007 11:19:02 +0200 Pawel Jakub Dawidek wrote: >> > BTW. sha256 is not needed. >> Could be a good idea though when mounting several providers with one >> keyfile/passphrase combination - if they are "salted". > GELI already provides additional salt and pass passphrase/keyfiles > through HMAC function. Ok, my bad. I didn't mean the salt provided by geli, but this: echo "SeCuRE01${password}sEcUre01" | sha256 | geli attach -p -k - /dev/ad0s1e ^^^^^^^^ ^^^^^^^^ The underlined Stuff is the "salt". Not quite politically correct, but I couldn't really think of anything better to call it. > It's not about salt. The idea is to call HMAC some number of times on > the passphrase and use the result. I use 131072 iterations with my > passphrase, this means that to brute-force my passphrase an attacker > needs 2^17 more steps to do for each password he wants to try. > It takes about 2 seconds to calculate the key out of my passphrase > because of those 2^17 steps. If I understand you correctly, you are not actually adding more security to the passphrase but just making sure that each attack ist sufficiently expensive, meaning each attack takes about two seconds. How exactly do you do this? IIRC geli doesn't do this by itself. > He can of course brute-force the result, but it's more or less totally > random and for HMAC/SHA256 he has 2^256 steps to do. Well, not really 2^256 steps, just as many as it takes to find the right one. :-) We have 2^256 combinations but it is pretty unlikely that an attacker will have to go through all of them to find the correct one. But let's be optimistic about an attack. Say we need 2^128 of them to find the right "result" and one attack takes 10ms (which makes 100 tries per second). Then it would still take 2.589.667.936.993.443.405.352.926.997.197 *years* to break open the code - if I didn't mess something up on my calculator. :-) Just as a reference: our universe is estimated to be about 15.000.000.000 years old. An attacker will have to get *really* lucky or find a weakness in Rijndael. > We are planning to create graphic front-end to the GEOM in my company in > python, but feel free to do a geli front-end as well:) How concrete are these plans? I don't really think this is something that competition would help with. Sure, there is always more than one solution for a problem but this problem isn't really one that is crying out for several ones. Are you only planning on doing this "some day in the future"? Do you already have a roadmap? Is this for all of GEOM, including GELI? I realise that you can't share the details, I just want to avoid duplicating your work. Regards Chris From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 16:22:14 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DFB016A41A for ; Mon, 24 Sep 2007 16:22:14 +0000 (UTC) (envelope-from nino80@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 26E2F13C45B for ; Mon, 24 Sep 2007 16:22:13 +0000 (UTC) (envelope-from nino80@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1299709rvb for ; Mon, 24 Sep 2007 09:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9pG+tOkicEB3ic8qdmDJnQ1V8wFGKP+tDna5hsV38Vk=; b=nNdyYiRdX0sFm0I7rUFVhTJQfN/9MxuS7UUyBrHUPR18hg30M9lk0G/8XeGovoFRW+xKS0kYUL+I714XpiX4WlialfmW4BJZF2Ib+H0dw6qKPT03Mn0Fu/rvi9XPkQw7aG5MbBCOkpbMz1JCCgApUyPd97pOdZ+0w5CLcTCvJgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fsmuJ7bY9FfpPxaaJC4QG7vxTsMYcn5/ErUdhaeZnRZXAa1YJ7PGlHs1p67/s18eVbIQZj3nbI3AKv6kU4jNLRnrJ0agE831Ft8M4D/5jP+okYRE6yj53unlxEx3Jyp6mTTlQe96x9jbkVKI5eNNI5QdkD3GscGlpiygKxrtwgA= Received: by 10.141.203.12 with SMTP id f12mr1707637rvq.1190650932665; Mon, 24 Sep 2007 09:22:12 -0700 (PDT) Received: by 10.141.18.7 with HTTP; Mon, 24 Sep 2007 09:22:12 -0700 (PDT) Message-ID: <92bcbda50709240922j614b2a8aka7d360d366c02221@mail.gmail.com> Date: Mon, 24 Sep 2007 18:22:12 +0200 From: "n j" To: "Ivan Voras" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92bcbda50709120843o6af4bd38v8725be3f5b765b0e@mail.gmail.com> <20070913081748.GA1155@garage.freebsd.pl> <92bcbda50709210437g590df3f9y94f32d3d4d5cd1f@mail.gmail.com> Cc: freebsd-geom@freebsd.org Subject: Re: Gmirror on a partition of a slice 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: Mon, 24 Sep 2007 16:22:14 -0000 On 9/21/07, Ivan Voras wrote: > > The logic behind this is probably that if you already partition or > > label the underlying consumers, you must not do the same with the > > provided mirror, i.e. you can't really treat the provided mirror as an > > entirely fresh new disk. As I said, this is maybe obvious to someone, > > but for me it was new. > Actually, you *can* do it if you really want to, because every GEOM > provider is a "whole disk" to the system, it's just that usually it's > not what you want. That is what I thought at first, but I spent a couple of days trying to boot off such a geom "disk" and had absolutely no success until I skipped the two steps Pawel pointed out. Actually, I'm beginning to think that OS has to read the boot code from an actual (physical) disk partition like da0s1a/da1s1a. In case you skip fdisk&bsdlabel on the gmirrored partition, gm0 remains the exact copy of the actual boot partition, da0s1a, and OS boots. By fdisk'ing and bsdlabel'ing the newly created disk, gm0, my understanding is that you actually change the underlying (boot) partition, da0s1a, and mess it up enough to make the system unbootable. The above interpretation, OTOH, might be completely wrong. My understanding of the boot process is very vague and you might be right. I'm not saying it's not possible, I'm just saying that I tried it and it didn't work, no matter how hard I try. If you care to describe the necessary steps on how to do it, I'll try again. Regards, -- Nino From owner-freebsd-geom@FreeBSD.ORG Mon Sep 24 19:44:57 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACB5316A469 for ; Mon, 24 Sep 2007 19:44:57 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.188]) by mx1.freebsd.org (Postfix) with ESMTP id 86A8613C459 for ; Mon, 24 Sep 2007 19:44:57 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1345827rvb for ; Mon, 24 Sep 2007 12:44:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=/uiOsO6nv9tnZi4Rc5VHtzVEnlFEHa1sCU+u8xBRiOo=; b=elBe1l+3C5y8uWm6nKpcuyu/zgUH/CR7FJlbFw+CXZ1oizF3Dskn6cpVizO/lurKrjIJVPWzFvO+0Y7bat/zw99R1GuT54N9lsNL7V35qUA8LdepCAKIeEW1Civcyy7/m88NIS/avi9d2/yThniai5aQs6ZzqtiSbk2CvY6kpSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=igQnLNCZTfv85cD3Ke4pmr+fXSqlwMIL9rVptyjjbYD+C3tdw6ryFxBFCjx/RZNRPbL/kqBcFORwo73E+JXLDH0jn7zP4wB878QwC3fL09Sq4R5hdlgJz0R/jt469ghLEmO12igcQjaCtlA2q8HRhD5ANLl1oWrSje2+vUWZtUw= Received: by 10.114.112.1 with SMTP id k1mr712772wac.1190661389507; Mon, 24 Sep 2007 12:16:29 -0700 (PDT) Received: by 10.141.159.3 with HTTP; Mon, 24 Sep 2007 12:16:29 -0700 (PDT) Message-ID: <9bbcef730709241216p629f36b4o730e93ef34813678@mail.gmail.com> Date: Mon, 24 Sep 2007 21:16:29 +0200 From: "Ivan Voras" Sender: ivoras@gmail.com To: "n j" In-Reply-To: <92bcbda50709240922j614b2a8aka7d360d366c02221@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <92bcbda50709120843o6af4bd38v8725be3f5b765b0e@mail.gmail.com> <20070913081748.GA1155@garage.freebsd.pl> <92bcbda50709210437g590df3f9y94f32d3d4d5cd1f@mail.gmail.com> <92bcbda50709240922j614b2a8aka7d360d366c02221@mail.gmail.com> X-Google-Sender-Auth: 6a2e3d944d789e72 Cc: freebsd-geom@freebsd.org Subject: Re: Gmirror on a partition of a slice 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: Mon, 24 Sep 2007 19:44:57 -0000 On 24/09/2007, n j wrote: > On 9/21/07, Ivan Voras wrote: > > Actually, you *can* do it if you really want to, because every GEOM > > provider is a "whole disk" to the system, it's just that usually it's > > not what you want. > > That is what I thought at first, but I spent a couple of days trying > to boot off such a geom "disk" and had absolutely no success until I > skipped the two steps Pawel pointed out. Actually, I'm beginning to > think that OS has to read the boot code from an actual (physical) disk > partition like da0s1a/da1s1a. In case you skip fdisk&bsdlabel on the Yes. > gmirrored partition, gm0 remains the exact copy of the actual boot > partition, da0s1a, and OS boots. By fdisk'ing and bsdlabel'ing the > newly created disk, gm0, my understanding is that you actually change > the underlying (boot) partition, da0s1a, and mess it up enough to make > the system unbootable. Yes. > The above interpretation, OTOH, might be completely wrong. My > understanding of the boot process is very vague and you might be > right. I'm not saying it's not possible, I'm just saying that I tried > it and it didn't work, no matter how hard I try. If you care to > describe the necessary steps on how to do it, I'll try again. When the machine boots, it sees the drives as ordinary devices, as it has no knowledge of gmirror. You can boot from one of these "ordinary" drives, and when the kernel boots, it recognizes gmirror's signature, reconstitutes the RAID and continues to work with it. But in the time between between when you turn the machine on and when kernel brings the GEOM system up, all you have are individual, disconnected drives. This works because the drives are by default accessed strictly read-only in this time frame. This is also how all other software RAID solutions work. From owner-freebsd-geom@FreeBSD.ORG Tue Sep 25 04:55:34 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEEAE16A418 for ; Tue, 25 Sep 2007 04:55:33 +0000 (UTC) (envelope-from aw1@stade.co.uk) Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by mx1.freebsd.org (Postfix) with ESMTP id 1E84713C447 for ; Tue, 25 Sep 2007 04:55:32 +0000 (UTC) (envelope-from aw1@stade.co.uk) Received: from 5aca3c02.bb.sky.com ([90.202.60.2] helo=access2.hanley.stade.co.uk) by lon-mail-4.gradwell.net with esmtp (Gradwell gwh-smtpd 1.257) id 46f876e8.84ee.2d for freebsd-geom@freebsd.org; Tue, 25 Sep 2007 03:48:08 +0100 (envelope-sender ) Received: from steerpike.hanley.stade.co.uk (steerpike [192.168.1.10]) by access2.hanley.stade.co.uk (8.14.1/8.14.1) with ESMTP id l8P2m7Nk062221 for ; Tue, 25 Sep 2007 03:48:07 +0100 (BST) (envelope-from aw1@steerpike.hanley.stade.co.uk) Received: from steerpike.hanley.stade.co.uk (localhost [127.0.0.1]) by steerpike.hanley.stade.co.uk (8.14.1/8.14.1) with ESMTP id l8P2m6Zh059121 for ; Tue, 25 Sep 2007 03:48:06 +0100 (BST) (envelope-from aw1@steerpike.hanley.stade.co.uk) Received: (from aw1@localhost) by steerpike.hanley.stade.co.uk (8.14.1/8.14.1/Submit) id l8P2m6ZH059120 for freebsd-geom@freebsd.org; Tue, 25 Sep 2007 03:48:06 +0100 (BST) (envelope-from aw1) Date: Tue, 25 Sep 2007 03:48:06 +0100 From: Adrian Wontroba To: freebsd-geom@freebsd.org Message-ID: <20070925024806.GA56751@steerpike.hanley.stade.co.uk> References: <92bcbda50709120843o6af4bd38v8725be3f5b765b0e@mail.gmail.com> <20070913081748.GA1155@garage.freebsd.pl> <92bcbda50709210437g590df3f9y94f32d3d4d5cd1f@mail.gmail.com> <92bcbda50709240922j614b2a8aka7d360d366c02221@mail.gmail.com> <9bbcef730709241216p629f36b4o730e93ef34813678@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9bbcef730709241216p629f36b4o730e93ef34813678@mail.gmail.com> User-Agent: Mutt/1.4.2.2i X-Operating-System: FreeBSD 6.2-STABLE Organization: Oh dear, I've joined one again. X-Virus-Scanned: ClamAV 0.91.2/4387/Tue Sep 25 02:45:10 2007 on access2.hanley.stade.co.uk X-Virus-Scanned: ClamAV 0.91.2/4387/Tue Sep 25 02:45:10 2007 on steerpike.hanley.stade.co.uk X-Virus-Status: Clean Subject: Re: Gmirror on a partition of a slice X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aw1@stade.co.uk List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2007 04:55:34 -0000 On Mon, Sep 24, 2007 at 09:16:29PM +0200, Ivan Voras wrote: > On 24/09/2007, n j wrote: < discussion about creating bootable mirrored disks with gmirror> This is possibly germane. I have very recently rebuilt my home file server, because the disks were wearing out, I was starting to be squeezed for space, and (P)ATA drives will soon start to become scarce. The rest of the system is old, a MSI KT6 Delta FIS2R MS-6590 motherboard, Athlon 3200 XP processor, and a couple of old (one very old) Promise ATA cards. I can't afford to replace the lot. I've rebuilt it on 4 new 500 GB disks, with a single slice per disk, multiple partitions, the root filesystem mirrored on all 4 drives, other filesystems and swap each on a stripe of two mirrors, and everything labeled. I chose to have a single large /home partition to avoid the spare space over there not here syndrome, which will be "fun" when an underlying mirror is re-silvered, and even more "fun" if the system panics or my UPS fails when /home is active. I decided not to use ("dangerously") dedicated disks. [ e.g. the workstation looks like this: [aw1@steerpike ~]$ gmirror status Name Status Components mirror/m1 COMPLETE ad4 ad6 [aw1@steerpike ~]$ bsdlabel /dev/mirror/m1s1 # /dev/mirror/m1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 524288 16 4.2BSD 2048 16384 32776 b: 4142720 524304 swap c: 312576642 0 unused 0 0 # "raw" part, don't edit d: 1048576 4667024 4.2BSD 2048 16384 8 e: 33554432 5715600 4.2BSD 2048 16384 28552 f: 273306610 39270032 4.2BSD 2048 16384 28552 [aw1@steerpike ~]$ df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/m1s1a 253678 82756 150628 35% / devfs 1 1 0 100% /dev /dev/mirror/m1s1d 507630 165158 301862 35% /var /dev/mirror/m1s1e 16244334 9750688 5194100 65% /usr /dev/mirror/m1s1f 132349372 50545228 71216196 42% /home /dev/md0 126702 540 116026 0% /tmp devfs 1 1 0 100% /var/named/dev ] To avoid finger trouble I threw together a makefile (which is as usual somewhat indigestible) to set up the disks and GEOMs and perform the restores. It may be of use to others. The GEOM names are a bit strange because I'm including the abbreviated machine name in each, and I seemed to run into problems with 9 character names. Performance is adequate. Copying (tar | tar) an 18 GB package collection within /home took 21 minutes. I intend to run disk benchmarks and try different gmirror balance algorithms and split sizes (easy) and different gstripe stripe sizes (harder) to determine what suits me. I'll be doing the same thing with the simpler 2 disk mirror workstation in a week or so. I'll post that makefile too. "make -n" output and initial disk label (where you set the partition sizes), the makefile, the new /etc/fstab and dmesg follow. Note that this approach only works if you can initially boot the system from something else (LiveCD, FreeSBIE, ...) and have your dumps accessible too (external USB hard disk). If you can't, look at http://people.freebsd.org/~rse/mirror/ which is Ralf S. Engelschall's ingenious howto remotely upgrade a single disk to a mirrored dual disk system. His introduction states: The following is a step-by-step command list for remotely converting a production FreeBSD 6.2-STABLE (i386 or amd64 PC architecture based) system from a single-disk/single-slice (ad0s1) to a two-disk/single-slice (ad0s1 & ad1s1) GEOM mirror (gm0) based setup without the need for console access or Fixit/LiveFS CDROM: (awk lives!) - narrative stops here - (8-( [aw1@rottcodd /root/setup_disks]$ make -n disks # set up disks, slices, partitions # quick, restartable logger -p crit "disks start" echo `date` " disks start" dd if=/dev/zero of=/dev/ad4 bs=512 count=32 fdisk -BI ad4 dd if=/dev/zero of=/dev/ad4s1 bs=512 count=32 bsdlabel -R -B ad4s1 initial.label bsdlabel ad4s1 > ad4s1.label dd if=/dev/zero of=/dev/ad6 bs=512 count=32 fdisk -BI ad6 dd if=/dev/zero of=/dev/ad6s1 bs=512 count=32 bsdlabel -R -B ad6s1 initial.label bsdlabel ad6s1 > ad6s1.label dd if=/dev/zero of=/dev/ad8 bs=512 count=32 fdisk -BI ad8 dd if=/dev/zero of=/dev/ad8s1 bs=512 count=32 bsdlabel -R -B ad8s1 initial.label bsdlabel ad8s1 > ad8s1.label dd if=/dev/zero of=/dev/ad10 bs=512 count=32 fdisk -BI ad10 dd if=/dev/zero of=/dev/ad10s1 bs=512 count=32 bsdlabel -R -B ad10s1 initial.label bsdlabel ad10s1 > ad10s1.label logger -p crit "disks end" echo `date` " disks end" [aw1@rottcodd /root/setup_disks]$ make -n geoms # stop and clear any GEOMs left over from last attempt # quick, restartable logger -p crit "geoms start" echo `date` " geoms start" gmirror stop -v gmrcroot gmirror clear ad4s1a ad6s1a ad8s1a ad10s1a gstripe stop -v gsrcvar gstripe clear -v gmrcvar1 gmrcvar2 gmirror stop -v gmrcvar1 gmirror clear -v ad4s1d ad8s1d gmirror stop -v gmrcvar2 gmirror clear -v ad6s1d ad10s1d gstripe stop -v gsrcusr gstripe clear -v gmrcusr1 gmrcusr2 gmirror stop -v gmrcusr1 gmirror clear -v ad4s1e ad8s1e gmirror stop -v gmrcusr2 gmirror clear -v ad6s1e ad10s1e glabel stop rcswp glabel clear -v gsrcswp gstripe stop -v gsrcswp gstripe clear -v gmrcswp1 gmrcswp2 gmirror stop -v gmrcswp1 gmirror clear -v ad4s1f ad8s1f gmirror stop -v gmrcswp2 gmirror clear -v ad6s1f ad10s1f gstripe stop -v gsrchom gstripe clear -v gmrchom1 gmrchom2 gmirror stop -v gmrchom1 gmirror clear -v ad4s1g ad8s1g gmirror stop -v gmrchom2 gmirror clear -v ad6s1g ad10s1g # bring on the geoms logger -p crit "gmrcroot" gmirror label -v -h -b prefer -s 1048576 gmrcroot ad4s1a ad6s1a ad8s1a ad10s1a logger -p crit "gsrcvar" gmirror label -v -h -b prefer -s 1048576 gmrcvar1 ad4s1d ad8s1d gmirror label -v -h -b prefer -s 1048576 gmrcvar2 ad6s1d ad10s1d gstripe label -v -h -s 16777216 gsrcvar /dev/mirror/gmrcvar1 /dev/mirror/gmrcvar2 logger -p crit "gsrcusr" gmirror label -v -h -b prefer -s 1048576 gmrcusr1 ad4s1e ad8s1e gmirror label -v -h -b prefer -s 1048576 gmrcusr2 ad6s1e ad10s1e gstripe label -v -h -s 16777216 gsrcusr /dev/mirror/gmrcusr1 /dev/mirror/gmrcusr2 logger -p crit "gsrcswp" gmirror label -v -h -b prefer -s 1048576 gmrcswp1 ad4s1f ad8s1f gmirror label -v -h -b prefer -s 1048576 gmrcswp2 ad6s1f ad10s1f gstripe label -v -h -s 16777216 gsrcswp /dev/mirror/gmrcswp1 /dev/mirror/gmrcswp2 glabel label -v rcswap /dev/stripe/gsrcswp logger -p crit "gsrchom" gmirror label -v -h -b prefer -s 1048576 gmrchom1 ad4s1g ad8s1g gmirror label -v -h -b prefer -s 1048576 gmrchom2 ad6s1g ad10s1g gstripe label -v -h -s 16777216 gsrchom /dev/mirror/gmrchom1 /dev/mirror/gmrchom2 logger -p crit "geoms end" echo `date` " geoms end" [aw1@rottcodd /root/setup_disks]$ make -n restore # restore filesystems # SLOW, NOT RESTARTABLE logger -p crit "restore start" echo `date` " restore start" mkdir /root/setup_disks/rottcodd_disks logger -p crit "root" newfs -U -L rcroot /dev/mirror/gmrcroot > rcroot.newfs mount /dev/ufs/rcroot /root/setup_disks/rottcodd_disks; cd /root/setup_disks/rottcodd_disks; time restore -r -f /root/setup_disks/root.dmp; rm -f restoresymtable logger -p crit "var" newfs -U -L rcvar /dev/stripe/gsrcvar > rcvar.newfs mount /dev/ufs/rcvar /root/setup_disks/rottcodd_disks/var; cd /root/setup_disks/rottcodd_disks/var; time restore -r -f /root/setup_disks/var.dmp; rm -f restoresymtable logger -p crit "usr" newfs -U -L rcusr /dev/stripe/gsrcusr > rcusr.newfs mount /dev/ufs/rcusr /root/setup_disks/rottcodd_disks/usr; cd /root/setup_disks/rottcodd_disks/usr; time restore -r -f /root/setup_disks/usr.dmp; rm -f restoresymtable logger -p crit "home" newfs -U -L rchome /dev/stripe/gsrchom > rchome.newfs mount /dev/ufs/rchome /root/setup_disks/rottcodd_disks/home; cd /root/setup_disks/rottcodd_disks/home; time restore -r -f /root/setup_disks/home.dmp; rm -f restoresymtable rm -rf /root/setup_disks/rottcodd_disks/root/setup_disks mkdir /root/setup_disks/rottcodd_disks/root/setup_disks df -Hi | tee df.info cp -v Makefile *.label *.newfs *.info /root/setup_disks/rottcodd_disks/root/setup_disks/ logger -p crit "restore end" echo `date` " restore end" echo "think about editing /root/setup_disks/rottcodd_disks/etc/fstab and boot/loader.conf!!!!" ==> /rottcodd/root/setup_disks/initial.label <== # # size offset fstype [fsize bsize bps/cpg] a: 2g 16 4.2BSD 4096 16384 75 # root, mirrored b: 8G * unused # spare, e.g. for crash dump dumpdev c: * * unused # whole disk (slice) - leave alone d: 8G * 4.2BSD # var, mirrored and striped e: 16G * 4.2BSD # usr, mirrored and striped f: 4G * 4.2BSD # swap, mirrored and striped g: * * 4.2BSD # home, mirrored and striped ==> /rottcodd/root/setup_disks/Makefile <== # # set up and restore a resilient system on 4 large and identical disks, each containing a single slice # # machine expected to be running on something else, such as FreeSBIE or other LiveCD # # root is mirrored # swap, var, usr and home are each striped on top of a pair of mirrors # partition adNs1b is unused - may be used as a crash dump device or for experimentation # # partition filesizes are specified in the file initial.label # # it is assumed that this make file, initial.sizes and root.dmp, var.dmp, usr.dmp and home.dmp # reside in the current directory of another (external) disk drive # # it is also assumed that the kernel modules for gmirror, gstripe and glabel have already # been loaded # # targets # ------- # # disks - set up the disks, specifically, for each: # zero out the first 32 blocks # create a DOS compatible disk, with one slice (DOS partition) over the whole disk # label the slice, creating (FreeBSD) partitions # quick # restartable # # geoms - set up the mirrors and stripes, specifically # destroy any geoms left over from previous runs # for each top level object # set up the mirrors # set up the slices (not for the root partition) # labels swap partion # quick # restartable # # restore - restore the dumps # for each filesystem: # newfs (and label) # restore # SLOW # NOT RESTARTABLE # leaves filesystems mounted, creates a directory used as a mount point which is not removed, etc # # naming convention # ----------------- # # PR is a 2 character prefix, which should be a very short abreviation of the machine name # # mirrors start gmPR, and are followed by a 3 letter (possibly abbreviated) filesystem / swap name # and then, if part of a stripe, a digit. # # stripes start gsPR and are followed by a 3 letter (possibly abbreviated) filesystem / swap name. # # labels start PR and are followed by the filesystem name or swap. # # end result # ---------- # # Script started on Mon Sep 24 04:34:27 2007 # [root@rottcodd /home/tmp]# df -H # Filesystem Size Used Avail Capacity Mounted on # /dev/ufs/rcroot 2.1G 82M 1.8G 4% / # devfs 1.0k 1.0k 0B 100% /dev # /dev/ufs/rcvar 17G 48M 15G 0% /var # /dev/ufs/rcusr 33G 2.2G 28G 7% /usr # /dev/ufs/rchome 890G 195G 624G 24% /home # /dev/md0 130M 74k 119M 0% /tmp # devfs 1.0k 1.0k 0B 100% /var/named/dev # [root@rottcodd /home/tmp]# glabel status # Name Status Components # ufs/rcroot N/A mirror/gmrcroot # ufs/rcvar N/A stripe/gsrcvar # ufs/rcusr N/A stripe/gsrcusr # label/rcswap N/A stripe/gsrcswp # ufs/rchome N/A stripe/gsrchom # [root@rottcodd /home/tmp]# gstripe status # Name Status Components # stripe/gsrcvar UP mirror/gmrcvar1 # mirror/gmrcvar2 # stripe/gsrcusr UP mirror/gmrcusr1 # mirror/gmrcusr2 # stripe/gsrcswp UP mirror/gmrcswp1 # mirror/gmrcswp2 # stripe/gsrchom UP mirror/gmrchom1 # mirror/gmrchom2 # [root@rottcodd /home/tmp]# gmirror status # Name Status Components # mirror/gmrcroot COMPLETE ad4s1a # ad6s1a # ad8s1a # ad10s1a # mirror/gmrcvar1 COMPLETE ad4s1d # ad8s1d # mirror/gmrcusr1 COMPLETE ad4s1e # ad8s1e # mirror/gmrcswp1 COMPLETE ad4s1f # ad8s1f # mirror/gmrchom1 COMPLETE ad4s1g # ad8s1g # mirror/gmrcvar2 COMPLETE ad6s1d # ad10s1d # mirror/gmrcusr2 COMPLETE ad6s1e # ad10s1e # mirror/gmrcswp2 COMPLETE ad6s1f # ad10s1f # mirror/gmrchom2 COMPLETE ad6s1g # ad10s1g # [root@rottcodd /home/tmp]# exit # # Script done on Mon Sep 24 04:35:40 2007 # # ROTTCODD SPECIFIC! # PREFIX?= rc NAME?= rottcodd DISK1?= ad4 DISK2?= ad6 DISK3?= ad8 DISK4?= ad10 BALANCE?= prefer # gmirror balance algorithm, load, prefer, round-robin, split # prefer seems to give the best performance for large files SLICE?= 1048576 # gmirror split slice size STRIPE?= 16777216 # gtripe stripe size disks: # set up disks, slices, partitions # quick, restartable @logger -p crit "${.TARGET} start" @echo `date` " ${.TARGET} start" dd if=/dev/zero of=/dev/${DISK1} bs=512 count=32 fdisk -BI ${DISK1} dd if=/dev/zero of=/dev/${DISK1}s1 bs=512 count=32 bsdlabel -R -B ${DISK1}s1 initial.label bsdlabel ${DISK1}s1 > ${DISK1}s1.label dd if=/dev/zero of=/dev/${DISK2} bs=512 count=32 fdisk -BI ${DISK2} dd if=/dev/zero of=/dev/${DISK2}s1 bs=512 count=32 bsdlabel -R -B ${DISK2}s1 initial.label bsdlabel ${DISK2}s1 > ${DISK2}s1.label dd if=/dev/zero of=/dev/${DISK3} bs=512 count=32 fdisk -BI ${DISK3} dd if=/dev/zero of=/dev/${DISK3}s1 bs=512 count=32 bsdlabel -R -B ${DISK3}s1 initial.label bsdlabel ${DISK3}s1 > ${DISK3}s1.label dd if=/dev/zero of=/dev/${DISK4} bs=512 count=32 fdisk -BI ${DISK4} dd if=/dev/zero of=/dev/${DISK4}s1 bs=512 count=32 bsdlabel -R -B ${DISK4}s1 initial.label bsdlabel ${DISK4}s1 > ${DISK4}s1.label @logger -p crit "${.TARGET} end" @echo `date` " ${.TARGET} end" geoms: # stop and clear any GEOMs left over from last attempt # quick, restartable @logger -p crit "${.TARGET} start" @echo `date` " ${.TARGET} start" -gmirror stop -v gm${PREFIX}root -gmirror clear ${DISK1}s1a ${DISK2}s1a ${DISK3}s1a ${DISK4}s1a -gstripe stop -v gs${PREFIX}var -gstripe clear -v gm${PREFIX}var1 gm${PREFIX}var2 -gmirror stop -v gm${PREFIX}var1 -gmirror clear -v ${DISK1}s1d ${DISK3}s1d -gmirror stop -v gm${PREFIX}var2 -gmirror clear -v ${DISK2}s1d ${DISK4}s1d -gstripe stop -v gs${PREFIX}usr -gstripe clear -v gm${PREFIX}usr1 gm${PREFIX}usr2 -gmirror stop -v gm${PREFIX}usr1 -gmirror clear -v ${DISK1}s1e ${DISK3}s1e -gmirror stop -v gm${PREFIX}usr2 -gmirror clear -v ${DISK2}s1e ${DISK4}s1e -glabel stop ${PREFIX}swp -glabel clear -v gs${PREFIX}swp -gstripe stop -v gs${PREFIX}swp -gstripe clear -v gm${PREFIX}swp1 gm${PREFIX}swp2 -gmirror stop -v gm${PREFIX}swp1 -gmirror clear -v ${DISK1}s1f ${DISK3}s1f -gmirror stop -v gm${PREFIX}swp2 -gmirror clear -v ${DISK2}s1f ${DISK4}s1f -gstripe stop -v gs${PREFIX}hom -gstripe clear -v gm${PREFIX}hom1 gm${PREFIX}hom2 -gmirror stop -v gm${PREFIX}hom1 -gmirror clear -v ${DISK1}s1g ${DISK3}s1g -gmirror stop -v gm${PREFIX}hom2 -gmirror clear -v ${DISK2}s1g ${DISK4}s1g # bring on the geoms @logger -p crit "gm${PREFIX}root" gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}root ${DISK1}s1a ${DISK2}s1a ${DISK3}s1a ${DISK4}s1a @logger -p crit "gs${PREFIX}var" gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}var1 ${DISK1}s1d ${DISK3}s1d gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}var2 ${DISK2}s1d ${DISK4}s1d gstripe label -v -h -s ${STRIPE} gs${PREFIX}var /dev/mirror/gm${PREFIX}var1 /dev/mirror/gm${PREFIX}var2 @logger -p crit "gs${PREFIX}usr" gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}usr1 ${DISK1}s1e ${DISK3}s1e gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}usr2 ${DISK2}s1e ${DISK4}s1e gstripe label -v -h -s ${STRIPE} gs${PREFIX}usr /dev/mirror/gm${PREFIX}usr1 /dev/mirror/gm${PREFIX}usr2 @logger -p crit "gs${PREFIX}swp" gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}swp1 ${DISK1}s1f ${DISK3}s1f gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}swp2 ${DISK2}s1f ${DISK4}s1f gstripe label -v -h -s ${STRIPE} gs${PREFIX}swp /dev/mirror/gm${PREFIX}swp1 /dev/mirror/gm${PREFIX}swp2 glabel label -v ${PREFIX}swap /dev/stripe/gs${PREFIX}swp @logger -p crit "gs${PREFIX}hom" gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}hom1 ${DISK1}s1g ${DISK3}s1g gmirror label -v -h -b ${BALANCE} -s 1048576 gm${PREFIX}hom2 ${DISK2}s1g ${DISK4}s1g gstripe label -v -h -s ${STRIPE} gs${PREFIX}hom /dev/mirror/gm${PREFIX}hom1 /dev/mirror/gm${PREFIX}hom2 @logger -p crit "${.TARGET} end" @echo `date` " ${.TARGET} end" restore: # restore filesystems # SLOW, NOT RESTARTABLE @logger -p crit "${.TARGET} start" @echo `date` " ${.TARGET} start" mkdir ${.CURDIR}/${NAME}_disks @logger -p crit "root" newfs -U -L ${PREFIX}root /dev/mirror/gm${PREFIX}root > ${PREFIX}root.newfs mount /dev/ufs/${PREFIX}root ${.CURDIR}/${NAME}_disks; cd ${.CURDIR}/${NAME}_disks; time restore -r -f ${.CURDIR}/root.dmp; rm -f restoresymtable @logger -p crit "var" newfs -U -L ${PREFIX}var /dev/stripe/gs${PREFIX}var > ${PREFIX}var.newfs mount /dev/ufs/${PREFIX}var ${.CURDIR}/${NAME}_disks/var; cd ${.CURDIR}/${NAME}_disks/var; time restore -r -f ${.CURDIR}/var.dmp; rm -f restoresymtable @logger -p crit "usr" newfs -U -L ${PREFIX}usr /dev/stripe/gs${PREFIX}usr > ${PREFIX}usr.newfs mount /dev/ufs/${PREFIX}usr ${.CURDIR}/${NAME}_disks/usr; cd ${.CURDIR}/${NAME}_disks/usr; time restore -r -f ${.CURDIR}/usr.dmp; rm -f restoresymtable @logger -p crit "home" newfs -U -L ${PREFIX}home /dev/stripe/gs${PREFIX}hom > ${PREFIX}home.newfs mount /dev/ufs/${PREFIX}home ${.CURDIR}/${NAME}_disks/home; cd ${.CURDIR}/${NAME}_disks/home; time restore -r -f ${.CURDIR}/home.dmp; rm -f restoresymtable rm -rf ${.CURDIR}/${NAME}_disks/root/setup_disks mkdir ${.CURDIR}/${NAME}_disks/root/setup_disks df -Hi | tee df.info cp -v Makefile *.label *.newfs *.info ${.CURDIR}/${NAME}_disks/root/setup_disks/ @logger -p crit "${.TARGET} end" @echo `date` " ${.TARGET} end" echo "think about editing ${.CURDIR}/${NAME}_disks/etc/fstab and boot/loader.conf!!!!" (ugh!) ==> /rottcodd/etc/fstab <== # # Device Mountpoint FStype Options Dump Pass# /dev/ufs/rcroot / ufs rw 1 1 /dev/label/rcswap none swap sw 0 0 /dev/ufs/rcvar /var ufs rw 2 2 /dev/ufs/rcusr /usr ufs rw 2 3 /dev/ufs/rchome /home ufs rw 2 4 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 ==> /rottcodd/var/run/dmesg.boot <== Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-STABLE #0: Fri Sep 14 07:28:55 BST 2007 toor@steerpike.hanley.stade.co.uk:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 3200+ (2205.02-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 536805376 (511 MB) avail memory = 515883008 (491 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) atapci0: port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f mem 0xdfffc000-0xdfffffff irq 16 at device 5.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0xd800-0xd807,0xd400-0xd403,0xd000-0xd007,0xcc00-0xcc03,0xc800-0xc80f mem 0xdfff4000-0xdfff7fff irq 19 at device 7.0 on pci0 ata4: on atapci1 ata5: on atapci1 bge0: mem 0xdffb0000-0xdffbffff irq 18 at device 11.0 on pci0 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:0c:76:e9:64:ee fwohci0: port 0xc400-0xc47f mem 0xdfff3800-0xdfff3fff irq 17 at device 14.0 on pci0 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 8. fwohci0: EUI64 00:10:dc:00:00:5e:9f:42 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:10:dc:5e:9f:42 fwe0: Ethernet address: 02:10:dc:5e:9f:42 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.0 on pci0 ata0: on atapci2 ata1: on atapci2 uhci0: port 0xb400-0xb41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xb800-0xb81f irq 21 at device 16.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbc00-0xbc1f irq 21 at device 16.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xc000-0xc01f irq 21 at device 16.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xdfff3600-0xdfff36ff irq 21 at device 16.4 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 pci0: at device 17.5 (no driver attached) acpi_button1: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 fdc0: port 0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcefff,0xcf000-0xd17ff,0xd1800-0xd3fff,0xd4000-0xd57ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2205015338 Hz quality 800 Timecounters tick every 1.000 msec acd0: DVDR at ata0-master UDMA33 ad4: 476940MB at ata2-master UDMA100 ad6: 476940MB at ata3-master UDMA100 ad8: 476940MB at ata4-master UDMA100 ad10: 476940MB at ata5-master UDMA100 GEOM_MIRROR: Device gmrcroot created (id=1307788816). GEOM_MIRROR: Device gmrcroot: provider ad4s1a detected. GEOM_MIRROR: Device gmrcvar1 created (id=1430879240). GEOM_MIRROR: Device gmrcvar1: provider ad4s1d detected. GEOM_MIRROR: Device gmrcusr1 created (id=3106786564). GEOM_MIRROR: Device gmrcusr1: provider ad4s1e detected. GEOM_MIRROR: Device gmrcswp1 created (id=3502221240). GEOM_MIRROR: Device gmrcswp1: provider ad4s1f detected. GEOM_MIRROR: Device gmrchom1 created (id=616768274). GEOM_MIRROR: Device gmrchom1: provider ad4s1g detected. GEOM_MIRROR: Device gmrcroot: provider ad6s1a detected. GEOM_MIRROR: Device gmrcvar2 created (id=1509388684). GEOM_MIRROR: Device gmrcvar2: provider ad6s1d detected. GEOM_MIRROR: Device gmrcusr2 created (id=3198564396). GEOM_MIRROR: Device gmrcusr2: provider ad6s1e detected. GEOM_MIRROR: Device gmrcswp2 created (id=339401470). GEOM_MIRROR: Device gmrcswp2: provider ad6s1f detected. GEOM_MIRROR: Device gmrchom2 created (id=3338347599). GEOM_MIRROR: Device gmrchom2: provider ad6s1g detected. GEOM_MIRROR: Device gmrcroot: provider ad8s1a detected. GEOM_MIRROR: Device gmrcvar1: provider ad8s1d detected. GEOM_MIRROR: Device gmrcvar1: provider ad8s1d activated. GEOM_MIRROR: Device gmrcvar1: provider ad4s1d activated. GEOM_MIRROR: Device gmrcvar1: provider mirror/gmrcvar1 launched. GEOM_MIRROR: Device gmrcusr1: provider ad8s1e detected. GEOM_MIRROR: Device gmrcusr1: provider ad8s1e activated. GEOM_MIRROR: Device gmrcusr1: provider ad4s1e activated. GEOM_MIRROR: Device gmrcusr1: provider mirror/gmrcusr1 launched. GEOM_MIRROR: Device gmrcswp1: provider ad8s1f detected. GEOM_MIRROR: Device gmrcswp1: provider ad8s1f activated. GEOM_MIRROR: Device gmrcswp1: provider ad4s1f activated. GEOM_MIRROR: Device gmrcswp1: provider mirror/gmrcswp1 launched. GEOM_MIRROR: Device gmrchom1: provider ad8s1g detected. GEOM_MIRROR: Device gmrchom1: provider ad8s1g activated. GEOM_MIRROR: Device gmrchom1: provider ad4s1g activated. GEOM_MIRROR: Device gmrchom1: provider mirror/gmrchom1 launched. GEOM_MIRROR: Device gmrcroot: provider ad10s1a detected. GEOM_MIRROR: Device gmrcroot: provider ad10s1a activated. GEOM_MIRROR: Device gmrcroot: provider ad8s1a activated. GEOM_MIRROR: Device gmrcroot: provider ad6s1a activated. GEOM_MIRROR: Device gmrcroot: provider ad4s1a activated. GEOM_MIRROR: Device gmrcroot: provider mirror/gmrcroot launched. GEOM_MIRROR: Device gmrcvar2: provider ad10s1d detected. GEOM_MIRROR: Device gmrcvar2: provider ad10s1d activated. GEOM_MIRROR: Device gmrcvar2: provider ad6s1d activated. GEOM_MIRROR: Device gmrcvar2: provider mirror/gmrcvar2 launched. GEOM_MIRROR: Device gmrcusr2: provider ad10s1e detected. GEOM_MIRROR: Device gmrcusr2: provider ad10s1e activated. GEOM_MIRROR: Device gmrcusr2: provider ad6s1e activated. GEOM_MIRROR: Device gmrcusr2: provider mirror/gmrcusr2 launched. GEOM_MIRROR: Device gmrcswp2: provider ad10s1f detected. GEOM_MIRROR: Device gmrcswp2: provider ad10s1f activated. GEOM_MIRROR: Device gmrcswp2: provider ad6s1f activated. GEOM_MIRROR: Device gmrcswp2: provider mirror/gmrcswp2 launched. GEOM_MIRROR: Device gmrchom2: provider ad10s1g detected. GEOM_MIRROR: Device gmrchom2: provider ad10s1g activated. GEOM_MIRROR: Device gmrchom2: provider ad6s1g activated. GEOM_MIRROR: Device gmrchom2: provider mirror/gmrchom2 launched. GEOM_STRIPE: Device gsrcvar created (id=937835587). GEOM_STRIPE: Disk mirror/gmrcvar1 attached to gsrcvar. GEOM_STRIPE: Device gsrcusr created (id=533043218). GEOM_STRIPE: Disk mirror/gmrcusr1 attached to gsrcusr. GEOM_STRIPE: Device gsrcswp created (id=534629169). GEOM_STRIPE: Disk mirror/gmrcswp1 attached to gsrcswp. GEOM_STRIPE: Device gsrchom created (id=2161269149). GEOM_STRIPE: Disk mirror/gmrchom1 attached to gsrchom. GEOM_LABEL: Label for provider mirror/gmrcroot is ufs/rcroot. GEOM_STRIPE: Disk mirror/gmrcvar2 attached to gsrcvar. GEOM_STRIPE: Device gsrcvar activated. GEOM_STRIPE: Disk mirror/gmrcusr2 attached to gsrcusr. GEOM_STRIPE: Device gsrcusr activated. GEOM_STRIPE: Disk mirror/gmrcswp2 attached to gsrcswp. GEOM_STRIPE: Device gsrcswp activated. GEOM_STRIPE: Disk mirror/gmrchom2 attached to gsrchom. GEOM_STRIPE: Device gsrchom activated. GEOM_LABEL: Label for provider stripe/gsrcvar is ufs/rcvar. GEOM_LABEL: Label for provider stripe/gsrcusr is ufs/rcusr. GEOM_LABEL: Label for provider stripe/gsrcswp is label/rcswap. GEOM_LABEL: Label for provider stripe/gsrchom is ufs/rchome. Trying to mount root from ufs:/dev/ufs/rcroot bge0: link state changed to UP -- Adrian Wontroba Definitions of hardware and software for dummies: Hardware is what you kick; Software is what you curse. From owner-freebsd-geom@FreeBSD.ORG Tue Sep 25 10:41:45 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBF0B16A419; Tue, 25 Sep 2007 10:41:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 64BBA13C447; Tue, 25 Sep 2007 10:41:45 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0D9A745E90; Tue, 25 Sep 2007 12:41:43 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F33F345B26; Tue, 25 Sep 2007 12:41:38 +0200 (CEST) Date: Tue, 25 Sep 2007 12:40:10 +0200 From: Pawel Jakub Dawidek To: Ivan Voras Message-ID: <20070925104010.GA1572@garage.freebsd.pl> References: <20070921143318.GC5690@garage.freebsd.pl> <20070921170506.GB9445@garage.freebsd.pl> <1310567292.20070921235802@gmail.com> <20070922011847.GH9445@garage.freebsd.pl> <1231480340.20070922112446@gmail.com> <20070922111958.GA1614@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: raidtest for zfs 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, 25 Sep 2007 10:41:45 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 23, 2007 at 11:35:15PM +0200, Ivan Voras wrote: > Pawel Jakub Dawidek wrote: >=20 > > ZFS ZVOL doesn't present raw blocks to use, like graid3/graid5, so it's > > quite possible that because of how the data was written and how ZFS > > prefetches the data it's faster than one disk. >=20 > So does ZVOL actually offer "cooked" data to its users (caching, lazy > allocation?), similar to what would happen if the entire ZVOL was one > big file in a "normal" ZFS file system? Yes. > Slightly off-topic: for most file systems, it used to be recommended > that "lots of smallish files" be distributed in lots of directories in a > radix-like fashion instead of keeping all files in one huge directory. > Do you know if ZFS does something to help this situation, or are the old > rules of thumb still applicable? ZFS uses extendable hash data structure for directory entires, but you would need to test it on your own to see if its fast enough for your needs. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFG+OWKForvXbEpPzQRAiAVAKCgwqtqJa6Q5Lgprmf+uppPgjK1uQCfWX1e WMHjWMkhux6w+PZL7Eo4Gs4= =P3Ge -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-freebsd-geom@FreeBSD.ORG Wed Sep 26 08:17:00 2007 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8987C16A417 for ; Wed, 26 Sep 2007 08:17:00 +0000 (UTC) (envelope-from matt.shaw@telefonicamovil.cl) Received: from alq198.internetdsl.tpnet.pl (alq198.internetdsl.tpnet.pl [83.17.46.198]) by mx1.freebsd.org (Postfix) with SMTP id D5B2113C458 for ; Wed, 26 Sep 2007 08:16:59 +0000 (UTC) (envelope-from matt.shaw@telefonicamovil.cl) Received: from glf ([43.139.55.103]) by alq198.internetdsl.tpnet.pl (8.13.3/8.13.3) with SMTP id l8Q8JCdk068425; Wed, 26 Sep 2007 10:19:12 +0200 Message-ID: <46FA14FD.3040802@homex.com.mx> Date: Wed, 26 Sep 2007 10:14:53 +0200 From: User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Oh yeah baby 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: Wed, 26 Sep 2007 08:17:00 -0000 Hey man, all these games are free. No gimmicks. http://85.10.10.209/