From owner-freebsd-fs@FreeBSD.ORG Tue Sep 18 06:10:01 2012 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 33A74106566C for ; Tue, 18 Sep 2012 06:10:01 +0000 (UTC) (envelope-from c.kworr@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id A54618FC0A for ; Tue, 18 Sep 2012 06:10:00 +0000 (UTC) Received: by bkcje9 with SMTP id je9so2721386bkc.13 for ; Mon, 17 Sep 2012 23:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=B2Bp3D2dEOgVe6RlSyz9Ivmpn52RqYb/RdnIJaW9e5U=; b=zvAxJh+Fg6W1UCxQrPSyoMDc3r3n0QNNGdiffQIGWbkmji3dIh0Y0hdyKCwYAGs3Bz As4zfdn+jLpKSMgpXSLokQdbxvsnRfTNRrgbuE2XK9DWIXnygKLyKjFw49cqybNB6vF0 Ve1xrper8GjuQ3n4elu90NYPkUPxdosDkk5SMSrdQQEkGDl0dHcHOtxJyzmhssxEg+AD fKZdWUillqIgeb3i0uW4LXmrVyOrmGfm0YOmj8bRl7OMdQoZ9JWImvqpsWb5NjUuebct ifhiv7nOQQWNFVZUDjc9a5fvwNYXRdPCP9HilQ16LTsr3nRgGf9T9mFPzvBzf3N6Nndl i/Fg== Received: by 10.204.156.18 with SMTP id u18mr1825406bkw.131.1347948599526; Mon, 17 Sep 2012 23:09:59 -0700 (PDT) Received: from limbo.xim.bz ([46.150.100.6]) by mx.google.com with ESMTPS id t23sm6800049bks.4.2012.09.17.23.09.57 (version=SSLv3 cipher=OTHER); Mon, 17 Sep 2012 23:09:58 -0700 (PDT) Message-ID: <50581033.4040102@gmail.com> Date: Tue, 18 Sep 2012 09:09:55 +0300 From: Volodymyr Kostyrko User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: =?UTF-8?B?IlRob21hcyBHw7ZsbG5lciAoTmV3c2xldHRlciki?= References: <001a01cd900d$bcfcc870$36f65950$@goelli.de> <504F282D.8030808@gmail.com> <000a01cd90aa$0a277310$1e765930$@goelli.de> <5050461A.9050608@gmail.com> <000001cd9239$ed734c80$c859e580$@goelli.de> <5052EC5D.4060403@gmail.com> <000a01cd9274$0aa0bba0$1fe232e0$@goelli.de> <505322C9.70200@gmail.com> <000001cd9377$e9e9b010$bdbd1030$@goelli.de> <50559CD8.1070700@gmail.com> <000001cd94f1$a4157030$ec405090$@goelli.de> In-Reply-To: <000001cd94f1$a4157030$ec405090$@goelli.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org Subject: Re: AW: AW: AW: AW: AW: ZFS: Corrupted pool metadata after adding vdev to a pool - no opportunity to rescue data from healthy vdevs? Remove a vdev? Rewrite metadata? 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: Tue, 18 Sep 2012 06:10:01 -0000 17.09.2012 19:29, Thomas Göllner (Newsletter) write: >> If you can afford putting your drives aside you can try to wait before some tool occasionally emerges. I will not promise anything >> but I'm slowly making some progress with my script. I'm motivated about that as I have broken pool with photos. Trying to import >> that pool is causing a core dump on any system I tested like OpenSolaris, Illumos or SystemRescueCD. > > It would be great if you script would be able to deal with pools with broken labels. I will put the three 3TB disks aside and use the old 1.5TB disks instead. So if there is some progress in your script or someone else is gonna write some tool for restoring labels or reading data of broken pools, perhaps I can get some data back. I think it would take some time to get this fresh 3TB pool full ;-) > > This would also solve the next problem I discovered... > These 1.5TB disks have 512byte sectors. I have one spare. If the second disk falls out, first I thought, I will replace it with a 4TB disk and so on until I have replaced all of them. So I can expand the pool. But as I read now, this is not possible, isn't it? Because the 4TB drives would have 4k sectors. From my point of view all hype about moving to 4k sectors is highly irrelevant to ZFS and current products on the market. 1. ZFS tends to use big recordsize for storing any data. This means most files on your drives are already stored in 128k sectors. Storing small tails in 512b or 4k sectors shouldn't give big difference. 2. For older drives each drive should be partitioned with respect to 4k sectors. This is what -a option of gpart does: it aligns created partitions to 4k sector bounds. But half a year ago I already found some drives that can auto-shift all disk transactions to optimize read and write performance. Courtesy of Microsoft Windows, OS that does not care about anything not written in license terms, same as the users do, so using this drives would be more straightforward and would not cause decent pain to IT stuff about realigning partitions the way it would just work. -- Sphinx of black quartz judge my vow.