Re: [developer] Adding a -p option to "zpool iostat"

> 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

[developer] Adding a -p option to "zpool iostat"

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

Re: [developer] Improvements to 6513 handling

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:

Re: [developer] spa_namespace_lock vs sync thread

"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

Re: [developer] Improvements to 6513 handling

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

Re: [developer] Improvements to 6513 handling

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

Re: [developer] Improvements to 6513 handling

*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. > >

Re: [developer] Improvements to 6513 handling

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

Re: [developer] spa_namespace_lock vs sync thread

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

Re: [developer] Improvements to 6513 handling

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

Re: [developer] spa_namespace_lock vs sync thread

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,

Re: [developer] spa_namespace_lock vs sync thread

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

[developer] spa_namespace_lock vs sync thread

I see a few places in the code that do the following: mutex_enter(_namespace_lock); dsl_sync_task(...); mutex_exit(_namespace_lock); One example is spa_change_guid(). In my understanding this implies that the sync thread must never acquire spa_namespace_lock. Is this a