Date: Fri, 5 Jul 2013 21:38:13 +0200 From: mxb <mxb@alumni.chalmers.se> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: Slow resilvering with mirrored ZIL Message-ID: <9052B6E6-F742-4C10-87B5-2EFE03FDB31E@alumni.chalmers.se> In-Reply-To: <D1AA0DF1F1954FFF9A99759A93B1BAEA@multiplay.co.uk> References: <CBCA1716-A3EC-4E3B-AE0A-3C8028F6AACF@alumni.chalmers.se> <20130704000405.GA75529@icarus.home.lan> <C8C696C0-2963-4868-8BB8-6987B47C3460@alumni.chalmers.se> <20130704171637.GA94539@icarus.home.lan> <2A261BEA-4452-4F6A-8EFB-90A54D79CBB9@alumni.chalmers.se> <20130704191203.GA95642@icarus.home.lan> <43015E9015084CA6BAC6978F39D22E8B@multiplay.co.uk> <CAOjFWZ4obK1cSmvTpW%2Bt4xKdMf%2BkJV5w-sujDT1AZoepj%2B5YrA@mail.gmail.com> <3CFB4564D8EB4A6A9BCE2AFCC5B6E400@multiplay.co.uk> <51D6A206.2020303@digsys.bg> <20130705145332.GA5449@icarus.home.lan> <D1AA0DF1F1954FFF9A99759A93B1BAEA@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <killing@multiplay.co.uk> = wrote: > ----- Original Message ----- From: "Jeremy Chadwick" <jdc@koitsu.org> >=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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9052B6E6-F742-4C10-87B5-2EFE03FDB31E>