From owner-freebsd-geom@FreeBSD.ORG Sat Feb 2 11:03:25 2008 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 6CBF916A419 for ; Sat, 2 Feb 2008 11:03:25 +0000 (UTC) (envelope-from lightmoogle@hotmail.com) Received: from bay0-omc1-s31.bay0.hotmail.com (bay0-omc1-s31.bay0.hotmail.com [65.54.246.103]) by mx1.freebsd.org (Postfix) with ESMTP id 513A513C459 for ; Sat, 2 Feb 2008 11:03:25 +0000 (UTC) (envelope-from lightmoogle@hotmail.com) Received: from BAY121-W12 ([207.46.10.47]) by bay0-omc1-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Feb 2008 02:51:20 -0800 Message-ID: X-Originating-IP: [69.145.234.160] From: Andrew B To: Date: Sat, 2 Feb 2008 10:51:19 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2008 10:51:20.0014 (UTC) FILETIME=[8B2FA6E0:01C86589] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Geli sector size > 8192 completely breaks. 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: Sat, 02 Feb 2008 11:03:25 -0000 I've been trying to get GELI working in a number of ways, and it seems when= ever I change the sector size to 16384 or higher, I can't run newfs on the = resultant encrypted volume. Using dd with sector size 16384 gives me the greatest performance for the s= ector size I'm willing to have. It's very close to the maximum transfer rat= e of my drive. Nevertheless, using a sector size of 16K makes it so I can't= run newfs: # geli init -s 16384 /dev/ad4; geli attach /dev/ad4 Enter passphrase: # newfs /dev/ad4.eli=20 # newfs /dev/stripe/raids.eli=20 /dev/stripe/raids.eli: 715404.8MB (1465149120 sectors) block size 16384, fr= agment size 16384 using 797 cylinder groups of 898.39MB, 57497 blks, 14400 inodes. newfs: can't read old UFS1 superblock: read error from block device: Invali= d argument As you can see, it's detecting the sector size of the device in the block a= nd fragment size. I'm not sure why the error occurs, and it occurs _only_ o= n sector sizes larger than 8192 (I've only tried powers of 2). In testing, I've created a stripe across multiple 16384 geli devices with 1= 6384 sector size, same issue; I've also done it with a geom_RAID5 device on= top.. same issue still. Interestingly, I'm not able to _seek_ with the 16k= sector size. # dd if=3D/dev/stripe/raids.eli of=3D/dev/null bs=3D1m seek=3D16384M dd: /dev/null: Inappropriate ioctl for device I can "skip" as that reads in the data and merely discards it, or I can sta= rt from zero and read. The ioctl error also applies with the 8192, 4096 and= probably other sector sizes. I'm a bit confused, then.. it seems like without setting it higher that 819= 2, I lose a bit of performance. Setting it higher, however, causes newfs to= fail. dd continues to work like a champ, however. Is this proper behavior = for geli? (I.e. man page is lacking an upper bound on sector size.) Or alte= rnatively, is there a bug in geli somewhere? or is something else going on = and I'm just too tired at the moment to comprehend it? 6.2-RELEASE-p10 FreeBSD 6.2-RELEASE-p10 #1: i386 I do get _fairly_ good transfer -- the parent device yields 50.3MB/s, while= the GELI device yields 46MB/s with a 16384 sector size, or 43MB/s with an = 8192 sector size. This is with a 1.5GHz via C7 and the padlock module compi= led in. During those tests, dd showed 2% CPU; top showed .5% user, 26% syst= em, 4% interrupt, on average. Not bad, I'd say, for a 12watt processor :-) -DrkShadow lightmoogle@hotmail.com _________________________________________________________________ Connect and share in new ways with Windows Live. http://www.windowslive.com/share.html?ocid=3DTXT_TAGHM_Wave2_sharelife_0120= 08=