From owner-freebsd-fs@FreeBSD.ORG Fri Jul 5 19:38:25 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5EDD43B5 for ; Fri, 5 Jul 2013 19:38:25 +0000 (UTC) (envelope-from mxb@alumni.chalmers.se) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) by mx1.freebsd.org (Postfix) with ESMTP id D497B1F54 for ; Fri, 5 Jul 2013 19:38:23 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id fe20so2299936lab.6 for ; Fri, 05 Jul 2013 12:38:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=G/la65njL0hOn+VoHkr99xy6E6D+RTz/Znh9pUsmuQ8=; b=agii92WS8uDI/agw9nQeQn81X5yjubZ3ECfubnzj/jmcJSQa0rEVtRmJlkpLyb2iDd XlYQ3Dp5seDnIQGkhR/HQlb8WjXDJhDCxmtvF93G2yrqnS9IgIKhNz9WPU1i17UbuAzv 4WbYRgXXYSSqBbO9pkzqTAp1hiv4JWv7cqDMc+cOqQkVTgXH+rOGXhO/7Zz7Ns2b/4Ga hYPn4zDmKqdNGVH1BGnSlAKf3Erris+8XBmqBHHEbwwf407mlQv1MKYANyA45ZGmBK9r QwoMdpv1O8CLoBIPpDjQZpXgGZnx9aCbCYp+7o+c1guTsZkqvS9mc4HwPLGI5HBlhE+x 1B5A== X-Received: by 10.112.180.164 with SMTP id dp4mr6206009lbc.68.1373053097025; Fri, 05 Jul 2013 12:38:17 -0700 (PDT) Received: from grey.home.unixconn.com (h-74-23.a183.priv.bahnhof.se. [46.59.74.23]) by mx.google.com with ESMTPSA id b8sm3391190lah.0.2013.07.05.12.38.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Jul 2013 12:38:15 -0700 (PDT) Subject: Re: Slow resilvering with mirrored ZIL Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=us-ascii From: mxb X-Priority: 3 In-Reply-To: Date: Fri, 5 Jul 2013 21:38:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9052B6E6-F742-4C10-87B5-2EFE03FDB31E@alumni.chalmers.se> References: <20130704000405.GA75529@icarus.home.lan> <20130704171637.GA94539@icarus.home.lan> <2A261BEA-4452-4F6A-8EFB-90A54D79CBB9@alumni.chalmers.se> <20130704191203.GA95642@icarus.home.lan> <43015E9015084CA6BAC6978F39D22E8B@multiplay.co.uk> <3CFB4564D8EB4A6A9BCE2AFCC5B6E400@multiplay.co.uk> <51D6A206.2020303@digsys.bg> <20130705145332.GA5449@icarus.home.lan> To: Steven Hartland X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQkYFrlXrzTsbwYa6hYzQf7eSvGATG7yv4KTFc0l510hgLw5xe5WWbK9wiYKwMNeBVJiQyzw Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 19:38:25 -0000 Thanks everyone for a very good info provided in this discussion! Question is if I should wait for resilvering to finish? It runs at 97B/s = now. Do I have any other options in this situation? Put back old disk? I really don't want to lose all data on this pool. //mxb On 5 jul 2013, at 17:52, Steven Hartland = wrote: > ----- Original Message ----- From: "Jeremy Chadwick" >=20 >> I'm not "damning FreeBSD", I'm just stating that this is the reality = of >> the situation. For example -- only recently in stable/9 (maybe >> stable/8, didn't look) were quirks added for Intel SSDs which came to >> market over 2 years ago (BTW thanks for adding those Steve). >=20 > Just to confirm both stable/8 and stable/9 are in sync with head for = all > the SSD quirks. >> Even if there was a way to rectify that scenario in an efficient = manner >> (the quirks right now are hard-coded in kernel space), it wouldn't >> change this scenario: >=20 > I've thought about that too, it would be really nice not to have to = recompile > to add a QUIRK. I also know scottl has some ideas on how to improve = CAM which > may well enable us to config these things much easier. >=20 >>> 2. Have an option to zpool create and zpool add, that specifies the >>> ashift value. Here my thinking is that it should let you specify an >>> ashift equal or larger than the computed one, which is based on the >>> largest sector size of all devices in a vdev. >> I'm very much a supporter of the option being added to one of the ZFS >> commands. I'm not against Steve's sysctl, but the problem with that = is >> more of a social one: features like this (if committed) never end up >> being announced to the world in a useful manner, so nobody knows they >> exist until it's too late. It would also just make me wonder "why >> bother with the sysctl at all, just use 4096 universally going = forward, >> and have whatever code/bits still support cases where existing setups >> use 512" (last part sounds easier than probably done, not sure). >=20 > The primary reason for not having it hard coded is while its good for > 99% of use cases there's still that extra 1%. Which is why I think > from a FreeBSD perspective having the option to configure the default, > but still having the standard as 4k is where my mind is. >=20 >> As for the "basing things on sector size" -- see my above explanation >> for why/how this isn't entirely reliable. Manufacturers, argh! :-) >> But something like "zpool create -a 12 ..." would be a blessing, = because >> I'd just use that all the time. If changing the default from 9 to 12 >> isn't plausible, then at least offering what I just described would = be a >> good/worthwhile stepping stone. >=20 > Indeed. >=20 > Regards > Steve >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. = and the person or entity to whom it is addressed. In the event of = misdirection, the recipient is prohibited from using, copying, printing = or otherwise disseminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission = please telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=20 > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"