Thanks for giving this a look @rmustacc.
> Doesn't it strike others as odd when you have a userland program use a
> kmutex_t, but then also referring to the userland bits like a normal
> USYNC_THREAD, which is definitely a userland mutex thing.
Thanks for catching this; this is wrong. Rather
grwilson commented on this pull request.
I have concerns about the ultimate goal for this command. It's unclear if we
really want to "wipe" or just "forget" about this device.
> @@ -709,8 +751,12 @@ zpool_do_labelclear(int argc, char **argv)
}
if (zpool_read_label(fd, ) != 0)
jwk404 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/537#pullrequestreview-94780084
--
openzfs-developer
pzakha 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/537#pullrequestreview-94794188
--
openzfs-developer
@prakashsurya pushed 1 commit.
7b561cc Iterate based Rob's and Andrew's feedback
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@andy-js @rmustacc let me know if my latest change is what y'all were thinking.
I haven't tested this yet, beyond verifying it builds.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Problem
The domount() function that is called by the mount() system call erroneously
calls lookupname() (a VFS filename lookup function) on ZFS filesystem names
when mounting ZFS filesystems. This causes spurious short-lived vnode holds to
be placed on vnode_t's unrelated to the filesystem being
I've run out of obvious looking diffs between ZOL and this commit. Might
require actual debugging now. Seems to die pretty early in `arc_buf_remove` but
it'd be nice to know where.
ZOL also has a `arc_buf_access()` called from `dbuf` but the ZOL commit
0873bb63 just talks about counting stats.
@lundman The PR testing is busted (sorry for that), but I just pulled this code
and kicked of a run using our internal Delphix test automation. I'll report
back after it completes.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
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
Thanks. I'll look into that, and push a new revision when I have something
working.
--
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-363920916
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
martymac commented on this pull request.
> @@ -709,8 +751,12 @@ zpool_do_labelclear(int argc, char **argv)
}
if (zpool_read_label(fd, ) != 0) {
- (void) fprintf(stderr,
- gettext("failed to read label from %s\n"), vdev);
+ if
martymac commented on this pull request.
> + if (pread64(fd, , sizeof (vdev_label_t),
+ label_offset(size, l)) != sizeof (vdev_label_t))
+ return (-1);
+
+ if (!force) {
+
Closed #511 via 4f1512595b4bee540e17f1c3ca601da19907e10a.
--
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#event-1463849595
--
Closed #532 via fafe9b241fed18c4119f482c4404b1c7f0c3d90f.
--
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/532#event-1463849600
--
Closed #434 via 78a5a1a25a7da81ed26d113699f3258dabd240ef.
--
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/434#event-1463849593
--
Closed #537 via d544209e17ded7a2f9f13d9992090ce495c88786.
--
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/537#event-1463849602
--
Closed #512 via 61d571bb1aca048a9ad48985ca5beb6d476fcbd2.
--
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/512#event-1463849598
--
I´m sorry to report the latest commit didnt fix my problem yet, but it indeed
cured a long open issue with compressed send/receive, see also
https://www.illumos.org/issues/7252
This is now the first time I was able to use zfs send -c sucessfully for more
than just a few GB of data.
Thanks for
Neat, I didn't mention the commit today, since the ZOL tickets just talked
about send|recv :)
Still unable to reproduce dnode_destroy panic, but the tester here seems to die
though
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Albeit my current dump looks a bit different:
panic[cpu1]/thread=ff000fa9cc40:
BAD TRAP: type=e (#pf Page fault) rp=ff000fa9c870 addr=68 occurred in
module "zfs" due to a NULL pointer dereference
sched:
#pf Page fault
Bad kernel fault at addr=0x68
pid=0, pc=0xf7d4b7e6,
22 matches
Mail list logo
