HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon

Hello Everyone,

On November 30th, FreeBSD 6.4 and FreeBSD 8.0 will have reached their
End of Life and will no longer be supported by the FreeBSD Security Team.
Since FreeBSD 6.4 is the last remaining supported release from the FreeBSD
6.x stable branch, support for the FreeBSD 6.x stable branch will also
cease at the same point.  Users of either of these FreeBSD releases are
strongly encouraged to upgrade to either FreeBSD 7.3 or FreeBSD 8.1 before
that date.

The FreeBSD Ports Management Team wishes to remind users that November 30
is also the end of support for the Ports Collection for both FreeBSD 6.4
RELEASE and the FreeBSD 6.x STABLE branch.  Neither the infrastructure nor
individual ports are guaranteed to work on these FreeBSD versions after
that date.  A CVS tag will be created for users who cannot upgrade for some
reason, at which time these users are advised to stop tracking the latest
ports CVS repository and use the RELEASE_6_EOL tag instead.

The current supported branches and expected EoL dates are:

   +---------------------------------------------------------------------+
   |  Branch   |  Release   |  Type  |   Release date  |  Estimated EoL  |
   |-----------+------------+--------+-----------------+-----------------|
   |RELENG_6   |n/a         |n/a     |n/a              |November 30, 2010|
   |---------------------------------------------------------------------|
   |RELENG_6_4 |6.4-RELEASE |Extended|November 18, 2008|November 30, 2010|
   |---------------------------------------------------------------------|
   |RELENG_7   |n/a         |n/a     |n/a              |last release + 2y|
   |-----------+------------+--------+-----------------+-----------------|

Re: 8.1-STABLE: zfs and sendfile: problem still exists

on 31/10/2010 11:02 Alexander Zagrebin said the following:
> I have a question.
> When we transfer a file via sendfile, then current code allocates
> a memory, marked inactive. For example, if the file has size 100 MB,
> then 100 MB of memory will be allocated.
> If we have to transfer this file again later, then this memory will used
> as cache, and no disk io will be required.
> The memory will be freed if file will be deleted or operating system
> will need an additional memory. 
> I have correctly understood?
> If it so, the i continue...
> Such behaviour is good if we have files with relatively small size.
> Suppose we have to transfer file with large size (for example, greater 
> than amount of physical memory).
> While transfering, the inactive memory will grow, pressing the ARC.
> When size of the ARC will fall to its minimum (vfs.zfs.arc_min), then
> inactive memory will be reused.
> So, when transfer is complete, we have:
> 1. No free memory
> 2. Size of the ARC has minimal size (it is bad)
> 3. Inactive memory contains the _tail_ of the file only (it is bad too)
> Now if we have to transfer this file again, then
> 1. there is no (or few) file's data in ARC (ARC too small)
> 2. The inactive memory doesn't contain a head part of the file
> So the file's data will read from a disk again and again...
> Also i've noticed that inactive memory frees relatively slowly,
> so if there is a frequent access to large files, then system will run
> at very unoptimal conditions.
> It's imho...
> Can you comment this?

Fwd: amd64: VM_KMEM_SIZE_SCALE changed to 1

FYI, this has been MFC-ed as r214620.

-------- Original Message --------
Message-ID: <4C9323F0.90500 <at> freebsd.org>
Date: Fri, 17 Sep 2010 11:16:48 +0300
From: Andriy Gapon <avg <at> freebsd.org>
To: freebsd-arch <at> FreeBSD.org
CC: freebsd-current <at> FreeBSD.ORG
Subject: amd64: VM_KMEM_SIZE_SCALE changed to 1

on 09/09/2010 11:01 Andriy Gapon said the following:
> on 26/07/2010 19:07 Andriy Gapon said the following:
>>
>> Anyone knows any reason why VM_KMEM_SIZE_SCALE on amd64 should not be set to 1?
>> I mean things potentially breaking, or some unpleasant surprise for an
>> administrator/user...
> 
> So, after having the discussion, what is our collective conclusion?
> a) Go for it!
> or
> b) Don't do it, fool!
> or
> c) Let's wait another year...

Nobody said (b), so:
http://svn.freebsd.org/viewvc/base?view=revision&revision=212784

This thread in Gmane for your convenience:
http://thread.gmane.org/gmane.os.freebsd.architechture/13419/focus=13551

Intel CPU topology code MFC-ed to stable/8

Please be advised that Intel CPU topology code from head has been MFC-ed to
stable/8 as r214621.

--

-- 
Andriy Gapon
_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"

Re: 8.1-STABLE: zfs and sendfile: problem still exists

On 2010-11-01 8:30, Andriy Gapon wrote:
> First and foremost, the double-caching issue for ZFS+sendfile on FreeBSD is
> still there and no resolution for this issue is on horizon.  So, you have to
> account for the fact that twice as much memory is needed for this use-case.
> Whether you plan your system, or configure it, or tune it.
>
> Second, with recent head and stable/8 ARC should not be the primary victim of
> memory pressure; ARC reclaim thread and the page daemon should cooperate in
> freeing/recycling memory.
>
> Nothing much to add.

Although this discussion started due to issues with serving files thru 
web-typish services, there are more apps that use sendfile.

For one, I noticed that I had once enabled sendfile in my Samba config.
As per this discussion I saw little advantage in keeping it that way......

But I'm open for other suggestions.

--WjW

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"

Re: hast vs ggate+gmirror sychrnoisation speed

On Sat, Oct 30, 2010 at 03:25:56PM +0300, Mikolaj Golub wrote:
> 
> On Thu, 28 Oct 2010 22:08:54 +0300 Mikolaj Golub wrote to Pawel Jakub Dawidek:
> 
>  PJD>> I looked at the code and the keepalive packets arbe sent from another
>  PJD>> thread. Could you try turning them off in primary.c and see if that
>  PJD>> helps?
> 
>  MG> At first I set RETRY_SLEEP to 1 sec to have more keepalive packets. The errors
>  MG> started to observe frequently:
> 
>  MG> Oct 28 21:35:53 bolek hastd[1709]: [storage] (secondary) Unable to receive request header: RPC
version wrong.
>  MG> Oct 28 21:35:54 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully
(pid=1709, exitcode=75).
>  MG> Oct 28 21:36:12 bolek hastd[1722]: [storage] (secondary) Unable to receive request header: RPC
version wrong.
>  MG> Oct 28 21:36:12 bolek hastd[1632]: [storage] (secondary) Worker process exited ungracefully
(pid=1722, exitcode=75).
>  MG> ...
> 
>  MG> Now I have been running synchronization for more then a half an hour with
>  MG> keepalive_send disabled and have not seen any error.
> 
> So  What do you think about sending keepalive in remote_send_thread() to
> avoid this problem and sending them only when a connection is idle (it looks
> like there is no much use to send them all the time)? Something like in the
> patch below (it works for me).

I like your patch and I agree of course it is better to send keepalive

Re: safe mode

On 10/29/2010 05:20 PM, John Baldwin wrote:
> On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote:
>    
>>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21)
>>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19)
>>>
>>>        
>> big snip
>>      
>>> lo0: bpf attached
>>> rr232x: no controller detected.
>>> hptrr: no controller detected.
>>> m
>>>
>>>        
>> Why does FreeBSD think I have a rocket raid controller? This the generic
>> kernel.
>> Is there some way disable this from loading?
>>      
> The hptrr driver is in GENERIC in 6.x and it always prints out the first
> message.  You can ignore it.
>
>    
Hi John,

Here is the verbose boot from the 7.2 release iso
SMAP type=01 base=0000000000000000 len=000000000009fc00
SMAP type=02 base=000000000009fc00 len=0000000000000400
SMAP type=02 base=00000000000e0000 len=0000000000020000
SMAP type=01 base=0000000000100000 len=000000003f9a0000

Re: hast vs ggate+gmirror sychrnoisation speed

On Mon, 1 Nov 2010 12:01:00 +0100 Pawel Jakub Dawidek wrote:

 PJD> I like your patch and I agree of course it is better to send keepalive
 PJD> packets only when connection is idle. The only thing I'd change is to
 PJD> modify QUEUE_TAKE1() macro to take additional argument 'timeout' - if we
 PJD> don't want it to time out, we pass 0. Could you modify your patch?

Sure . Could you look at the updated version?

Note. So far I have only tested that hastd with this updated patch is
compilable and runnable. I will do normal testing today later when I have
access to my test instances and will report about the results.

--

-- 
Mikolaj Golub

_______________________________________________
freebsd-stable <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe <at> freebsd.org"

Re: safe mode

On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote:
> On 10/29/2010 05:20 PM, John Baldwin wrote:
> > On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote:
> >    
> >>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21)
> >>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19)
> >>>
> >>>        
> >> big snip
> >>      
> >>> lo0: bpf attached
> >>> rr232x: no controller detected.
> >>> hptrr: no controller detected.
> >>> m
> >>>
> >>>        
> >> Why does FreeBSD think I have a rocket raid controller? This the generic
> >> kernel.
> >> Is there some way disable this from loading?
> >>      
> > The hptrr driver is in GENERIC in 6.x and it always prints out the first
> > message.  You can ignore it.
> >
> >    
> atapci0: <Intel ICH8M UDMA100 controller> port 
> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x0
> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0
> ata0: <ATA channel 0> on atapci0
> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0
> atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6

Re: safe mode

On 11/01/2010 09:54 AM, John Baldwin wrote:
> On Monday, November 01, 2010 8:38:15 am Stephen Clark wrote:
>    
>> On 10/29/2010 05:20 PM, John Baldwin wrote:
>>      
>>> On Friday, October 29, 2010 4:20:24 pm Stephen Clark wrote:
>>>
>>>        
>>>>> rr232x: RocketRAID 232x controller driver v1.02 (Jan 16 2008 04:16:21)
>>>>> hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 04:16:19)
>>>>>
>>>>>
>>>>>            
>>>> big snip
>>>>
>>>>          
>>>>> lo0: bpf attached
>>>>> rr232x: no controller detected.
>>>>> hptrr: no controller detected.
>>>>> m
>>>>>
>>>>>
>>>>>            
>>>> Why does FreeBSD think I have a rocket raid controller? This the generic
>>>> kernel.
>>>> Is there some way disable this from loading?
>>>>
>>>>          
>>> The hptrr driver is in GENERIC in 6.x and it always prints out the first
>>> message.  You can ignore it.