(No changes, just fixed conflicts with master)
--
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/489#issuecomment-364290139
--
openzfs-developer
A
Well, that's good.. Not sure what to do next then, perhaps @GernotS can
provide a dump file, and someone who actually knows how to use mdb (I sure
don't) can be coaxed into glancing at it?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or v
Maybe even `ZIO_GANG_BIT`, etc.
--
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/505#issuecomment-364269552
--
openzfs-developer
Archives:
https:
@grwilson this looks good to me!
But... But! I've wondered only __just now__ if we could have best of both
approaches by pre-defining the child type bits. E.g.
```
#define ZIO_CHILD_BIT_GANGZIO_CHILD_BIT(ZIO_CHILD_GANG)
```
... or something like that.
Maybe that could help to make the code wh
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
Yeah, this change was in response to a change in our application that disabled
per-process cores, leaving them only in /var/crash. This change lets us get
cores from cwd. I wouldn't guess this change would have broad appeal (assuming
most folks don't disable per-process cores) but I don't think
Reviewed by: Matthew Ahrens
Reviewed by: George Wilson
Description
A scenario came up where a callback executed by vdev_indirect_remap() on a
vdev, calls
vdev_indirect_remap() on the same vdev and tries to reacquire
vdev_indirect_rwlock that
was already acquired from the first call to vdev_in
Reviewed by: Matt Ahrens
Reviewed by: Pavel Zakharov
The timeline of the race condition is the following:
[1] Thread A is about to finish condesing the first vdev in
spa_condense_indirect_thread(),
so it calls the spa_condense_indirect_complete_sync() sync task which sets
the
spa_conde
Looking at our internal issue, I think we have coreadm configure to put core
files in `/var/crash`. We added this so the core files would end up in the CWD
and would get collected by our automation (with the other zloop
files/logs/etc). So, I think the answer is yes.. @jwk404 can you confirm?
-
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
-
youzhongyang commented on this pull request.
It looks good to me. 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/505#pullrequestreview-95227067
-
@youzhongyang @avg-I can you take another look to make sure I've address all of
your concerns?
--
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/505#issuecomment-364239237
--
Your comments are considered and I will be pushing a new commit with the
updated logic. I've tried several variations to the suggestions to find which
looks the best and has the least amount of impact. The suggested
`ZIO_CHILD_BIT` option looks the best so I've gone with that option.
--
You ar
Reviewed by: Serapheim Dimitropoulos
Reviewed by: Prakash Surya
To make zloop for resilient to coreadm configuration differences on the various
illumos distributions, we should enable per process core dumps at the start of
zloop.
Upstream bug: DLPX-52252
You can view, comment on, or merge this
@prakashsurya pushed 1 commit.
c8a3e65 Fix cstyle; use tab for indentation, not spaces
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/openzfs/openzfs/pull/536/files/3a83672ecf670c528f05209997189ad8c22ce836..c8a3e654b0940d3ba0914b397f2
so our comments will not be considered?
--
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/505#issuecomment-364225821
--
openzfs-developer
Archives:
ahrens 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/505#pullrequestreview-95183334
--
openzfs-developer
Archiv
@prakashsurya pushed 2 commits.
20d3e56 Missed a mutex_{enter,exit} pair, causing a crash
3a83672 Fix lint; add guards for _TASKQUSER in lgrp_user.h
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/openzfs/openzfs/pull/536/files/7b561c
This passed zfstest and zloop using our internal test automation.
--
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/489#issuecomment-364181843
--
o
Reviewed by: George Wilson
Reviewed by: Matthew Ahrens
Some work has been done lately to improve the debugability of the ZFS pool
load (and import) process. This includes:
7638 Refactor spa_load_impl into several functions
8961 SPA load/import should tell us why it failed
20 matches
Mail list logo