Re: kern.sched.quantum: Creepy, sadistic scheduler

[Eugene Grosbein]

04.04.2018 21:16, Peter wrote:

> // With nCPU compute-bound processes running, with SCHED_ULE, any other
> // process that is interactive (which to me means frequently waiting for
> // I/O) gets ABYSMAL performance -- over an order of magnitude worse
> // than it gets with SCHED_4BSD under the same conditions. --
> https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html
> 
> And this describes quite exactly what I perceive.
> Now, I would like to ask: what has been done about this issue?

I see no reasons to use SHED_ULE for such single core systems and use SCHED_BSD.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

Andriy Gapon wrote:

Not everyone has a postgres server and a suitable database.
Could you please devise a test scenario that demonstrates the problem and that
anyone could run?



Alright, simple things first: I can reproduce the effect without 
postgres, with regular commands. I run this on my database file:


# lz4 2058067.1 /dev/null

And have this as throughput:

poolalloc   free   read  write   read  write
cache   -  -  -  -  -  -
  ada1s47.08G  10.9G889  0  7.07M  42.3K

  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
51298 root870 16184K  7912K RUN  1:00  51.60% lz4

I start the piglet:

$ while true; do :; done

And, same effect:

poolalloc   free   read  write   read  write
cache   -  -  -  -  -  -
  ada1s47.08G  10.9G 10  0  82.0K  0

  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
 1911 admin   980  7044K  2860K RUN 65:48  89.22% bash
51298 root520 16184K  7880K RUN  0:05   0.59% lz4


It does *not* happen with plain "cat" instead of "lz4".

What may or may not have an influence on it: the respective filesystem 
is block=8k, and is 100% resident in l2arc.


What is also interesting: I started trying this with "tar" (no effect,
behaves properly), then with "tar --lz4". In the latter case "tar" 
starts "lz4" as a sub-process, so we have three processes in the play - 
and in that case the effect happens, but to lesser extent: about 75 I/Os 
per second.
So, it seems quite clear that this has something to do with the logic 
inside the scheduler.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

Andriy Gapon wrote:

On 04/04/2018 03:52, Peter wrote:

Lets run an I/O-active task, e.g, postgres VACUUM that would
continuousely read from big files (while doing compute as well [1]):


Not everyone has a postgres server and a suitable database.
Could you please devise a test scenario that demonstrates the problem and that
anyone could run?



Andriy,

and maybe nobody anymore has such old system that is CPU-bound instead 
of IO-bound. I'd rather think about reproducing it on my IvyBridge.


I know for sure that it is *not* specifically dependent on postgres.
What I posted was the case when an endless-loop piglet starves a 
postgres VACUUM - and there we see a very pronounced effect of almost

factor 100.
When I first clearly discovered it (after a long time of belly-feeling 
that something behaves strange), it was postgres pg_dump (which does 
compression, i.e. CPU-bound) as the piglet starving an bacula-fd

backup that would scan the filesystem.

So, there is a general rule: we have one process that is a CPU-hog, and 
another process that does periodic I/O (but also *some* compute). and 
-important!- nothing else.


If we understand the logic of the scheduler, that information should 
already suit for some logical verification *eg* - but I will see if I 
get it reprocuved on the IvyBridge machine and/or see if I get a 
testcase together. May take a while.


P.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Andriy Gapon]

On 04/04/2018 03:52, Peter wrote:
> Lets run an I/O-active task, e.g, postgres VACUUM that would
> continuousely read from big files (while doing compute as well [1]):

Not everyone has a postgres server and a suitable database.
Could you please devise a test scenario that demonstrates the problem and that
anyone could run?

-- 
Andriy Gapon
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[George Mitchell]

On 04/04/18 10:34, Peter wrote:
> [...] It does not make sense to me if now we state that
> we cannot do it anymore because single-CPU is uncommon today.
> [...]
+1.-- George



signature.asc
Description: OpenPGP digital signature

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

Hi Alban!

Alban Hertroys wrote:

Occasionally I noticed that the system would not quickly process the
tasks i need done, but instead prefer other, longrunning tasks. I
figured it must be related to the scheduler, and decided it hates me.


If it hated you, it would behave much worse.


Thats encouraging :)  But I would say, running a job 100 times slower 
than expected is quite an amount of hate for my taste.



A closer look shows the behaviour as follows (single CPU):


A single CPU? That's becoming rare! Is that a VM? Old hardware? Something 
really specific?


I don't plug in another CPU because there is no need to. Yes, its old 
hardware:

CPU: Intel Pentium III (945.02-MHz 686-class CPU)
ACPI APIC Table: 

If I had bought new hardware, this one would now rot in Africa, and I 
would have new hardware idling along that is spectre/meltdown affected 
nevertheless.



Lets run an I/O-active task, e.g, postgres VACUUM that would


And you're running a multi-process database server on it no less. That > is 
going to hurt,


I'm running a lot more than only that on it. But it's all private use, 
idling most of the time.



no matter how well the scheduler works.


Maybe. But this post is not about my personal expectations on over-all 
performance - it is about a specific behaviour that is not how a 
scheduler is expected to behave - no matter if we're on a PDP-11 or on a 
KabyLake.



Now, as usual, the "root-cause" questions arise: What exactly does
this "quantum"? Is this solution a workaround, i.e. actually something
else is wrong, and has it tradeoff in other situations? Or otherwise,
why is such a default value chosen, which appears to be ill-deceived?

The docs for the quantum parameter are a bit unsatisfying - they say
its the max num of ticks a process gets - and what happens when
they're exhausted? If by default the endless loop is actually allowed
to continue running for 94k ticks (or 94ms, more likely) uninterrupted,
then that explains the perceived behaviour - buts thats certainly not
what a scheduler should do when other procs are ready to run.


I can answer this from the operating systems course I followed recently. This 
does not apply to FreeBSD specifically, it is general job scheduling theory. I 
still need to read up on SCHED_ULE to see how the details were implemented 
there. Or are you using the older SCHED_4BSD?


I'm using the default scheduler, which is ULE. I would not go 
non-default without reason. (But it seems, a reason is just appering now.)



Now, that would cause a much worse situation in your example case. The endless 
loop would keep running once it gets the CPU and would never release it. No 
other process would ever get a turn again. You wouldn't even be able to get 
into such a system in that state using remote ssh.

That is why the scheduler has this "quantum", which limits the maximum time the 
CPU will be assigned to a specific job. Once the quantum has expired (with the job 
unfinished), the scheduler removes the job from the CPU, puts it back on the ready queue 
and assigns the next job from that queue to the CPU.
That's why you seem to get better performance with a smaller value for the 
quantum; the endless loop gets forcibly interrupted more often.


Good description. Only my (old-fashioned) understanding was that this is 
the purpose of the HZ value: to give control back to the kernel, so that 
a new decision can be made.
So, I would not have been surpized to see 200 I/Os for postgres 
(kern.hz=200), but what I see is 9 I/Os (which indeed figures to a 
"quantum" of 94ms).


But then, we were able to do all this nicely on single-CPU machines for 
almost four decades. It does not make sense to me if now we state that 
we cannot do it anymore because single-CPU is uncommon today.
(Yes indeed, we also cannot fly to the moon anymore, because today 
nobody seems to recall how that stuff was built. *headbangwall*)



This changing of the active job however, involves a context switch for the CPU. 
Memory, registers, file handles, etc. that were required by the previous job 
needs to be put aside and replaced by any such resources related to the new job 
to be run. That uses up time and does nothing to progress the jobs that are 
waiting for the CPU. Hence, you don't want the quantum to be too small either, 
or you'll end up spending significant time switching contexts.


Yepp. My understanding was that I can influence this behaviour via the 
HZ value, so to tradeoff responsiveness against performance. Obviousely 
that was wrong.

From Your writing, it seems the "quantum" is indeed the correct place
to tune this. (But I will still have to ponder a while about the knob 
mentioned by Stefan, concerning preemption, which seems to magically 
resolve the issue.)



That said, SCHED_ULE (the default scheduler for quite a while now) was designed 
with multi-CPU configurations in mind and there are claims that SCHED_4BSD 
works better for single-CPU configurations. You may 

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Peter]

George Mitchell wrote:

On 04/04/18 06:39, Alban Hertroys wrote:

[...]
That said, SCHED_ULE (the default scheduler for quite a while now) was designed 
with multi-CPU configurations in mind and there are claims that SCHED_4BSD 
works better for single-CPU configurations. You may give that a try, if you're 
not already on SCHED_4BSD.
[...]


A small, disgruntled community of FreeBSD users who have never seen
proof that SCHED_ULE is better than SCHED_4BSD in any environment
continue to regularly recompile with SCHED_4BSD.  I dread the day when
that becomes impossible, but at least it isn't here yet.  -- George



Yes *laugh*, I found a very lengthy and mind-boggling discussion from 
back in 2011. And I found that You made this statement somewhere there:


// With nCPU compute-bound processes running, with SCHED_ULE, any other
// process that is interactive (which to me means frequently waiting for
// I/O) gets ABYSMAL performance -- over an order of magnitude worse
// than it gets with SCHED_4BSD under the same conditions. --
https://lists.freebsd.org/pipermail/freebsd-stable/2011-December/064984.html

And this describes quite exactly what I perceive.
Now, I would like to ask: what has been done about this issue?

P.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Try setting kern.sched.preempt_thresh != 0

[Peter]

Stefan Esser wrote:


I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which
prevents preemption of low priority processes by interactive or I/O bound
processes.

For a quick test try:

# sysctl kern.sched.preempt_thresh=1


Hi Stefan,

thank You, thats an interesting knob! Only it is actually the other way 
round: it is not set to 0. My settings (as default) are:


kern.sched.steal_thresh: 2
kern.sched.steal_idle: 1
kern.sched.balance_interval: 127
kern.sched.balance: 1
kern.sched.affinity: 1
kern.sched.idlespinthresh: 157
kern.sched.idlespins: 1
kern.sched.static_boost: 152
kern.sched.preempt_thresh: 80
kern.sched.interact: 30
kern.sched.slice: 12
kern.sched.quantum: 94488
kern.sched.name: ULE
kern.sched.preemption: 1
kern.sched.cpusetsize: 4

But then, if I change kern.sched.preempt_thresh to 1 *OR* 0, things 
behave properly! Precisely, changing from 8 down to 7 changes things 
completely:


>poolalloc   free   read  write   read  write
>cache   -  -  -  -  -  -
>  ada1s47.08G  10.9G927  0  7.32M  0

>  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
> 1900 pgsql   820   618M 17532K RUN  0:53  34.90% postgres
> 1911 admin   810  7044K  2824K RUN  6:07  28.34% bash

(Notice the PRI values which also look differnt now.)

rgds,
P.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

RE: Delegates Email list of Atlanta Apartment Association 2018

[Veronica Baker]

 

 

Hi,

 

I hope you're doing well.

 

I was wondering if you had a chance to review my previous email that I sent
to you.

 

Kindly let me know your interest so that i can get back to you with counts
and pricing available.

 

 

Best Regards,

Veronica Baker

 

From: Veronica Baker [mailto:veronica.ba...@showezdeligates.com] 
Sent: 29 March 2018 12:59
To: 'freebsd-stable@freebsd.org'
Subject: Delegates Email list of Atlanta Apartment Association 2018

 

Hi,

 

Would you be interested in Attendees Email List Of Atlanta Apartment
Association 2018.? 

 

Attendees:

 

. Decision Makers

. Apartment owners

. Managers

. Suppliers, and Professionals

 

List includes: E-mails, contact number and other fields on an excel sheet.

 

Would you like to see counts and pricing details available.?

 

Looking forward for your email.

 

 

Regards,

Veronica Baker| B.D.Exe

 

If you do not wish to receive future emails from us, please reply as
"Exclude Me"

 

 

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[George Mitchell]

On 04/04/18 06:39, Alban Hertroys wrote:
> [...]
> That said, SCHED_ULE (the default scheduler for quite a while now) was 
> designed with multi-CPU configurations in mind and there are claims that 
> SCHED_4BSD works better for single-CPU configurations. You may give that a 
> try, if you're not already on SCHED_4BSD.
> [...]

A small, disgruntled community of FreeBSD users who have never seen
proof that SCHED_ULE is better than SCHED_4BSD in any environment
continue to regularly recompile with SCHED_4BSD.  I dread the day when
that becomes impossible, but at least it isn't here yet.  -- George



signature.asc
Description: OpenPGP digital signature

Try setting kern.sched.preempt_thresh != 0 (was: Re: kern.sched.quantum: Creepy, sadistic scheduler)

[Stefan Esser]

Am 04.04.18 um 12:39 schrieb Alban Hertroys:
> 
>> On 4 Apr 2018, at 2:52, Peter  wrote:
>>
>> Occasionally I noticed that the system would not quickly process the
>> tasks i need done, but instead prefer other, longrunning tasks. I
>> figured it must be related to the scheduler, and decided it hates me.
> 
> If it hated you, it would behave much worse.
> 
>> A closer look shows the behaviour as follows (single CPU):
> 
> A single CPU? That's becoming rare! Is that a VM? Old hardware? Something 
> really specific?
> 
>> Lets run an I/O-active task, e.g, postgres VACUUM that would
> 
> And you're running a multi-process database server on it no less. That is 
> going to hurt, no matter how well the scheduler works.
> 
>> continuousely read from big files (while doing compute as well [1]):
>>> poolalloc   free   read  write   read  write
>>> cache   -  -  -  -  -  -
>>>  ada1s47.08G  10.9G  1.58K  0  12.9M  0
>>
>> Now start an endless loop:
>> # while true; do :; done
>>
>> And the effect is:
>>> poolalloc   free   read  write   read  write
>>> cache   -  -  -  -  -  -
>>>  ada1s47.08G  10.9G  9  0  76.8K  0
>>
>> The VACUUM gets almost stuck! This figures with WCPU in "top":
>>
>>>  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
>>> 85583 root990  7044K  1944K RUN  1:06  92.21% bash
>>> 53005 pgsql   520   620M 91856K RUN  5:47   0.50% postgres
>>
>> Hacking on kern.sched.quantum makes it quite a bit better:
>> # sysctl kern.sched.quantum=1
>> kern.sched.quantum: 94488 -> 7874
>>
>>> poolalloc   free   read  write   read  write
>>> cache   -  -  -  -  -  -
>>>  ada1s47.08G  10.9G395  0  3.12M  0
>>
>>>  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
>>> 85583 root940  7044K  1944K RUN  4:13  70.80% bash
>>> 53005 pgsql   520   276M 91856K RUN  5:52  11.83% postgres
>>
>>
>> Now, as usual, the "root-cause" questions arise: What exactly does
>> this "quantum"? Is this solution a workaround, i.e. actually something
>> else is wrong, and has it tradeoff in other situations? Or otherwise,
>> why is such a default value chosen, which appears to be ill-deceived?
>>
>> The docs for the quantum parameter are a bit unsatisfying - they say
>> its the max num of ticks a process gets - and what happens when
>> they're exhausted? If by default the endless loop is actually allowed
>> to continue running for 94k ticks (or 94ms, more likely) uninterrupted,
>> then that explains the perceived behaviour - buts thats certainly not
>> what a scheduler should do when other procs are ready to run.
> 
> I can answer this from the operating systems course I followed recently. This 
> does not apply to FreeBSD specifically, it is general job scheduling theory. 
> I still need to read up on SCHED_ULE to see how the details were implemented 
> there. Or are you using the older SCHED_4BSD?
> Anyway...
> 
> Jobs that are ready to run are collected on a ready queue. Since you have a 
> single CPU, there can only be a single job active on the CPU. When that job 
> is finished, the scheduler takes the next job in the ready queue and assigns 
> it to the CPU, etc.

I'm guessing that the problem is caused by kern.sched.preempt_thresh=0, which
prevents preemption of low priority processes by interactive or I/O bound
processes.

For a quick test try:

# sysctl kern.sched.preempt_thresh=1

to see whether it makes a difference. The value 1 is unreasonably low, but it
has the most visible effect in that any higher priority process can steal the
CPU from any lower priority one (high priority corresponds to low PRI values
as displayed by ps -l or top).

Reasonable values might be in the range of 80 to 224 depending on the system
usage scenario (that's what I found to have been suggested in the mail-lists).

Higher values result in less preemption.

Regards, STefan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: kern.sched.quantum: Creepy, sadistic scheduler

[Alban Hertroys]

> On 4 Apr 2018, at 2:52, Peter  wrote:
> 
> Occasionally I noticed that the system would not quickly process the
> tasks i need done, but instead prefer other, longrunning tasks. I
> figured it must be related to the scheduler, and decided it hates me.

If it hated you, it would behave much worse.

> A closer look shows the behaviour as follows (single CPU):

A single CPU? That's becoming rare! Is that a VM? Old hardware? Something 
really specific?

> Lets run an I/O-active task, e.g, postgres VACUUM that would

And you're running a multi-process database server on it no less. That is going 
to hurt, no matter how well the scheduler works.

> continuousely read from big files (while doing compute as well [1]):
> >poolalloc   free   read  write   read  write
> >cache   -  -  -  -  -  -
> >  ada1s47.08G  10.9G  1.58K  0  12.9M  0
> 
> Now start an endless loop:
> # while true; do :; done
> 
> And the effect is:
> >poolalloc   free   read  write   read  write
> >cache   -  -  -  -  -  -
> >  ada1s47.08G  10.9G  9  0  76.8K  0
> 
> The VACUUM gets almost stuck! This figures with WCPU in "top":
> 
> >  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
> >85583 root990  7044K  1944K RUN  1:06  92.21% bash
> >53005 pgsql   520   620M 91856K RUN  5:47   0.50% postgres
> 
> Hacking on kern.sched.quantum makes it quite a bit better:
> # sysctl kern.sched.quantum=1
> kern.sched.quantum: 94488 -> 7874
> 
> >poolalloc   free   read  write   read  write
> >cache   -  -  -  -  -  -
> >  ada1s47.08G  10.9G395  0  3.12M  0
> 
> >  PID USERNAME   PRI NICE   SIZERES STATETIMEWCPU COMMAND
> >85583 root940  7044K  1944K RUN  4:13  70.80% bash
> >53005 pgsql   520   276M 91856K RUN  5:52  11.83% postgres
> 
> 
> Now, as usual, the "root-cause" questions arise: What exactly does
> this "quantum"? Is this solution a workaround, i.e. actually something
> else is wrong, and has it tradeoff in other situations? Or otherwise,
> why is such a default value chosen, which appears to be ill-deceived?
> 
> The docs for the quantum parameter are a bit unsatisfying - they say
> its the max num of ticks a process gets - and what happens when
> they're exhausted? If by default the endless loop is actually allowed
> to continue running for 94k ticks (or 94ms, more likely) uninterrupted,
> then that explains the perceived behaviour - buts thats certainly not
> what a scheduler should do when other procs are ready to run.

I can answer this from the operating systems course I followed recently. This 
does not apply to FreeBSD specifically, it is general job scheduling theory. I 
still need to read up on SCHED_ULE to see how the details were implemented 
there. Or are you using the older SCHED_4BSD?
Anyway...

Jobs that are ready to run are collected on a ready queue. Since you have a 
single CPU, there can only be a single job active on the CPU. When that job is 
finished, the scheduler takes the next job in the ready queue and assigns it to 
the CPU, etc.

Now, that would cause a much worse situation in your example case. The endless 
loop would keep running once it gets the CPU and would never release it. No 
other process would ever get a turn again. You wouldn't even be able to get 
into such a system in that state using remote ssh.

That is why the scheduler has this "quantum", which limits the maximum time the 
CPU will be assigned to a specific job. Once the quantum has expired (with the 
job unfinished), the scheduler removes the job from the CPU, puts it back on 
the ready queue and assigns the next job from that queue to the CPU.
That's why you seem to get better performance with a smaller value for the 
quantum; the endless loop gets forcibly interrupted more often.

This changing of the active job however, involves a context switch for the CPU. 
Memory, registers, file handles, etc. that were required by the previous job 
needs to be put aside and replaced by any such resources related to the new job 
to be run. That uses up time and does nothing to progress the jobs that are 
waiting for the CPU. Hence, you don't want the quantum to be too small either, 
or you'll end up spending significant time switching contexts. That gets worse 
when the job involves system calls, which are handled by the kernel, which is 
also a process that needs to be switched (and Meltdown made that worse, because 
more rigorous clean-up is necessary to prevent peeks into sections of memory 
that were owned by the kernel process previously).

The "correct" value for the quantum depends on your type of workload. 
PostgreSQL's auto-vacuum is a typical background process that will probably (I 
didn't verify) request to be run at a lower priority, giving other, more 
important, jobs more chance 

Re: another question about zfs compression numbers

[Eugene M. Zheganin]

Hi,

On 04.04.2018 12:35, Patrick M. Hausen wrote:

Hi all,


Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin :
I'm just trying to understand these numbers:

file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so 
then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On 
one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get 
it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks if 
it matters:

A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" zeroes at 
the
VFS layer is not taken into account as fas as I know. Seriously, how should it?
If I'm not mistaken, ZFS will never get to see these empty blocks.

Looks so, thanks. Although it's a mysql tablespace file. But yeah, in 
hex viewer looks like it's filled with zeroes in many places.


Eugene.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: another question about zfs compression numbers

[Patrick M. Hausen]

Hi all,

> Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin :
> I'm just trying to understand these numbers:
> 
> file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so 
> then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On 
> one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get 
> it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks 
> if it matters:

A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" zeroes at 
the
VFS layer is not taken into account as fas as I know. Seriously, how should it?
If I'm not mistaken, ZFS will never get to see these empty blocks.

Patrick
-- 
punkt.de GmbH   Internet - Dienstleistungen - Beratung
Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100
76133 Karlsruhe i...@punkt.de   http://punkt.de
AG Mannheim 108285  Gf: Juergen Egeling

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

another question about zfs compression numbers

[Eugene M. Zheganin]

Hello,


I'm just trying to understand these numbers:


file size is 232G, it's actual size on the lz4-compressed dataset is 
18G, so then why is the compressratio only 1.86x ? And why logicalused 
is 34.2G ? On one hand, 34.2G exactlyfits to the 1.86x compresstaio, but 
still I don't get it. dataset is on raidz, 3 spans across 5 disk vdevs, 
with total of 15 disks if it matters:



# du -h
 18G.
# ls -lh
total 19316318
-rw-r-  1 root  wheel   232G  4 апр.  11:29 mp_userCoordsHistory.ibd
# zfs get all data/test
NAME   PROPERTY  VALUE SOURCE
data/test  type  filesystem  -
data/test  creation  ср апр.  4 10:31 2018  -
data/test  used  18,4G   -
data/test  available 9,95T   -
data/test  referenced18,4G   -
data/test  compressratio 1.86x   -
data/test  mounted   yes -
data/test  quota none default
data/test  reservation   none default
data/test  recordsize128K default
data/test  mountpoint/data/test default
data/test  sharenfs  off default
data/test  checksum  on default
data/test  compression   lz4 local
data/test  atime on default
data/test  devices   on default
data/test  exec  on default
data/test  setuidon default
data/test  readonly  off default
data/test  jailedoff default
data/test  snapdir   hidden default
data/test  aclmode   discard default
data/test  aclinheritrestricted default
data/test  canmount  on default
data/test  xattr off temporary
data/test  copies1 default
data/test  version   5   -
data/test  utf8only  off -
data/test  normalization none-
data/test  casesensitivity   sensitive   -
data/test  vscan off default
data/test  nbmandoff default
data/test  sharesmb  off default
data/test  refquota  none default
data/test  refreservationnone default
data/test  primarycache  all default
data/test  secondarycacheall default
data/test  usedbysnapshots   0   -
data/test  usedbydataset 18,4G   -
data/test  usedbychildren0   -
data/test  usedbyrefreservation  0   -
data/test  logbias   latency default
data/test  dedup on inherited from data
data/test  mlslabel  -
data/test  sync  standard default
data/test  refcompressratio  1.86x   -
data/test  written   18,4G   -
data/test  logicalused   34,2G   -
data/test  logicalreferenced 34,2G   -
data/test  volmode   default default
data/test  filesystem_limit  none default
data/test  snapshot_limitnone default
data/test  filesystem_count  none default
data/test  snapshot_countnone default
data/test  redundant_metadataall default

# zpool status
  pool: data
 state: ONLINE
  scan: scrub repaired 0 in 28h24m with 0 errors on Thu Feb 15 13:26:36 
2018

config:

NAMESTATE READ WRITE CKSUM
dataONLINE   0 0 0
  raidz1-0  ONLINE   0 0 0
da2 ONLINE   0 0 0
da3 ONLINE   0 0 0
da4 ONLINE   0 0 0
da5 ONLINE   0 0 0
da6 ONLINE   0 0 0
  raidz1-1  ONLINE   0 0 0
da7 ONLINE   0 0 0
da8 ONLINE   0 0 0
da9 ONLINE   0 0 0
da10ONLINE   0 0 0
da11ONLINE   0 0 0
  raidz1-2  ONLINE   0 0 0
da12ONLINE   0 0 0
da13ONLINE   0 0 0
da14ONLINE   0 0 0
da15ONLINE   0 0 0
da16ONLINE   0 0 0

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213

--- Comment #15 from Mark Knight  ---
Created attachment 192199
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192199=edit
Kernel config file

Attached kernel config. My kernel is close to generic, extras are:

> options IPFIREWALL
> options IPDIVERT
> options DUMMYNET

then added these for debug, but the problem occurred without them:

> options KDB_UNATTENDED
> options DDB # Support DDB.
> options GDB # Support remote GDB.
> options INVARIANTS  # Enable calls of extra sanity 
> checking
> options INVARIANT_SUPPORT   # Extra sanity checks of internal 
> structures, required by INVARIANTS
> options WITNESS # Enable checks to detect deadlocks 
> and cycles
> options WITNESS_SKIPSPIN# Don't run witness on spinlocks for 
> speed

You've probably got these from loader.conf, but I also have these:

mkn@shrewd$ kldstat
Id Refs AddressSize Name
 1   35 0x8020 17dbb70  kernel
 21 0x819dc000 215a8geom_eli.ko
 32 0x819fe000 352d0crypto.ko
 41 0x81a34000 23fb0geom_mirror.ko
 51 0x81a58000 157c0aio.ko
 61 0x81a6e000 4a70 coretemp.ko
 71 0x81a73000 b188 sem.ko
 81 0x81a7f000 26e0 cc_cubic.ko
 91 0x81c11000 56c6 fdescfs.ko
101 0x81c17000 8df4 uftdi.ko
111 0x81c2 54c4 ucom.ko
121 0x81c26000 3d12clinux.ko
132 0x81c64000 683b linux_common.ko
141 0x81c6b000 37ae9linux64.ko

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

[Bug 227213] FreeBSD 10.4 kernel deadlocks on sysctlmemlock

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227213

--- Comment #14 from Eugene Grosbein  ---
(In reply to Mark Knight from comment #13)

Do you use GENERIC kernel? If not, please attach your kernel config file.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"