> On Jul 8, 2016, at 4:17 PM, Kai Storbeck wrote:
>
> Hello List,
>
> I'm new to the list, so please redirect me to the right place if I'm not at
> the right place
FYI, telegraf on Linux has an agent that collects (some of) this info and sends
to a time-series
database for easy plotting and
Fine by me. Also see https://github.com/zfsonlinux/zfs/pull/4433, which I
believe includes -Hp. I'd be happy to see that come to illumos/OpenZFS as
well.
--matt
On Fri, Jul 8, 2016 at 4:17 PM, Kai Storbeck wrote:
> Hello List,
>
> I'm new to the list, so please redirect me to the right place
Hello List,
I'm new to the list, so please redirect me to the right place if I'm not
at the right place.
I'd like to propose a patch to zpool iostat where it outputs the raw (or
literal) counters instead of the human-readable output, for machine
parsing.
Whilst searching for this, I stumbl
On Fri, Jul 8, 2016 at 11:21 AM, Albert Lee wrote:
> On Fri, Jul 8, 2016 at 9:03 AM, George Wilson
> wrote:
>
>> Andriy,
>>
>> I think this is basically a rule, although I don't think it's stated
>> anywhere. We do rely heavily on this locking strategy since there are many
>> places that will ho
So, as we found out a short time ago, this is actually fixed in ZoL as well,
but after the 0.6.5.7
From: Rich
Sent: Friday, July 8, 2016 12:37:52 PM
To: develo...@lists.open-zfs.org
Cc: developer; Developer Lists Illumos
Subject: Re: [developer] Improvements to 6
"Andriy Gapon" wrote:
> I've got curious about this while looking into what appears to be a
> FreeBSD-specific deadlock:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203864#c13
Here's another spa_namespace_lock-related deadlock:
6 102135 zfskern txg_thread_enter mi_switch+0xde
Hi Boris,
I now have working code that implements this feature, and defaults to
ignoring hole_birth data for sends if this feature is not enabled; I'm
going to post patches for it after I've tested it on both ZoL and illumos.
The latter portion of the above is easily changed, but "always correct a
Hi, Rich,
I agree that unconditional switch using the tunable is heavy if done 'as a
matter of standard practice' as opposed to 'for a short time, to fixup the
known corrupted backups'.
To clarify the earlier suggestions, people with data affected by the bug can do
two things:
1) install t
*cough* fsck tool *cough*
/Tomas
--
Written on a tiny keyboard
On 8 July 2016 2:31:18 am "Rich" wrote:
> Hi all,
>
> So, ZFS on Linux just noticed it was getting bitten by what ultimately
> turned out to be Illumos #6513, partially filled holes losing birth time.
>
> Implementing that fix
Hi Boris,
A full send of the affected snapshots should be safe, AIUI - but that means
people would need to do non-incremental snapshot sends to be certain of not
hitting this bug, which becomes increasingly infeasible as your datasets
grow.
If we're looking for the simplest solution without risk o
On Fri, Jul 8, 2016 at 9:03 AM, George Wilson
wrote:
> Andriy,
>
> I think this is basically a rule, although I don't think it's stated
> anywhere. We do rely heavily on this locking strategy since there are many
> places that will hold the namespace lock to prevent spa config changes but
> yet w
Andriy,
Thanks for the context. I see that in freebsd the zfsdev_state_lock is the
spa_namespace_lock. I agree with your analysis and am curious why these two
locks are the same. I wonder if there are other potential deadlocks that
could exist in the zvol code as a result of this.
Thanks,
George
Hi, Rich,
perhaps there is a simpler solution here.
I think for the datasets affected by this feature, a full (not incremental)
send of the source snapshot that has some holes that have not been transmitted
by the faulty incremental send code, should fix the issue, as far as the
on-disk layo
George,
thank you very much for the reply.
I've got curious about this while looking into what appears to be a
FreeBSD-specific deadlock:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203864#c13
On 08/07/2016 17:03, George Wilson wrote:
> Andriy,
>
> I think this is basically a rule, altho
Andriy,
I think this is basically a rule, although I don't think it's stated
anywhere. We do rely heavily on this locking strategy since there are many
places that will hold the namespace lock to prevent spa config changes but
yet wait for a txg to sync.
Is it honored everywhere? Well, I hope so
I see a few places in the code that do the following:
mutex_enter(&spa_namespace_lock);
dsl_sync_task(...);
mutex_exit(&spa_namespace_lock);
One example is spa_change_guid().
In my understanding this implies that the sync thread must never acquire
spa_namespace_lock. Is t
16 matches
Mail list logo
