Cant say I've ever had a issue with gnop, but I haven't used it for
some time.
I did have a quick look over the weekend at your issue and it looks
to me like warning for the cache is a false positive, as the vdev
for cache doesn't report an ashift in zdb so could well be falling
back to a default value.
I couldn't reproduce the issue for log here, it just seems to work
for me, can you confirm what ashift is reported for your devices
using: zdb <pool>
Regards
Steve
----- Original Message -----
From: "Borja Marcos" <bor...@sarenet.es>
To: "Steven Hartland" <kill...@multiplay.co.uk>
Cc: "Dmitryy Makarov" <suppor...@ukr.net>; <freebsd-current@freebsd.org>; "Justin T.
Gibbs" <gi...@freebsd.org>
Sent: Monday, September 16, 2013 12:06 PM
Subject: Re: ZFS secondarycache on SSD problem on r255173
On Sep 13, 2013, at 2:18 PM, Steven Hartland wrote:
This is a recent bit of code by Justin cc'ed, so he's likely the best person to
investigate this one.
Hmm. There is still a lot of confusion surrounding all this, and it's a time
bomb waiting to explode.
A friend had serious problems on 9.2 with the gnop trick in order to force a 4
KB block size. After a reboot,
ZFS would insist on trying to find the .nop device for the ZIL which, of course, did no longer exist. In his case, for some
reason,
ZFS didn't identify the labelled gpt/name or gptpd/uuid devices as valid, and the pool wouldn't attach. Curiously, it did identify
the L2ARC
without problems.
The cure was to disable GPT labels using loader.conf (I don't remember if he disabled kern.geom.label.gptid.enable,
kern.geom.label.gpt.enable or both) in
order to force it to use the "classical" daXpY nomenclature.
As I said, this sounds like a time bomb in the works. There seems to be some confusion in the ZFS between the different naming
schemes you
can use for a disk partition right now ( daXpY, gpt label or gptid).
Borja.
================================================
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 postmas...@multiplay.co.uk.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
