Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 8 Jun 2016 15:53:57 +0200 (CEST)
From:      =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no>
To:        Niklaas Baudet von Gersdorff <stdin@niklaas.eu>
Cc:        freebsd-questions@freebsd.org, freebsd-net@freebsd.org
Subject:   Re: Getting CARP to broadcast on a different interface
Message-ID:  <alpine.BSF.2.20.1606081547300.1240@mail.fig.ol.no>
In-Reply-To: <20160608124310.GG2050@box-hlm-03.niklaas.eu>
References:  <20160608124310.GG2050@box-hlm-03.niklaas.eu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 8 Jun 2016 14:43+0200, Niklaas Baudet von Gersdorff wrote:

> Hello,
> 
> is it possible to configure CARP in such a way that it sends its
> broadcasts on an interface different from the one that gets the shared
> IP address assigned? Unfortunately, my provider blocks broadcast and
> multicast on public interfaces of virtual machines.
> 
> However, they offer to set up an additional virtual NIC that directly
> connects multiple virtual machines on which broadcast and multicast are
> not blocked. So, while I assign a shared IP to the public interface
> vtnet0, I would like to configure CARP to broadcast on the private
> interface vtnet1.
> 
> Is that possible? Or are there alternatives for CARP that support this
> function?

Although it sounds pretty bad, you could set up CARP on the internal 
network and use those CARP events to control the main interfaces, e.g. 
re-adjust their annoncement intervals, or something equally awful.

You might end up locked out of your systems unless you can control 
them remotely using a third set of means, e.g. RDP.

Just a quick thought that popped up in my head.

-- 
+-------------------------------+------------------------------------+
| Vennlig hilsen,               | Best regards,                      |
| Trond Endrestøl,              | Trond Endrestøl,                   |
| IT-ansvarlig,                 | System administrator,              |
| Fagskolen Innlandet,          | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,       | Cellular...: +47 952 62 567,       |
| sentralbord 61 14 54 00.      | Switchboard: +47 61 14 54 00.      |
+-------------------------------+------------------------------------+
From owner-freebsd-questions@freebsd.org  Wed Jun  8 14:16:08 2016
Return-Path: <owner-freebsd-questions@freebsd.org>
Delivered-To: freebsd-questions@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB078B6EE7E
 for <freebsd-questions@mailman.ysv.freebsd.org>;
 Wed,  8 Jun 2016 14:16:08 +0000 (UTC)
 (envelope-from freebsd@qeng-ho.org)
Received: from bede.qeng-ho.org (bede.qeng-ho.org [217.155.128.241])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "fileserver.home.qeng-ho.org",
 Issuer "fileserver.home.qeng-ho.org" (not verified))
 by mx1.freebsd.org (Postfix) with ESMTPS id 341A8146B
 for <freebsd-questions@freebsd.org>; Wed,  8 Jun 2016 14:16:07 +0000 (UTC)
 (envelope-from freebsd@qeng-ho.org)
Received: from arthur.home.qeng-ho.org (arthur.home.qeng-ho.org [172.23.1.2])
 by bede.home.qeng-ho.org (8.15.2/8.15.2) with ESMTP id
 u58Dws7j044510; Wed, 8 Jun 2016 14:58:55 +0100 (BST)
 (envelope-from freebsd@qeng-ho.org)
Subject: Re: Feedback on UFS2 tuning for large number of small files (~100m)
To: Eduardo Morras <emorrasg@yahoo.es>, freebsd-questions@freebsd.org
References: <CA+Tk8fyZjdvb70HFfwJBD=+J4PU9Ae5FcsaQgSvMZW5B2T3YLA@mail.gmail.com>
 <20160608125325.71fab3fe95b0bc3c6272ea7c@yahoo.es>
From: Arthur Chance <freebsd@qeng-ho.org>
Cc: ciprian.craciun@gmail.com
Message-ID: <67d9d4ae-03c1-f141-92d0-daaa4b168b16@qeng-ho.org>
Date: Wed, 8 Jun 2016 14:58:54 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160608125325.71fab3fe95b0bc3c6272ea7c@yahoo.es>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-BeenThere: freebsd-questions@freebsd.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: User questions <freebsd-questions.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-questions/>;
List-Post: <mailto:freebsd-questions@freebsd.org>
List-Help: <mailto:freebsd-questions-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-questions>, 
 <mailto:freebsd-questions-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 14:16:08 -0000

On 08/06/2016 11:53, Eduardo Morras via freebsd-questions wrote:
> On Wed, 8 Jun 2016 11:14:40 +0300
> Ciprian Dorin Craciun <ciprian.craciun@gmail.com> wrote:
> 
>> Hello all!  (Please keep me in CC as I'm not subscribed on the mailing
>> list.  Should I perhaps post this to the `freebsd-fs` mailing list?)
>>
>>
>> I would like your feedback on tuning a UFS2 file-system for the
>> following use-case, which is very similar to a maildir mail server.  I
>> tried to look for hints on the internet, but found nothing more
>> in-depth than enabling soft-updates, `noatime`, etc.
>>
> 
> You can use tunefs to set:
> 
> a) average file size and expected number of files per directory,
> b) check if your filesystem has any ACL flags on (NFS, POSIX, whatever) and disable them if you don't use ACLs,
> c) if filesystem is full or near full, system switch from faster writes to minimize fragmentation strategy (slower), force the fast access optimization.
> 
> They requires a umount/mount only no reformating. 
> 
> Newfs can set those values at fs formatting/createing.
> 
> There are some sysctl you can tweak, again without reformating:
> 
> vfs.ufs.dirhash_maxmem: maximum allowed dirhash memory usage

Minor point: this looks like it's dependent on the memory size. On my
32GB machine it's 27.8 MB, on my 4GB machine it's 6.5 MB, and on a 2GB
machine it's 3.3 MB.

> 
> Defaul value is 6MB. Check first dirhash usage with 
> 
> #sysctl vfs.ufs.dirhash_mem
> 
> and if it's equal or close to maxmem, grow it (24MB or more, f.ex.)
> 
> Tuning at ffs level are more tricky and risky, check sysctl vfs.ffs.*



-- 
Moore's Law of Mad Science: Every eighteen months, the minimum IQ
necessary to destroy the world drops by one point.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1606081547300.1240>