Do you have vm.kmem_size set in /boot/loader.conf?
If not, do set it to about double of your physical RAM size. Defaults
are way too conservative for use with large amounts of memory and ZFS.
--Artem
On Wed, Apr 28, 2010 at 8:07 PM, James R. Van Artsdalen
wrote:
> FreeBSD bigback.housenet.jrv
If I understand it correctly, the problem in this case is that even
when you do have more than enough RAM, kernel just does not provide
enough space in kmem_map to map that physical memory into.
Unless you want to have dedupe turned on large filesystem (and FreeBSD
does not have this feature yet)
> But did they close the sources too ?
> I mean, they have a VCS, can we still access it and download the ZFS source
> files ?
If I understand Oracle's announcement correctly, sources would still
be available. The change is that they will stop publishing them
near-real-time and would release them
> So all we need to direct some of the money we already spend for
> supporting developers and certain developments to core ZFS developers no
> longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS
> development platform for the future. If you have the key developers, the
> communi
Another "me too" here.
8-stable/amd64 + v15 (zpool still uses v14) + metaslab +
abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches.
The box survived few days of pounding on it without any signs of trouble.
--Artem
On Fri, Aug 27, 2010 at 4:19 PM, Norikatsu Shigemura wrote:
On Fri, Aug 27, 2010 at 6:24 PM, jhell wrote:
> On 08/27/2010 19:50, Artem Belevich wrote:
>> Another "me too" here.
>>
>> 8-stable/amd64 + v15 (zpool still uses v14) + metaslab +
>> abe_stat_rrwlock + A.Gapon's vm_paging_needed() + uma defrag patches.
&
On Tue, Dec 21, 2010 at 1:26 AM, Artem Belevich wrote:
> On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote:
>> It would be nice to get the i386 counterpart too when this goes into the
>> tree.
>
> Here's updated version that has syscall:linux32 worki
On Mon, Dec 20, 2010 at 3:15 AM, Andriy Gapon wrote:
> It would be nice to get the i386 counterpart too when this goes into the tree.
Here's updated version that has syscall:linux32 working on i386, too.
https://sites.google.com/site/abc678site/files/dt-systrace-20101221.patch.gz
--Artem
__
> I have one comment though. I am not sure about renaming syscall.ko to
> syscall_freebsd.ko.
You mean systrace_freebsd.ko.
I've renamed it for consistency with other systrace provider variants.
I can change it back.
> Perhaps we could keep the old name? Or add a new module
> under that name t
>>> I have one comment though. I am not sure about renaming syscall.ko to
>>> syscall_freebsd.ko.
>> I've renamed it for consistency with other systrace provider variants.
>> I can change it back.
>
> I think that I would prefer this.
> If only for POLA reasons.
Done. New patch is here:
https://s
/dev/random and /dev/urandom are relatively slow and are not suitable
as the source of data for testing modern hard drives' sequential
throughput.
On my 3GHz dual-core amd63 box both /dev/random and /dev/urandom max
out at ~80MB/s while consuming 100% CPU time on one of the processor
cores.
That w
On Mon, Oct 3, 2011 at 11:21 AM, Paul Mather wrote:
> =
>
> The pool itself reports no errors. I performed a scrub on the pool yet this
> bizarre filesystem corruption persists:
>
> =
> tape# zpool status backups
> pool: backups
> state: ONLINE
> scan: scrub repaired 15K in 7h33m with
On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek wrote:
> On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote:
>> > Should it be set to a larger initial value based on min(physical,KVM)
>> > space
>> > available?
>>
>> It needs to be smaller than the physical space, [...]
>
> O
On Wed, Jan 23, 2013 at 8:32 AM, Luigi Rizzo wrote:
> Probably our compiler folks have some ideas on this...
>
> When doing netmap i found that on FreeBSD memcpy/bcopy was expensive,
> __builtin_memcpy() was even worse, and so i ended up writing
> my custom routine, (called pkt_copy() in the progr
On Sat, Nov 2, 2013 at 9:47 AM, Teske, Devin wrote:
>> where are the forth files in question?
>>
>
> D'Oh!
>
> Here they are:
>
> http://druidbsd.cvs.sf.net/viewvc/druidbsd/forth_zfs/
>
> Supplied as patches to either stable/9 or head.
> --
> Devin
Thanks for the patches. Tried on stable/9 and th
--Artem
On Fri, Mar 25, 2011 at 8:05 PM, Nerius Landys wrote:
>> Use devel/subversion-freebsd though so it expands the $FreeBSD$ RCS tag.
>
> I just did that. I am afraid however that all of my files in /etc
> will have a different RCS tag. For example, I got /usr/src/ via SVN
> directly (hea
On Sat, Mar 26, 2011 at 10:31 AM, Nerius Landys wrote:
> By the way, are there any other ways that are more preferred to get
> /usr/src/ than doing what I've done, which is using
> devel/subversion-freebsd to checkout head into /usr/src/?
Another option would be to use git.
Some kind soul mainta
On Thu, May 5, 2011 at 4:33 PM, David Christensen wrote:
>> > After building dtrace into the kernel and loading the dtraceall
>> > kernel module, when I load my bxe kernel module and run "dtrace -l"
>> > to list all supported probes I notice that many functions have an
>> > entry probe but no exit
On Thu, May 5, 2011 at 1:08 PM, David Christensen wrote:
> I was looking at using dtrace to help characterize performance
> for the new bxe(4) driver but I'm having problems with the very
> simple task of capturing time spent in a function. The D script
> I'm using looks like the following:
>
> #
On Fri, Jul 1, 2011 at 7:45 AM, Tim Gustafson wrote:
>> it is nice that you give 9 a chance, but there is LSI SAS2008 support
>> in 8.2, too.
>
> I tried booting off an 8.2 release disc and it did not see the controller.
More specifically, it's in 8.2-STABLE. mps driver was MFC'ed on Feb
18th, 20
On Sun, Jul 17, 2011 at 4:54 AM, Ulrich Spörlein wrote:
...
>> Having a project adopted way of sharing work in progress will be a step
>> forward. Yes, I'm aware of perforce, it's to hard to use and wasn't
>> designed to share and test ideas. I think guthub can be a very good
>> candidate (but AFA
On Thu, Sep 1, 2011 at 12:25 PM, Matt Thyer wrote:
> On Sep 2, 2011 4:35 AM, "Nathan Whitehorn" wrote:
>>
>> On 09/01/11 14:00, Matt Thyer wrote:
>>>
>>> Shouldn't we use MBR partitioning instead of GPT for the memstick image ?
>>>
>>> We won't need larger than 2TiB installation media for many de
22 matches
Mail list logo
