[developer] Re: [openzfs/openzfs] 8491 uberblock on-disk padding to reserve space for smoothly merging zpool checkpoint & MMP in ZFS (#425)

gwr commented on this pull request. > @@ -54,6 +55,12 @@ struct uberblock { /* highest SPA_VERSION supported by software that wrote this txg */ uint64_tub_software_version; + + /* These fields are reserved for features that are under development: */ +

[developer] Re: [openzfs/openzfs] 8204 Makefile changes in zfstest cannot cope with empty directories (#402)

Yeah, I've run into this too, i.e. when switching branches where one branch has some new test and the other doesn't. LGTM. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[developer] Re: [openzfs/openzfs] 8204 Makefile changes in zfstest cannot cope with empty directories (#402)

gwr approved this pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/402#pullrequestreview-43745502 -- openzfs-developer

Re: [developer] propose update for sys/types.h

I don't think you can "just add those" without breaking some namespace pollution rules (i.e. XPG etc.) I'm not sure what the right #ifdef guard would be, but I'm pretty sure it would need one. On Sun, Oct 1, 2017 at 12:25 PM, Igor Kozhukhov wrote: > Hi All, > > i’d like proposed

Re: [developer] propose update for sys/types.h

Perhaps under some sort of #ifdef guard, i.e. LEGACY_BSD_TYPES or something? On Mon, Oct 2, 2017 at 9:37 AM, Toomas Soome wrote: > > ok, I think this indeed does make sense, my concern is/was that we should > not prolong deprecation needlessly. However, at this stage it seems to

[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)

Well, the rest of what's in libfakekernel is probably not as "generic" as we might like a libtaskq or libutaskq to be, so I'd probably go with a separate library. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [developer] stable API - public API

Sorry I didn't realize that change would cause API impact, or it might have had more discussion. Perhaps we should try to give people more warning about that kind of change. On Sun, Nov 12, 2017 at 8:15 AM, Igor Kozhukhov wrote: > Hello All, > > this commit killing compatibility

[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)

gwr commented on this pull request. The rest looks reasonable, but let's chat about what to keep in libfakekernel vs. consumers. > + * + * CDDL HEADER END + */ +/* + * Copyright (c) 2005, 2010, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2015 by Delphix. All

[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)

gwr commented on this pull request. > @@ -0,0 +1,68 @@ +/* I know, but I'm starting to think that was a mistake. In general, I'd rather "promote" things into libfakekernel only after we're fairly sure they're generic enough to satisfy the needs of all consumers. That's not at all obvious to

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (#451)

Andy, if you have this use libfakekernel, don't we end up with two taskq implementations in consumers of libzfs? (the second being the one in libzpool). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)

The libzpool taskq was there first, but was not sufficiently generic for "fksmbd". (That was our "fake/debug" SMB server in a user process.) We tried to make the taskq code in libfakekernel a little more generic, so it _might_ make sense to work from that, but that's a decision for whoever

[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)

Thinking about this some more, it _might_ be worthwhile considering the idea of having libzpool just use libfakekernel, but I'm not sure we made that sufficiently generic either. If not, perhaps extract what can be shared (taskq) and promote it to a library of it's own, I guess. -- You are

[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)

presumably, yes -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/141#issuecomment-338207035 -- openzfs-developer Archives:

[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)

Is there some place (i.e. a git branch) where I can pick up the new taskq library? I'd like to see how it goes replacing the one in libfakekernel with it. Maybe a separate PR for the new lib might be easier... -- You are receiving this because you are subscribed to this thread. Reply to this

[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)

That said, I hate to hold things up. If you think the (rather limited) cred implementation is generic enough, at least for today's consumers, I guess it's OK for this to go ahead. It does mean that if and when a consumer comes along that needs real credentials (i.e. NFS?) we'll need to change

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

Going further than Robert here, after looking at how this ended up, and some later work on other (unpublished) consumers of libfakekernel, I would not advocate _not_ trying to have libfakekernel share a libutaskq library. The libfakekernel one really needs to present a "kernel-like" thread

[developer] Re: [openzfs/openzfs] 8454 degradation after illumos#7431 (#418)

gwr commented on this pull request. > @@ -34,7 +34,6 @@ */ #define tolower(C) (((C) >= 'A' && (C) <= 'Z') ? (C) - 'A' + 'a' : (C)) #define toupper(C) (((C) >= 'a' && (C) <= 'z') ? (C) - 'a' + 'A': (C)) -#define iscntrl(C) C) >= 0) && ((C) <= 0x1f)) || ((C) == 0x7f)) I

[developer] Re: [openzfs/openzfs] 8454 degradation after illumos#7431 (#418)

gwr commented on this pull request. > @@ -34,7 +34,6 @@ */ #define tolower(C) (((C) >= 'A' && (C) <= 'Z') ? (C) - 'A' + 'a' : (C)) #define toupper(C) (((C) >= 'a' && (C) <= 'z') ? (C) - 'a' + 'A': (C)) -#define iscntrl(C) C) >= 0) && ((C) <= 0x1f)) || ((C) == 0x7f))

[developer] Re: [openzfs/openzfs] 8115 parallel zfs mount (v2) (#536)

gwr commented on this pull request. I didn't look in detail, but the approach looks reasonable. Is utaskq.c also used in libzpool? Or was you plan to use it both places? I don't see changes for that. -- You are receiving this because you are subscribed to this thread. Reply to this email

[developer] Re: [openzfs/openzfs] 9676 mdb's ::stacks command can loop forever (#670)

Caution: The simple direction test was insufficient in https://www.illumos.org/issues/5132/ See this thread: https://illumos.topicbox.com/groups/developer/T94b36db3a88d6615 -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [developer] Proposal: Platform-specific ZFS properties

FYI, for NexentaStor we made sharesmb a "no-inherit" property. (because most customers want "traverse mounts" in SMB, meaning the SMB server exposes descendent file systems) Note also that the most common situation (by far) for customer configurations is that a shared ZFS dataset should show up

Re: [developer] ZFS feature notifications

I'm not sure who to ask about this, but I'm curious whether the new ZFS_REPARSEPOINT might be redundant with the existing flag (in the "dos attributes field") XAT_REPARSE. See: http://src.illumos.org/source/search?project=illumos-gate=XAT_REPARSE The illumos in-kernel SMB server uses links with

[developer] dtrace set-error probe in dbuf_findbp is very noisy

I was using the dtrace set-error probe in ZFS to track something down, and I found that the probe in dbuf_findbp is VERY noisy. I also don't think this one is really returning an "error" condition (in the usual sense) but rather a status to the caller indicating the "bp" is not there. Would it