andy-js 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/630#pullrequestreview-162836829
--
openzfs: openzfs-devel
andy-js 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/690#pullrequestreview-162812532
--
openzfs: openzfs-devel
andy-js approved this pull request.
LGTM. Thanks for taking the time to clean-up libzfs.
--
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/660#pullrequestreview-135829277
Might as well update libzfs to use this while you're at it.
--
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/660#issuecomment-402866513
--
openzfs
andy-js commented on this pull request.
> @@ -1,4 +1,4 @@
-#!/usr/bin/ksh -p
+#!/bin/ksh -p
We already fix the shebangs for python scripts:
https://github.com/illumos/illumos-gate/blob/master/usr/src/Makefile.master#L267
Doing the same for the tests should be easy.
--
You are receiving this
andy-js commented on this pull request.
> @@ -1,4 +1,4 @@
-#!/usr/bin/ksh -p
+#!/bin/ksh -p
A change such as this should be discussed on the illumos-dev list before
considering integration.
@ikozhukhov Have you considered changing the tests so that the shebang is
determined at build time?
-
andy-js commented on this pull request.
> @@ -1808,13 +1808,17 @@ zfs_prop_set_list(zfs_handle_t *zhp, nvlist_t *props)
ret = zfs_ioctl(hdl, ZFS_IOC_SET_PROP, &zc);
if (ret != 0) {
+ (void) zfs_standard_error(hdl, errno, errbuf);
Oh. You're right. I didn't real
Is the zdb problem documented anywhere? The is the first I’ve heard of it.
- Andy.
> On 24 Jun 2018, at 18:05, Igor Kozhukhov wrote:
>
> Hi All,
>
> Thanks to everyone who helped with analyzes of issues with zdb and crashes
> under dilos env with zfs tests.
>
> zdb was broken on dilos env -
andy-js 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/655#pullrequestreview-131113115
--
openzfs: openzfs-devel
andy-js 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/656#pullrequestreview-131002382
--
openzfs: openzfs-devel
Before patch:
```
# zfs set mountpoint=/test testpool
internal error: out of memory
```
After patch:
```
# zfs set mountpoint=/test testpool
cannot set property for 'testpool': pool is read-only
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email direct
This adds a check for zc_nvlist_dst_filled prior to calling
zcmd_read_dst_nvlist() which will cause the zfs command to exit with "internal
error: out of memory" if the error list is not filled, which is the case when
attempting to modify a property on a readonly pool.
It also fixes a slight mis
andy-js approved this pull request.
I've seen the deadlock.
--
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/645#pullrequestreview-129120299
--
andy-js commented on this pull request.
> @@ -4924,12 +4924,18 @@ zdb_embedded_block(char *thing)
exit(1);
}
ASSERT3U(BPE_GET_LSIZE(&bp), <=, SPA_MAXBLOCKSIZE);
+ buf = malloc(SPA_MAXBLOCKSIZE);
+ if (buf == NULL) {
+ (void) printf("out o
andy-js commented on this pull request.
> @@ -1091,7 +1091,9 @@ dmu_object_remap_indirects(objset_t *os, uint64_t
> object,
return (err);
}
- if (dn->dn_nlevels <= 1) {
+ rw_enter(&dn->dn_struct_rwlock, RW_WRITER);
+ if (dn->dn_phys->dn_nlevels <= 1)
I have been doing my own testing with parallel mounts and have observed that
enabling SMB shares is a significant bottleneck. From looking at the code it's
not clear to me that this will help.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or
andy-js commented on this pull request.
> @@ -73,6 +74,13 @@ struct libzfs_handle {
int libzfs_storeerr; /* stuff error messages into buffer */
void *libzfs_sharehdl; /* libshare handle */
boolean_t libzfs_mnttab_enable;
+ /*
+* We need a lock to handle the
andy-js approved this pull request.
Good job.
--
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/592#pullrequestreview-104984091
--
openzfs: open
I can live with this.
Rather than having 3 userspace taskq implementations (the one in libzpool,
libfakekernel and libutaskq) we now have 2 (one in libfakekernel and one in
libzfs). That's an improvement.
--
You are receiving this because you are subscribed to this thread.
Reply to this email
andy-js commented on this pull request.
> @@ -1716,15 +1731,18 @@ zfs_acl_ids_create(znode_t *dzp, int flag, vattr_t
> *vap, cred_t *cr,
mutex_exit(&dzp->z_lock);
mutex_exit(&dzp->z_acl_lock);
- if (vap->va_type == VDIR)
- ac
@prakashsurya You may count me as a reviewer if you wish to proceed down the
current path, though I am having some seconds thoughts based on Robert's
comments. We could break this up in a subsequent change I guess. I'd be okay
with that.
--
You are receiving this because you are subscribed t
andy-js commented on this pull request.
> @@ -88,6 +89,9 @@
#include
#defineMAXISALEN 257 /* based on sysinfo(2) man page */
+static int mount_tq_nthr = 512;/* taskq threads for multi-threaded
mounting */
I suppose this could be made a tuneable through /etc/defau
andy-js commented on this pull request.
> -#ifdef __cplusplus
-extern "C" {
-#endif
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-#ifdef __cplusplus
-}
-#endif
-
-#endif /* _SYS_ZFS_CONTEXT_H */
I'm glad to see this file go. Too bad we can't also drop the one in
Am I right in thinking these are the changes that were presented an OpenZFS
Europe a couple of years back?
--
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/548#issuecomment-366071890
--
andy-js commented on this pull request.
Overall looks good.
> +#
+# We want to test the case where a whole created by a log device is filled
+# by a regular device
+#
+function test_remove_log_then_add_vdev
+{
+ log_note "$0."
+ log_must zpool create -o cachefile=$CPATH $TESTPOOL1 \
+
andy-js approved this pull request.
Thanks for confirming.
--
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/540#pullrequestreview-95253573
--
o
Does this still work if coreadm is configured to put dumps in a different
location?
--
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/540#issuecomment-364252166
-
andy-js 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/538#pullrequestreview-94871236
--
openzfs-developer
Archi
I think @rmustacc is exactly right. We should not be building the zfs command
(or libzfs) in fakekernel context. This is a highly specialised environment
that really only makes sense for things like libzpool which include kernel code.
I suggest you have a look at this earlier webrev of mine wh
andy-js 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/511#pullrequestreview-93268615
--
openzfs-developer
Archi
fprop is a different type. It does not need to be changed.
--
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/528#issuecomment-359194535
--
openzfs
8652 missed a couple of instances of ZPROP_INVAL which should be changed to
ZPOOL_PROP_INVAL. This causes newer versions of GCC (I'm using 5.3.0) to throw
a warning.
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/528
-- Commit Summary
Sure. I'll take a stab at it tomorrow.
--
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/466#issuecomment-358808844
--
openzfs-developer
Archives:
Here's the fix:
diff --git a/usr/src/cmd/zpool/zpool_main.c b/usr/src/cmd/zpool/zpool_main.c
index 3f8bee81c0..a6e878a341 100644
--- a/usr/src/cmd/zpool/zpool_main.c
+++ b/usr/src/cmd/zpool/zpool_main.c
@@ -413,7 +413,7 @@ static int
add_prop_list(const char *propname, char *propval, nvlist_t **
Your forgot to update line 414 and line 432 in zpool_main.c. This causes
warnings with GCC 5.3.
--
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/466#issuecomment-358801503
andy-js approved this pull request.
This looks good to me, and in the spirit of libzfs_core.
--
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/508#pullrequestreview-89831235
--
andy-js approved this pull request.
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/520#pullrequestreview-89814560
--
openzfs-developer
andy-js approved this pull request.
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/526#pullrequestreview-89534107
--
openzfs-developer
Gordon had some concerns about the cred stuff but I'm not so sure. What I
would like to do - if he's happy - is go ahead and revisit that in a separate
change.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github
andy-js 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/502#pullrequestreview-81496701
--
openzfs-developer
Archi
andy-js commented on this pull request.
> @@ -2425,6 +2425,7 @@ zpool_vdev_online(zpool_handle_t *zhp, const char
> *path, int flags,
{
zfs_cmd_t zc = { 0 };
char msg[1024];
+ char *pathname = NULL;
Is it necessary to initialise pathname in this case?
--
You are receiv
andy-js commented on this pull request.
> @@ -52,6 +53,34 @@ crgetuid(const cred_t *cr)
return (0);
}
+/*ARGSUSED*/
If we could add the missing functionality and make all consumers happy I'd
rather do that.
--
You are receiving this because you are subscribed to this thread.
Reply
andy-js commented on this pull request.
> @@ -0,0 +1,68 @@
+/*
I don't think so. I don't see these functions defined there, anyway. And
besides, there's already some cred stuff in libfakekernel.
--
You are receiving this because you are subscribed to this thread.
Reply to this email direct
andy-js commented on this pull request.
> @@ -65,6 +67,29 @@ kmem_zalloc(size_t size, int kmflags)
return (umem_zalloc(size, kmem2umem_flags(kmflags)));
}
+/*
Will do.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Gi
andy-js commented on this pull request.
> + *
+ * 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
andy-js commented on this pull request.
> @@ -69,6 +117,32 @@ delay(clock_t ticks)
(void) poll(0, 0, msec);
}
+int
+issig(int why)
+{
+ return (0);
+}
+
+/* ARGSUSED */
Sure. This sounds good to me.
--
You are receiving this because you are subscribed to this thread.
Reply t
andy-js commented on this pull request.
> @@ -0,0 +1,80 @@
+/*
Some of the print functions have different prototypes (kernel versions are
void, user space versions return number of characters printed) and this causes
the compiler to generate an error.
--
You are receiving this because you a
The lint and test errors have now been fixed. If I could get another review or
two that'd be great.
--
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-348701614
Thanks for your help. I think I have pushed a fix, but CI has failed again
complaining about not being able to find the workspace.
--
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#
Looks like zloop was killed for some reason. In the log I see "Timeout has
been exceeded
Finished: ABORTED"
--
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-348039255
Looks like the build failure was unrelated to my changes. I see:
"could not determine the workspace used to perform the build"
--
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#issue
@zettabot go
--
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-347562830
--
openzfs-developer
Archives:
https://openzfs.topicbox.
Thanks. I think I see what's going on.
--
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-347561219
--
openzfs-developer
Archives:
Looks like some of the import tests failed. I'm not sure why because they PASS
on my VM.
Is there any way I can get a look at those result files?
--
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/o
Where can I see what caused the build failure?
--
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-345459605
--
openzfs-developer
Ar
Yeah I think I agree. I will split the parallel stuff out into a separate
change. To make lint happy we might need to breakout 'ifdef lint'.
--
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/openzf
andy-js commented on this pull request.
> @@ -94,6 +95,7 @@ int zfs_vdev_async_read_max_active;
static const char cmdname[] = "zdb";
uint8_t dump_opt[256];
+extern int aok;
I am going to say that that's bogus. Either that or we aren't linking in libc
(which provides aok) which building th
andy-js commented on this pull request.
> @@ -94,6 +95,7 @@ int zfs_vdev_async_read_max_active;
static const char cmdname[] = "zdb";
uint8_t dump_opt[256];
+extern int aok;
Just out of curiosity... what was the lint error?
--
You are receiving this because you are subscribed to this threa
Not sure why this failed to build. It's building fine on my OmniOS VM.
--
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-342238703
--
This changeset follows on from #451 which implement parallel mounting of zfs
filesystems. Additionally it attempts to cleanup libzpool by having it
leverage the work done in libfakekernel.
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull
I introduced _TASKQUSER so that we don't need to build libzfs in fakekernel
context, which reduces the size of the diff a bit.
--
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#issue
Updated webrev: http://cr.illumos.org/~webrev/andy_js/8115-1/
--
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-342125067
--
openz
I spent the weekend reworking libzpool to use libfakekernel. Here's a summary
of the changes:
- libzpool is now built in fake-kernel context and uses the taskq API in
libfakekernel. Most of the defines in zfs_context.h have been dropped in
favour of included system header files.
- libfakeker
Sounds good to me. I'll look at updating libzpool to use libfakekernel.
--
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-341067822
-
andy-js 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/487#pullrequestreview-73350731
--
openzfs-developer
Archi
Well that depends on whether or not they're pulling in both libzfs and
libzpool. From what I can see most things (like the zfs and zpool commands)
only pull in libzfs, so they should be okay.
I have no problem with changing libzpool to use libfakekernel. I chose not to
go down that route simp
I took at stab at updating the changeset to use libfakekernel instead:
http://cr.illumos.org/~webrev/andy_js/8115/
Apart from some weirdness with sys/cmn_err.h conflicting with stdio.h it was
straightforward.
--
You are receiving this because you are subscribed to this thread.
Reply to this ema
@prakashsurya Do you think it would make sense to split the changes to the VFS
code out into a separate issue?
--
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-33898653
I think it makes sense to decouple this from #451 and change the name to
something like "libzfs should use taskq in libfakekernel".
--
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#
Having libzpool use libfakekernel seems like the right answer to me.
--
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-338625995
-
That sounds like a good idea. libcmdutils is becoming a bucket for everything.
--
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-338036480
--
I think it's time to reopen this. The problem was addressed in #359 by giving
the user space implementation a different name (utaskq). Apart from a minor
omission the changes look good.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view i
You forgot to add a mapping for taskqid_t to sys/zfs_context.h.
--
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-68160
--
ope
Looks like the build failed because of a network issue.
--
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-333242633
--
openzfs-dev
andy-js approved this pull request.
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/459#pullrequestreview-60271942
--
openzfs-developer
Perhaps zpool_read_label should just return an errno?
--
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/442#issuecomment-320784745
--
openzfs-devel
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/422#issuecomment-318613316
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/gro
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/433#issuecomment-318303586
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/gro
andy-js commented on this pull request.
> @@ -3660,7 +3660,7 @@ zfs_promote(zfs_handle_t *zhp)
return (zfs_error(hdl, EZFS_EXISTS, errbuf));
default:
- return (zfs_standard_error(hdl, save_errno, errbuf));
+ re
andy-js commented on this pull request.
if (ret != 0) {
- int save_errno = errno;
I'm not sure how that happened. I did a build before pushing and it appeared
to complete successfully.
--
You are receiving this because you are subscribed to this thread.
Reply to this e
andy-js commented on this pull request.
> zfs_error_aux(hdl, dgettext(TEXT_DOMAIN,
"not a cloned filesystem"));
return (zfs_error(hdl, EZFS_BADTYPE, errbuf));
}
- (void) strlcpy(zc.zc_value, zhp->zfs_dmustats.dds_origin,
-
andy-js commented on this pull request.
> zfs_error_aux(hdl, dgettext(TEXT_DOMAIN,
"not a cloned filesystem"));
return (zfs_error(hdl, EZFS_BADTYPE, errbuf));
}
- (void) strlcpy(zc.zc_value, zhp->zfs_dmustats.dds_origin,
-
Looks good to me. I suspect this will also solve an unrelated issue I've seen
with netatalk.
--
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-305920296
---
andy-js commented on this pull request.
> @@ -3628,8 +3629,7 @@ int
zfs_promote(zfs_handle_t *zhp)
{
libzfs_handle_t *hdl = zhp->zfs_hdl;
- zfs_cmd_t zc = { 0 };
- char parent[MAXPATHLEN];
+ char snapname[MAXPATHLEN];
Fixed.
--
You are receiving this because you ar
andy-js commented on this pull request.
> +lzc_promote(const char *fsname, char *snapnamebuf, int snapnamelen)
+{
+ /*
+* The promote ioctl is still legacy, so we need to construct our
+* own zfs_cmd_t rather than using lzc_ioctl().
+*/
+ zfs_cmd_t zc = { 0 };
andy-js commented on this pull request.
> +lzc_promote(const char *fsname, char *snapnamebuf, int snapnamelen)
+{
+ /*
+* The promote ioctl is still legacy, so we need to construct our
+* own zfs_cmd_t rather than using lzc_ioctl().
+*/
+ zfs_cmd_t zc = { 0 };
andy-js commented on this pull request.
> @@ -3628,8 +3629,7 @@ int
zfs_promote(zfs_handle_t *zhp)
{
libzfs_handle_t *hdl = zhp->zfs_hdl;
- zfs_cmd_t zc = { 0 };
- char parent[MAXPATHLEN];
+ char snapname[MAXPATHLEN];
Yeah it probably should.
--
You are receiving t
Thanks Yuri. Feel free to count me as a reviewer.
--
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/358#issuecomment-304988815
--
openzfs-develope
Feel free to count me as a reviewer too.
--
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/101#issuecomment-304988132
--
openzfs-developer
Archives
andy-js commented on this pull request.
> @@ -2301,11 +2301,18 @@ dump_label(const char *dev)
(void) snprintf(path, sizeof (path), "%s%s", ZFS_RDISK_ROOTD,
dev);
- if ((s = strrchr(dev, 's')) == NULL || !isdigit(*(s + 1)))
+ if ((
andy-js commented on this pull request.
> (void) strlcat(path, "s0", sizeof (path));
}
- if (stat64(path, &statbuf) != 0) {
- (void) printf("failed to stat '%s': %s\n", path,
+ if ((fd = open64(path, O_RDONLY)) < 0) {
+ (voi
andy-js commented on this pull request.
> @@ -2301,11 +2301,18 @@ dump_label(const char *dev)
(void) snprintf(path, sizeof (path), "%s%s", ZFS_RDISK_ROOTD,
dev);
- if ((s = strrchr(dev, 's')) == NULL || !isdigit(*(s + 1)))
+ if ((
@ahrens How does this version look?
--
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/389#issuecomment-304845578
--
openzfs-developer
Archives:
ht
Thanks for the review Andriy.
Please see #389 which is rebased on the latest mater branch.
--
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/387#issuecomment-304505488
--
Closed #387.
--
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/387#event-1100136649
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/gr
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/389
-- Commit Summary --
* 8264 want support for promoting datasets in libzfs_core
-- File Changes --
M usr/src/lib/libzfs/common/libzfs_dataset.c (14)
M usr/src/lib/libzfs_core
Closing this. Please see #387
--
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/385#issuecomment-304476981
--
openzfs-developer
Archives:
https:/
You can view, comment on, or merge this pull request online at:
https://github.com/openzfs/openzfs/pull/387
-- Commit Summary --
* 8264 want support for promoting datasets in libzfs_core
-- File Changes --
M usr/src/lib/libzfs/common/libzfs_dataset.c (14)
M usr/src/lib/libzfs_core
Closed #385.
--
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/385#event-116149
--
openzfs-developer
Archives:
https://openzfs.topicbox.com/gr
andy-js commented on this pull request.
> @@ -203,6 +204,23 @@ lzc_clone(const char *fsname, const char *origin,
return (error);
}
+int
+lzc_promote(const char *fsname, const char *origin)
Thanks for the feedback.
I agree with Matt. Please hold off integrating this change while I l
1 - 100 of 102 matches
Mail list logo
