[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
make sense to get rid of this one?
It's a small change, so pasted below.
diff --git a/usr/src/uts/common/fs/zfs/dbuf.c
b/usr/src/uts/common/fs/zfs/dbuf.c
index d23cdfa673..47222cd430 100644
--- a/usr/src/uts/common/fs/zfs/dbuf.c
+++ b/usr/src/uts/common/fs/zfs/dbuf.c
@@ -2338,8 +2338,11 @@ dbuf_findbp(dnode_t *dn, int level, uint64_t blkid,
int fail_sparse,
((nlevels - level - 1) * epbs)) ||
(fail_sparse &&
blkid > (dn->dn_phys->dn_maxblkid >> (level * epbs {
- /* the buffer has no parent yet */
- return (SET_ERROR(ENOENT));
+ /*
+ * The buffer has no parent yet. This is a normal
+ * condition with sparse files, so no SET_ERROR().
+ */
+ return (ENOENT);
} else if (level < nlevels-1) {
/* this block is referenced from an indirect block */
int err = dbuf_hold_impl(dn, level+1,
--
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T83528121898a0810-M12a158c082e303023845bfd9
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
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 in SMB by a predetermined name that the customer pics, not some system made-up thing. I know it looks odd, but the typical sharesmb string for us therefore looks like: sharesmb=name=test (for a share named "TEST") and it gets even more interesting, i.e. sharesmb=name=test,abe=true,PROP=VAL, ... where each "name=something" part starts a new share (yes you can define multiple SMB share names at the same point in your ZFS dataset hierarchy). I find that many are unfamiliar with much of this. Hope this helps. On Wed, Feb 27, 2019 at 3:48 PM wrote: > > > > Am 26.02.2019 um 06:42 schrieb George Wilson: > > A couple of months ago we discussed the issues surrounding zfs properties > which have platform specific implementations. The example given was > “sharenfs” which has platform-specific syntax and platform-specific > implementations. Having platform-specific syntax for these types of > properties means that importing pools across platforms can lead to unexpected > behavior. In order to ensure cross platform safety, I would like to propose > the concept of platform-specific properties. > > > Here are some high level goals: > > > 1. Platform-specific properties are only processed on their respective > platform. If a platform-specific property does not exist for the platform > where the pool is imported then it’s treated as an unset property and the > default setting is used. > > 2. Converting a property to a platform-specific property should not break > existing scripts. > > Administrators may rely on property names, like sharenfs, so > platform-specific properties should continue to use the same naming convention > > 3. Platforms should be able to read and set platform-specific properties for > other platforms > > > Proposed Implementation: > > > To accomplish this, I propose that we introduce a property alias to our > current property scheme. The “alias” would only exist if a property is a > platform-specific property. Platform-specific properties would append the > operating system name to the property. For example, “sharenfs_Linux”, > “sharenfs_SunOS”, or “sharenfs_FreeBSD”. > > > In the case of the “sharenfs” property, the alias would remain as “sharenfs” > and the real property name would be “sharenfs_Linux”, for example. When a > user wants to “get” the value of “sharenfs” the system will automatically map > the property name to the platform-specific property. Administrators can use > the alias or the real property name when setting or getting the property: > > > # zfs set sharenfs=on tank (preferred) > # zfs set sharenfs_Linux=on tank > > > Both result in the “sharenfs_Linux” property being set to “on” on-disk. > Reading a property does the reverse mapping, allowing users to get “sharenfs” > without having to know about the underlying platform-specific name: > > > # zfs get sharenfs tank > > NAME PROPERTY VALUE SOURCE > > tank sharenfs on default > > > Having this mapping allows pools to safely import across platforms since only > properties that exist for that platform will be read and evaluated. > > > Administrators may also want the ability to set another platform’s property, > so in those cases setting the real property name should be allowed: > > > ZFS running on a Linux system: > > # zfs set sharenfs_SunOS=off tank > # zfs get sharenfs tank > > NAME PROPERTY VALUE SOURCE > > tank sharenfs on default > > > #zfs get sharenfs_SunOS tank > > NAME PROPERTY VALUE SOURCE > > tank sharenfs_SunOS on default > > > How do people feel about this approach? If we are to adopt this model, then > how should we handle converting existing properties to platform-specific > properties? Feedback and suggestions are welcome. > > The general problems I have with the share* mechanics: > - It's baked into ZFS, to change how the properties are interpreted I have to > either code in C and recompile ZFS or neuter the call to 'zfs (un)share' to > make it do what I need > - They inherit, while this is often needed to share filesystem hirarchies > over NFS it's mostly counterproductive for SMB (as that can handle > sub-filesystems) > - They're one-property containing all options (to the respective daemon), > this gives problems when doing complex shares, not all features of respective > daemons are not supported, inheritance boild down to take it as it is or > copy&paste from the parent and edit. > > > What I would like to see is to move the (un)share functionaly to external > executeables (so #! scripts work for the ones not fluent in C) that give a > clear interface for share/unshare/reload so they are easily > replaceable in case the on-size-fits
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&refs=XAT_REPARSE
The illumos in-kernel SMB server uses links with that attribute set to
represent reparse points to SMB and NFS clients.
Note there are also "dos attributes" for advisory "sparseness" XAT_SPARSE
There's also some support for IMMUTABLE and APPENDONLY in illumos
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/vnode.h#643
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/vnode.h#644
in case anything there helps.
I bring these up just in hopes of avoiding unnecessary duplication of
functionality in ways that might interfere with portability of
datasets between ZFS implementations.
On Thu, Jan 10, 2019 at 3:23 AM Jorgen Lundman wrote:
>
>
> To bring us up to date now, on the OsX and Windows platforms, I have
> (internally) made the following reservations as compared to ZOL;
>
> We have no additional command-line options.
>
> File flags (zfs_znode.h)
>
> +/* Unsure how we officially register new flags bits, but
> + * I guess we will claim the whole nibble for OSX
> + * 0x00n0ull : n = 1 2 4 8
> + */
> +#define ZFS_TRACKED 0x0010ull
> +#define ZFS_COMPRESSED 0x0020ull
> +#define ZFS_SIMMUTABLE 0x0040ull
> +#define ZFS_SAPPENDONLY 0x0080ull
>
> Although the UF_COMPRESSED might be a confusing name, it refers to HFS
> decmpfs compression, that we (have to) track, and undo (asap!). The flag
> can most likely be removed if the code is re-organised.
>
> On Windows we have:
>
> + /* Unsure how we officially register new flags bits, but
> +* I guess we will claim the whole nibble for Windows
> +* 0x0n00ull : n = 1 2 4 8
> +*/
> +#defineZFS_REPARSEPOINT0x0100ull
>
> With ioctl codes, Linux reserved +0x80 and FreeBSD +0xC0. I took +0xD0 for
> OsX and +0xE0 for Windows.
>
> ZFS_IOC_PROXY_DATASET = ('Z' << 8) + 0xD0,
>
> ZFS_IOC_MOUNT = CTL_CODE(ZFSIOCTL_TYPE, 0x8E0
> ZFS_IOC_UNMOUNT = CTL_CODE(ZFSIOCTL_TYPE, 0x8E1
> ZFS_IOC_UNREGISTER_FS = CTL_CODE(ZFSIOCTL_TYPE, 0x8E2
>
> I believe SA, zfs prop and zpool props do not affect on disk format, but we
> define;
>
> ZPL_DXATTR,
> +ZPL_ADDTIME,
> +ZPL_DOCUMENTID,
> ZPL_END
>
> These all have manpage changes.
>
> zprop_register_string(ZFS_PROP_SHAREAFP, "shareafp"
> zprop_register_index(ZFS_PROP_APPLE_BROWSE, "com.apple.browse"
> zprop_register_index(ZFS_PROP_APPLE_IGNOREOWNER, "com.apple.ignoreowner"
> zprop_register_hidden(ZFS_PROP_APPLE_LASTUNMOUNT,"COM.APPLE.LASTUNMOUNT"
> zprop_register_index(ZFS_PROP_APPLE_MIMIC_HFS, "com.apple.mimic_hfs"
> zprop_register_index(ZFS_PROP_APPLE_DEVDISK, "com.apple.devdisk"
>
> zprop_register_string(ZFS_PROP_DRIVELETTER, "driveletter"
>
> Since there is no (easy) way to do automounted snapshot mounting, we have
> extended the "zfs mount" (and unmount) commands to also accept snapshots.
> Ie, "zfs mount pool/dataset@snapshot". The mountpoint location is the same.
>
> I may have missed a bunch :)
>
> Lund
>
> --
> Jorgen Lundman |
> Unix Administrator | +81 (0)90-5578-8500
> Shibuya-ku, Tokyo| Japan
>
--
openzfs: openzfs-developer
Permalink:
https://openzfs.topicbox.com/groups/developer/T538929199ec54878-M6f1aa6a646af29b40b27c8e1
Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
[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: https://github.com/openzfs/openzfs/pull/670#issuecomment-47886 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/T0a20d78ceac3a60d-M5259a1bad6ec303a2f7e68b2 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
[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 don't have strong feelings either way. I just wanted to confirm that the discussion was concluded to the satisfaction of your reviewers. -- 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/418#discussion_r178444759 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/Tf974af07ec408e5e-M70cdbb0013876b197e6c1433 Delivery options: https://openzfs.topicbox.com/groups
[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)) @yuripv Are you satisfied with this review? Igor, I generally lean toward "the less change the better", so I'd probably go as Yuri suggests and just remove the test for zero. -- 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/418#discussion_r178436906 -- openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/discussions/Tf974af07ec408e5e-M64f42bf585919655dfe4ddf9 Delivery options: https://openzfs.topicbox.com/groups
[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 directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/536#pullrequestreview-99147191 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-Me22844fcd4cb8d7431901ed2 Powered by Topicbox: https://topicbox.com
[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 model, with a real (kernel-like) thread_t object avail to each libfakekernel thread. I don't see any easy way to do that without having the libfakekernel implementation use the kernel thread interfaces to create threads. Given all that, I now think we're just "trying too hard" to share some code (and it's just not all that much code anyway). -- 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/536#issuecomment-366361905 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T22334a01fda83bfd-M23be74171fbe1410500fba97 Powered by Topicbox: https://topicbox.com
[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 this lib and all current consumers. If you're OK with that, then go ahead. -- 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/494#issuecomment-361641583 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T34088d4e3e9cd4f5-Me14de37e2a0f2da658016dbe Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8809 libzpool should leverage work done in libfakekernel (#494)
As we're sort of "promoting" libfakekernel to more wide-spread use, I'd really rather not have it include things that are rather SMB-specific. I see the current cred hacking there as rather SMB-specific. Sorry I haven't had time to offer changes to take that out, though I don't think it should be too hard. -- 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/494#issuecomment-361419114 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T34088d4e3e9cd4f5-Maaa999e8169295f4c3d0a9df Powered by Topicbox: https://topicbox.com
[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 me in the case of cred the stuff... -- 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/494#discussion_r155100585 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T34088d4e3e9cd4f5-M7e08df384d706e7c7a28da9f Powered by Topicbox: https://topicbox.com
[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 rights reserved.
+ * Copyright (c) 2013, Joyent, Inc. All rights reserved.
+ * Copyright 2017 RackTop Systems.
+ */
+
+#include
+#include
+#include
+
+#include
+
Is this file sufficiently "generic" that it deserves to be part of
libfakekernel? or should it remain as part of libzpool?
> @@ -52,6 +53,34 @@ crgetuid(const cred_t *cr)
return (0);
}
+/*ARGSUSED*/
I'm not sure we should keep the cred stuff in libfakekernel.
Maybe better to leave that to the consumers?
(libfksmbsrv, and libzpool after this work)
> @@ -65,6 +67,29 @@ kmem_zalloc(size_t size, int kmflags)
return (umem_zalloc(size, kmem2umem_flags(kmflags)));
}
+/*
How about adding a strext.c file for this?
(like in uts/common/os)
It might not have been obvious, but we tried to keep the functions organized in
files of similar names as the "real" versions.
> @@ -69,6 +117,32 @@ delay(clock_t ticks)
(void) poll(0, 0, msec);
}
+int
+issig(int why)
+{
+ return (0);
+}
+
+/* ARGSUSED */
Here too, how about a cyclic.c?
Would rather not see kmisc.c turn into more of a "catch" all...
> @@ -0,0 +1,68 @@
+/*
Doesn't this clash with what libfksmbsrv is doing with creds, sids, and ksids?
I think we may need to keep this too in the consumers, rather than in
libfakekernel (leaving this ignorant of creds or ksids).
> @@ -0,0 +1,80 @@
+/*
Did you run into problems using the normal sys/cmn_err.h?
What happened?
--
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/494#pullrequestreview-80691511
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/T34088d4e3e9cd4f5-M745bcb2edae84659b21ba1ff
Powered by Topicbox: https://topicbox.com
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 with older libdladm: > > 8765 dladm tries setting persistent prop on temporary link > https://bitbucket.org/dilos/dilos-illumos/commits/638cab1445079b522f4c99f02eb7eba4d5819aae > > it’s mean - if you have zones with exclusive ip-type and just wants to > update zone without global zone update - you will lost network in your zone. > > where we can use this case? > > for example, on DilOS, i can run and use zones with OI (iplg), smartos (grab > native zone + pkgsrc). > I can use zones for development and update it without global zone updates > with DilOS if we have no updates in primary/major components. > > yes, i know about sync of global zone and non-global zones with primary > components, but time to time i need update just zones and postpone update > global zone and to do upgrade globa zone if we have updates in primary > components. > > I’d like to propose to use wrappers to public functions whre we have public > propotypes and in theory some others components have dependencies. > right now we can see how it can impact configured/instaled components. > > if we have no it yet - i’d like propose to do it from now. > > best regards, > -Igor > > openzfs-developer | Archives | Powered by Topicbox -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tc85856698599769e-Mce0fdad31277596f053b64cd Powered by Topicbox: https://topicbox.com
[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: https://github.com/openzfs/openzfs/pull/451#issuecomment-339431010 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T156a07b986390bdb-M1a827f89347c27c882638061 Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)
BTW, the concerns about "taskq" vs "utaskq" (etc.) might have been unfounded. Our dtrace scripts for fksmbd work OK with the current libfakekernel taskq (which doesn't have a 'u' prefix) so long as data types are referenced like: this->tq = (userland pid`taskq_t *) It's probably not necessary to rename things (if that makes the job easier). -- 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-338346120 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-Mac459255d2d6e7c3e2982969 Powered by Topicbox: https://topicbox.com
[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 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-338326217 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-M02759efa88be29165e25ea83 Powered by Topicbox: https://topicbox.com
[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 works on this. As for interfaces, it would be helpful if this could be usable in both consumers (libzpool and libfksmbsrv) with relatively modest changes, i.e. perhaps a special header file with #define(s) sufficient to let us build the SMB server code without (much) change. I know that's a lot to ask, which is part of why this hasn't happened already. -- 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-338325324 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-Mcae9dfefb66968c70f94da38 Powered by Topicbox: https://topicbox.com
[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 email directly or view it on GitHub: https://github.com/openzfs/openzfs/pull/141#issuecomment-338261325 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-Ma9fe67b6b76d543451c1 Powered by Topicbox: https://topicbox.com
[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: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-M65073e161a65f3f681081377 Powered by Topicbox: https://topicbox.com
[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: https://github.com/openzfs/openzfs/pull/141#issuecomment-338196031 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-M804da9f8d6075d4d197578aa Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 7149 move libzpool's taskq library into libcmdutils (#141)
Maybe a new library would be better? -- 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-338028106 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T012acd019d09e76d-M2eccee09dab6a2bef5627c2e Powered by Topicbox: https://topicbox.com
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 try to update sys/typs.h by changes what are available in
> FreeBSD for better portality:
>
> igor@z172:~/users/igor/dilos-illumos$ g diff
> diff --git a/usr/src/uts/common/sys/types.h b/usr/src/uts/common/sys/types.h
> index dcb2c86283..a2e37263b8 100644
> --- a/usr/src/uts/common/sys/types.h
> +++ b/usr/src/uts/common/sys/types.h
> @@ -58,6 +58,11 @@
> #include
> #endif
>
>
>
> +typedef uint8_tu_int8_t; /* unsigned integrals
> (deprecated) */
> +typedef uint16_t u_int16_t;
> +typedef uint32_t u_int32_t;
> +typedef uint64_t u_int64_t;
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
>
>
>
> i have found several userland apps what are needs where changes and I
> understand - they are deprocated, but it can helps and reduce additional
> patches in userland apps with portability and builds based on illumos env.
>
> If you are agreed - i can file a bug for it.
>
> best regards,
> -Igor
>
> openzfs-developer | Archives | Powered by Topicbox
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/T0cc9a914d001ea54-M2e955b705f75b539397a32a2
Powered by Topicbox: https://topicbox.com
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 make
> sense to have the typedefs.
>
> +1.
>
> rgds,
> toomas
>
> On 2 Oct 2017, at 15:09, Jonathan Perkin wrote:
>
> * On 2017-10-02 at 12:55 BST, Toomas Soome wrote:
>
> On 1 Oct 2017, at 19:25, Igor Kozhukhov wrote:
>
> Hi All,
>
> i’d like proposed try to update sys/typs.h by changes what are available in
> FreeBSD for better portality:
>
> igor@z172:~/users/igor/dilos-illumos$ g diff
> diff --git a/usr/src/uts/common/sys/types.h b/usr/src/uts/common/sys/types.h
> index dcb2c86283..a2e37263b8 100644
> --- a/usr/src/uts/common/sys/types.h
> +++ b/usr/src/uts/common/sys/types.h
> @@ -58,6 +58,11 @@
> #include
> #endif
>
> +typedef uint8_tu_int8_t; /* unsigned integrals
> (deprecated) */
> +typedef uint16_t u_int16_t;
> +typedef uint32_t u_int32_t;
> +typedef uint64_t u_int64_t;
> +
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> i have found several userland apps what are needs where changes and I
> understand - they are deprocated, but it can helps and reduce additional
> patches in userland apps with portability and builds based on illumos env.
>
> If you are agreed - i can file a bug for it.
>
> I have different kind of question — the u_* types inFreeBSD at least are
> deprecated and handled quite the same way as we do - when you step on it,
> fix it:) so the actual question is, how many cases (approximately) there are
> and perhaps it is just wiser to use the strategy to fix things at the point
> of origin. Note, I have done such fixing myself and helped to get it done
> for illumos. Depending on the volume of the work, it still may be reasonable
> to have those types defined, but in my opinion, the focus should be on real
> fixes in any case - even if we do have this (temporary and deprecated) list
> of typedefs.
>
> In pkgsrc we have 67 packages where we have already fixed this by
> defining -Du_int*=uint* in CPPFLAGS. It is unknown how many of these
> 67 still require the workaround, it's possible that many of them have
> already been fixed upstream.
>
> According to the most recent bulk build report there are 32 further
> potential packages where adding them might help fix the build.
>
> This is out of 19,303 total packages.
>
> Regardless of whether illumos decides to add these typedefs, we will
> still have to add them to pkgsrc to support older systems, so it would
> be appreciated if this was done in a way that avoids redefinitions.
>
> Regards,
>
> --
> Jonathan Perkin - Joyent, Inc. - www.joyent.com
>
> openzfs-developer | Archives | Powered by Topicbox
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/T0cc9a914d001ea54-Ma4c680fad3d57563e05c21fa
Powered by Topicbox: https://topicbox.com
[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: */
+ uint64_tub_mmp_magic;
+ uint64_tub_mmp_delay;
[ Copying a question here I posted in the RTI forum. ]
I'm not normally at this depth in ZFS, so let me ask:
How do we know this works with older on-disk data?
--
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/425#pullrequestreview-51367746
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/Td128c23c12b31635-M545430309c6863780ac009f0
Powered by Topicbox: https://topicbox.com
[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 Archives: https://openzfs.topicbox.com/groups/developer/discussions/T71eb784c31872ce3-M92e32005be707350db2c5b30 Powered by Topicbox: https://topicbox.com
[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: https://github.com/openzfs/openzfs/pull/402#issuecomment-308137963 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/T71eb784c31872ce3-Md4362ebfe94218a0e5bd303d Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8311 ZFS_READONLY is a little too strict (#392)
What's next for this? more reviewers? RTI? Thx! -- 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/392#issuecomment-307500204 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tb6ca17b06450145d-M1672e8fdcedcee9018f4f3b4 Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8311 ZFS_READONLY is a little too strict (#392)
gwr commented on this pull request.
> +{
+ nvlist_t*nvl = NULL;
+ int err;
+
+ err = nvlist_alloc(&nvl, NV_UNIQUE_NAME, 0);
+ if (err != 0)
+ return (err);
+
+ (void) nvlist_add_boolean_value(nvl, A_READONLY, 1);
+
+ if (fname == NULL) {
+ err = fsetattr(fildes, XATTR_VIEW_READWRITE, nvl);
+ } else {
+ err = setattrat(fildes, XATTR_VIEW_READWRITE, fname, nvl);
+ }
+ if (err < 0) {
Let's just leave it. It might be useful to add a test case using that code
path in the future.
(and I'm not too bothered by one line of dead code in a test program:)
Thanks!
--
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/392#discussion_r121134545
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/Tb6ca17b06450145d-M03be46f9a223f84647cdc503
Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8311 ZFS_READONLY is a little too strict (#392)
gwr commented on this pull request.
> +{
+ nvlist_t*nvl = NULL;
+ int err;
+
+ err = nvlist_alloc(&nvl, NV_UNIQUE_NAME, 0);
+ if (err != 0)
+ return (err);
+
+ (void) nvlist_add_boolean_value(nvl, A_READONLY, 1);
+
+ if (fname == NULL) {
+ err = fsetattr(fildes, XATTR_VIEW_READWRITE, nvl);
+ } else {
+ err = setattrat(fildes, XATTR_VIEW_READWRITE, fname, nvl);
+ }
+ if (err < 0) {
Oh, well the code was "borrowed" from something else where fname could be
passed in.
I could go either way (minimize this code, vs leave it more general).
Your thoughts on which way is better?
--
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/392#discussion_r120876944
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/groups/developer/discussions/Tb6ca17b06450145d-Mbb6ceb920ffe318bfd3f6bd2
Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8311 ZFS_READONLY is a little too strict (#392)
Looks like a piece of this change got dropped: ``` diff --git a/usr/src/test/zfs-tests/include/default.cfg b/usr/src/test/zfs-tests/include/default.cfg index 635f3f0b15..56b41b6250 100644 --- a/usr/src/test/zfs-tests/include/default.cfg +++ b/usr/src/test/zfs-tests/include/default.cfg @@ -45,6 +45,7 @@ export ZONE_CTR="zonectr" export CHG_USR_EXEC="/opt/zfs-tests/bin/chg_usr_exec" export DEVNAME2DEVID="/opt/zfs-tests/bin/devname2devid" export DIR_RD_UPDATE="/opt/zfs-tests/bin/dir_rd_update" +export DOS_RO_CMD="/opt/zfs-tests/bin/dos_ro" export FILE_CHECK="/opt/zfs-tests/bin/file_check" export FILE_TRUNC="/opt/zfs-tests/bin/file_trunc" export FILE_WRITE="/opt/zfs-tests/bin/file_write" ``` -- 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/392#issuecomment-306070553 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tb6ca17b06450145d-Me6961b280c3698a85697aecf Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] 8311 ZFS_READONLY is a little too strict (#392)
Thanks for putting this together, @yuripv -- 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/392#issuecomment-305985005 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/discussions/Tb6ca17b06450145d-M59e696a1c438e4d9ed054a86 Powered by Topicbox: https://topicbox.com
[developer] Re: [openzfs/openzfs] Remove "zfs_acl_chmod_xattr_001_pos" from known zfstest failures (#380)
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/380#pullrequestreview-38680273 -- openzfs-developer Archives: https://openzfs.topicbox.com/groups/developer/ Powered by Topicbox: https://topicbox.com
[developer] Fwd: Welcome to GSoC 2017!
Hi everyone, I'm pleased to announce that the illumos project has been accepted as a mentoring organization for this year's Google Summer of Code <https://summerofcode.withgoogle.com/> program. Our next steps are to recruit some "mentors" and start talking to prospective students who might like to make an application to participate in this excellent program. If you know anyone who might be interested, please pass the word, and suggest they look over our "ideas" pages: https://wiki.illumos.org/display/illumos/Project+Ideas The Welcome message from GSoC below has some more details, timelines etc. Thanks, Gordon -- Forwarded message -- From: Google Summer of Code Date: Wed, Mar 1, 2017 at 6:19 PM Subject: Welcome to GSoC 2017! [image: Google Summer of Code] Hi Gordon Ross, This year marks our biggest program ever! We have 201 open source organizations participating in GSoC 2017 and we expect to accept more students than ever before as well. And welcome to 37 organizations participating in their first GSoC! Right now you should be chatting with proactive, excited students. Remember to keep your Ideas List updated and make it clear and simple to understand so students can easily find your Ideas - if it requires multiple clicks to get to the Ideas List that is not ideal. We want to give you a quick overview of the next few months and address some of the common questions you may have these first few weeks of the program. *New changes (and some reminders) for 2017* - There are 3 evaluation periods this year where mentors are required to complete an evaluation of their student. After the first 4 weeks of coding, after 8 weeks of coding and then at the end (after 12 weeks of coding). The evaluation forms are shorter than previous years so they should take less time to complete. - Students can only be accepted into GSoC 2 times. Google Admins will do a sanity check on all accepted students once you select your students in late April so you do not need to be concerned about this. - If you are a university, we expect you to select students outside of your program. Selecting students from your university is okay but if *all* of the students you select are from your university then you likely won’t be accepted into GSoC again. - New org payment system using Payoneer. We are no longer requiring OAs to register for a Google supplier account and instead orgs will do what students do and create an account with Payoneer. This will allow for orgs to receive payments *much* faster, with orgs receiving their stipend payments in September. (more details to come in May) - We are now allowing 13-17 year olds to be mentors for GSoC as long as they have parental consent to be a part of the program. An additional form is required. *Inviting Mentors to your Organization* Organization Administrators should be reaching out to mentors and sending them invitations to be a part of their organization. The mentor will then click the link in the email they receive to create their account. PLEASE NOTE: Right now first time mentors should wait a few days to register until we have announced that we have fixed a small validation error on the site not allowing mentors to choose “0” as an option to the question ‘How many times have you participated as a GSoC mentor previously?’ They can’t edit that field once they put a number into it and we are trying to get a good idea of how many new mentors we have each year. Thank you for your patience. *GSoC Mentor-invite Mailing List* For those that have opted into the GSoC mentor mailing list (available on your profile page) we will bulk add you to the list on March 6th. Then we will add additional folks who opt in about once a week throughout the program period. You can remove yourself through the groups interface at any time. You can also update your settings to receive a daily digest of emails and other options. This generally is not a very high traffic list but there will be more questions over the next two months on this list than probably later in the program. The GSoC mentor mailing list is a great way to ask questions of other org admins and mentors and to get their feedback and help. *Important Upcoming Dates* *Now - March* *20:* Proactive students will reach out to you and ask questions about your ideas list and receive feedback from your org so they can start crafting their project proposals. *March 20 - April 3 16:00 UTC*: Students will submit their draft proposals through the program website for you to give solid feedback on. *April 3 - 16:* Review all submitted student proposals with your org and consider how many you want to select and how many you can handle. Decide on the minimum/maximum number of student slots to request. *April 17, 16:00 UTC*: Deadline to submit slot requests (OAs enter requests) *April 19, 16:00 UTC*: Slot allocations are announced by Googl
