From owner-freebsd-fs@FreeBSD.ORG Sat Jun 25 14:26:55 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D4AB106564A for ; Sat, 25 Jun 2011 14:26:55 +0000 (UTC) (envelope-from tdgx86@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id F3FC08FC0C for ; Sat, 25 Jun 2011 14:26:54 +0000 (UTC) Received: by gxk28 with SMTP id 28so1902312gxk.13 for ; Sat, 25 Jun 2011 07:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=q9Txle6QOp7uejuAh2aFXFdGzsPTyMk7D5lNJin0o5o=; b=O43YlQh/XUSpXaICs9UC335x4tid+NV0QtVEgwEXC0Nm7hcuDbDDiqOFJdJpv44/SX HXskbPZcyCeK8eLAAGSjdJq9+IN2EEHNZH+6V71fNRTDa4TNoJBn488IGsBO/L6g+Fzw jGOeoZ71Jbco4CXhFUQ5qGMsee385oiqQaoUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qVPTALFSKWJKWxQ8omeX9JdLy0kOqWp8Y/A2get2ZSFSdGd+Dm4Su6z6Z1G4pfgLrZ k4zJFbexQC7FfAhYdPWtsFcXuECpU1Nv9Ck2uYQDcNO629205F3dfPpmSHWOPb4+2OXr KGIt+e46E5GYTDcT7ryWU5Z7qLRBjwpeGkKLg= MIME-Version: 1.0 Received: by 10.100.55.33 with SMTP id d33mr3967759ana.151.1309010482662; Sat, 25 Jun 2011 07:01:22 -0700 (PDT) Received: by 10.100.189.20 with HTTP; Sat, 25 Jun 2011 07:01:22 -0700 (PDT) Date: Sat, 25 Jun 2011 09:01:22 -0500 Message-ID: From: Troy Drake To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: GEOM: the primary GPT table is corrupt or invalid after RAIDZ creation X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 14:26:55 -0000 I have recently setup a new file server with 5x 2TB Samsung 4K sector drives in a RAIDZ array and after going through the steps of creating GPT partitions to set the alignment a 1 MB aligned sector (block 2048) and gnop to force 4k sectors and finally a RAIDZ array, I receive the following warning: GEOM: ad6: the primary GPT table is corrupt or invalid. GEOM: ad6: using the secondary instead -- recovery strongly advised. (Snipped, but applies to ad8, ad10, ad12, ad14 identically). The steps I used to setup this array are as follows: gpart create -s GPT ad6 (and to all others) gpart add -t freebsd-zfs -b 2048 ad6 (and to all others) gnop create -S 4086 ad6 zpool create raidz tank ad6.nop ad8 ad10 ad12 ad14 zpool export tank gnop destroy ad6.nop zpool import tank Even though the pool works fine, gpart for all disks show no geometry: gpart: No such geom: ad6. (et al.) Now the pools status is good with no errors, however performance seems a bit backwards to me: #/usr/bin/time dd if=/dev/zero of=/tank/foo1 bs=2M count=10000 10000+0 records in 10000+0 records out 20971520000 bytes transferred in 66.247113 secs (316565040 bytes/sec) 66.24 real 0.01 user 12.44 sys # /usr/bin/time dd if=/tank/foo1 of=/dev/null bs=2M 10000+0 records in 10000+0 records out 20971520000 bytes transferred in 102.649646 secs (204301922 bytes/sec) 102.65 real 0.00 user 5.71 sys 316 MB/sec writes and 204 MB/sec reads, I would expect it the other way around, but this is consistent performance after running similar dd tests many times. Writes are always faster than reads. My main concern is reliability and the ability to import this pool into perhaps into another OS just in case. Is the GEOM warnings about a corrupt or invalid primary table a concern? Are the steps I'm using best practices or is there a better way? I've searched the lists and Google and what little I can find this seems like a verbose warning but isn't too much to be concerned about, but these are my first 4K sector disks on ZFS so I'm wanting to make sure before loading it up with data. The performance of writes faster than reads makes me has me a bit concerned though. Interestingly, if I start over and create a nop on the slice at step 4 - (gnop create -S 4096 ad6p1.nop) ad6 will retain its valid GPT table however the rest wont as they don't get nop'd. However that makes me unsure that ad6 itself aligned properly, or that ad6 is aligned the same as the rest of the disks. Regards, Troy