Slow resilvering with mirrored ZIL

[mxb]

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 at multiplay.co.uk> wrote:

> ----- Original Message ----- From: "Jeremy Chadwick" <jdc at koitsu.org>
> 
>> 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).
> 
> 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:
> 
> 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.
> 
>>> 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).
> 
> 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.
> 
>> 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.
> 
> Indeed.
> 
>   Regards
>   Steve
> 
> ================================================
> 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. 
> In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
> or return the E.mail to postmaster at multiplay.co.uk.
> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"