Thanks for passing this along, Mark.
Comments embedded
> On Aug 29, 2018, at 2:22 PM, Mark Johnston wrote:
>
> On Wed, Aug 29, 2018 at 12:42:33PM +0300, Paul wrote:
>> Hello team,
>>
>>
>> It seems like a commit on Mar 23 introduced a bug: if during execution of
>> arc_adjust()
>> target is
> On Aug 29, 2018, at 11:49 AM, w.kruzel via openzfs-developer
> wrote:
>
> I think yes, there is sufficient demand to have I/O at such level. What do
> you mean by higher rate for the same workload? If types of devices - I have
> tested two Intel nvme disks and one of them had a
On Wed, Aug 29, 2018 at 12:42:33PM +0300, Paul wrote:
> Hello team,
>
>
> It seems like a commit on Mar 23 introduced a bug: if during execution of
> arc_adjust()
> target is reached after MRU is evicted current code continues evicting MFU.
> Before said
> commit, on the step prior to MFU
@lundman FYI, I added 3 commits to fix a few more issues. There were some
changes on linux that were not directly related to encryption but which the
encryption code depends on.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
@ahrens pushed 3 commits.
3de57cc fix error handling in arc_read
5548355 spill blocks are metadata
e2df9b7 zfs_receive_one needs to restore keylocation prop
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
@GernotS Thanks for your report. I was not able to reproduce this with a
simple test. Could you upload/send me the crash dump?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
I think yes, there is sufficient demand to have I/O at such level. What do you
mean by higher rate for the same workload? If types of devices - I have tested
two Intel nvme disks and one of them had a throughput limit on 1 thread at
about 225MB/s while the other had an output of 285MB/s
I shall
amotin commented on this pull request.
> @@ -1039,6 +1039,13 @@ metaslab_group_allocatable(metaslab_group_t *mg,
> metaslab_group_t *rotor,
if (mg->mg_no_free_space)
return (B_FALSE);
+ /*
+* Relax allocation throttling
ahrens commented on this pull request.
> @@ -1039,6 +1039,13 @@ metaslab_group_allocatable(metaslab_group_t *mg,
> metaslab_group_t *rotor,
if (mg->mg_no_free_space)
return (B_FALSE);
+ /*
+* Relax allocation throttling
pzakha approved this pull request.
Great changes!
--
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/688#pullrequestreview-150579785
--
openzfs:
10 matches
Mail list logo
