On 16/10/2014 08:56, Justin T. Gibbs wrote:
avg pointed out the rate limiting code in vm_pageout_scan() during discussion
about PR 187594. While it certainly can contribute to the problems discussed
in that PR, a bigger problem is that it can allow the OOM killer to be
triggered even though
On 16/10/2014 08:56, Justin T. Gibbs wrote:
avg pointed out the rate limiting code in vm_pageout_scan() during discussion
about PR 187594. While it certainly can contribute to the problems discussed
in that PR, a bigger problem is that it can allow the OOM killer to be
triggered even though
On 1010T1529, Matthew Grooms wrote:
All,
I am a long time user and advocate of FreeBSD and manage a several
deployments of FreeBSD in a few data centers. Now that these
environments are almost always virtual, it would make sense that FreeBSD
support for basic features such as dynamic
On Oct 16, 2014, at 1:10, Edward Tomasz Napierała tr...@freebsd.org wrote:
camcontrol rescan does not force fetching the updated disk size.
AFAIK there is no way to do that. However, this should happen
automatically, if the other side properly sends proper Unit Attention
after resizing.
Unfortunately ZFS doesn't prevent new inflight writes until it
hits zfs_dirty_data_max, so while what your suggesting will
help, if the writes come in quick enough I would expect it to
still be able to out run the pageout.
- Original Message -
From: Justin T. Gibbs gi...@freebsd.org
Bezüglich Ian Lepore's Nachricht vom 14.10.2014 19:00 (localtime):
…
The old code that used to work for you got the version via sysctl, so I
was recommending that you keep doing that yourself, since it's no longer
built in to bsd.ports.mk.
So just add export OSVERSION=`sysctl
On 2014-10-16 04:17, Garrett Cooper wrote:
On Oct 16, 2014, at 1:10, Edward Tomasz Napierała tr...@freebsd.org
wrote:
camcontrol rescan does not force fetching the updated disk size.
AFAIK there is no way to do that. However, this should happen
automatically, if the other side properly sends
The zfs recv / kmem arena hang happens with -CURRENT as well as
10-STABLE, on two different systems, with 16GB or 32GB of RAM, from
memstick or normal multi-user environments,
Hangs usually seem to hapeen 1TB to 3TB in, but last night one run hung
after only 4.35MB.
On 9/26/2014 1:42 AM, James
Bezüglich O. Hartmann's Nachricht vom 04.10.2014 08:47 (localtime):
…
Sorry, forget the suggestion, it doesn't work since it leads to CFLAG
-march= and the same problem occurs.
For my case this works:
--- sys/boot/efi/Makefile.inc.orig 2014-09-23 16:22:46.0 +0200
+++
On 16/10/2014 12:08, Steven Hartland wrote:
Unfortunately ZFS doesn't prevent new inflight writes until it
hits zfs_dirty_data_max, so while what your suggesting will
help, if the writes come in quick enough I would expect it to
still be able to out run the pageout.
As I've mentioned,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/16/14 4:25 AM, James R. Van Artsdalen wrote:
The zfs recv / kmem arena hang happens with -CURRENT as well as
10-STABLE, on two different systems, with 16GB or 32GB of RAM,
from memstick or normal multi-user environments,
Hangs usually
[Please reply to freebsd-rc@]
Hi,
I would like your feedback and testers of the attached patch. This
implements multiple instance support in rc.d scripts. You can try it
by replacing /etc/rc.subr with the attached one.
More details are as follow. Typically, an rc.d/foo script has the
On 2014-10-16 21:22, Hiroki Sato wrote:
[Please reply to freebsd-rc@]
Hi,
I would like your feedback and testers of the attached patch. This
implements multiple instance support in rc.d scripts. You can try it
by replacing /etc/rc.subr with the attached one.
More details are as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/16/14 8:43 PM, James R. Van Artsdalen wrote:
On 10/16/2014 11:12 AM, Xin Li wrote:
On 9/26/2014 1:42 AM, James R. Van Artsdalen wrote:
FreeBSD BLACKIE.housenet.jrv 10.1-BETA2 FreeBSD 10.1-BETA2
#2 r272070M: Wed Sep 24 17:36:56 CDT 2014
14 matches
Mail list logo
