I've rebased it off openzfs/master and pushed it back to my fork (had to push
-f though) -- though I'm not sure what needs to happen (if anything) for the PR
to update (or if I'd need to just create a new one).
--
You are receiving this because you are subscribed to this thread.
Reply to this
The output is somewhat confusing -- it suggests there are a number of tests
that are passing that it expected it not to pass?? Does that mean all of those
are a problem?
There does look to be one test that's failing - FAIL
largest_pool/largest_pool_001_pos (expected PASS)
-- but I cannot find
Hmm.. some reason my original comment didn't get posted. I found the error, I
just need to figure out what the values were that triggered the overflow (I'll
dig into the test itself this afternoon and see what I can figure out on that).
I suspect what might be happening is that the output
Having had some resource constraints on my OmniOS vm that's preventing the
running of all of the zfs tests on it, per Matt Ahrens's suggestion, creating
the PR here to run the ZFS tests to ensure this doesn't cause a problem with
any of the tests.
You can view, comment on, or merge this pull
FYI, a webrev is available here: http://cr.illumos.org/~webrev/jbk/demangle/
--
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/575#issuecomment-369123501
jasonbking 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/700#pullrequestreview-163395125
--
openzfs:
jasonbking requested changes on this pull request.
Just two cstyle nits, otherwise looks good.
> @@ -1166,6 +1176,14 @@ mountpoint_cmp(const void *arga, const void *argb)
const char *a = mounta;
const char *b = mountb;
boolean_t gota, gotb;
+ uint64_t zoneda,
For a small amount of background, I’ve been trying to help nail down some
of the reported problems from users trying out the zfs crypto PR on illumos
distros. I have one instance here I’ve been digging into, and have some
questions I’m hoping those who’ve spent far more time in this code than I
How would cross-dataset files be accounted in the dataset quotas? With
snapshot/clones IIRC, since there’s an origin dataset that gets ‘charged’
the space for all the unchanged blocks. It seems like doing the same here
would make the most sense (the original source of the file gets ‘charged’
for
On most unix-like platforms, sizeof(int) == 4, even for 64-bit binaries, and
you still need ‘long int’ to get 64-bits.
From: Igor Kozhukhov
Reply: openzfs-developer
Date: June 26, 2018 at 4:05:22 AM
To: openzfs-developer
Cc: Yuri Pankov
Subject: Re: [developer] Re: zfs tests design/issues
I believe in illumos, getopt_long() without any long options will operate
similar to glibc’s getopt() in that it will permute argv to find and process
options intermixed with arguments (however as the way that glibc does this is
not documented, when there are ambiguities on if a particular
Are there any concerns this might become a bit unwieldy over time? I’m
undecided on this myself, but thought it’d be worth raising the question.
Just as a data point, had this existed when ZFS was first publicly released
(Nov 2005 is the date I can find), that would mean 13 ‘portable-XXX’
t: Re: [developer] Panic when receiving from encrypted zpool
On Fri, Nov 16, 2018 at 12:11 PM Jason King wrote:
> For a small amount of background, I’ve been trying to help nail down some
> of the reported problems from users trying out the zfs crypto PR on illumos
> distros. I have on
13 matches
Mail list logo
